Hey. I purchased the new 7" display and naively expected my software to just work. It didn't ![:)]( "Smile")
I realized that, while the display is fully controlled via KMS/DRM, the properties and objects available are severely limited compared to the normal HDMI/vc4 card: There's only a single mandatory (can't commit without) primary plane with lots of properties missing compared to what's available on vc4 planes. Also pixel formats from the video decoder cannot be used directly as the plane only supports XR24 XB24 AR24 AB24 RG24 BG24 RG16 framebuffers.
My software currently fully used the multiple plane composition available normally, so I'm not sure yet on how to best approach this. My idea is to use the writeback connector to produce a 720x1280 XR24 framebuffer and then just commit that to the display's plane. So the vc4's hardware does all the composition and the 7"'s drm device is just a dumb mirror of that. From what I understand labwc uses OpenGL composition and similarly produces a single XR24 framebuffer.
Insights welcome. Is such minimal DRM support typical with these types of display? I guess so, as they don't have any hardware composition support and you're expected to just send them RGB?
For anyone curious: Here's the kmsprint:
I realized that, while the display is fully controlled via KMS/DRM, the properties and objects available are severely limited compared to the normal HDMI/vc4 card: There's only a single mandatory (can't commit without) primary plane with lots of properties missing compared to what's available on vc4 planes. Also pixel formats from the video decoder cannot be used directly as the plane only supports XR24 XB24 AR24 AB24 RG24 BG24 RG16 framebuffers.
My software currently fully used the multiple plane composition available normally, so I'm not sure yet on how to best approach this. My idea is to use the writeback connector to produce a 720x1280 XR24 framebuffer and then just commit that to the display's plane. So the vc4's hardware does all the composition and the 7"'s drm device is just a dumb mirror of that. From what I understand labwc uses OpenGL composition and similarly produces a single XR24 framebuffer.
Insights welcome. Is such minimal DRM support typical with these types of display? I guess so, as they don't have any hardware composition support and you're expected to just send them RGB?
For anyone curious: Here's the kmsprint:
Code:
Connector 0 (35) DSI-2 (connected) EDID (1) = blob-id 0 (immutable) DPMS (2) = 0 (On) [On=0|Standby=1|Suspend=2|Off=3] TILE (4) = blob-id 0 (immutable) link-status (5) = 0 (Good) [Good=0|Bad=1] non-desktop (6) = 0 [0 - 1] (immutable) CRTC_ID (20) = object id 33 Encoder 0 (34) NONE Crtc 0 (33) 720x1280@60.04 83.330 720/239/33/50/? 1280/20/2/30/? 60 (60.04) P|D OUT_FENCE_PTR (19) = 0 [0 - 18446744073709551615] ACTIVE (22) = 1 [0 - 1] MODE_ID (23) = blob-id 39 len 68 VRR_ENABLED (24) = 0 [0 - 1] Plane 0 (31) fb-id: 37 (crtcs: 0) 0,0 720x1280 -> 0,0 720x1280 (XR24 XB24 AR24 AB24 RG24 BG24 RG16) type (8) = 1 (Primary) [Overlay=0|Primary=1|Cursor=2] (immutable) SRC_X (9) = 0 [0 - 4294967295] SRC_Y (10) = 0 [0 - 4294967295] SRC_W (11) = 47185920 [0 - 4294967295] SRC_H (12) = 83886080 [0 - 4294967295] CRTC_X (13) = 0 [-2147483648 - 2147483647] CRTC_Y (14) = 0 [-2147483648 - 2147483647] CRTC_W (15) = 720 [0 - 2147483647] CRTC_H (16) = 1280 [0 - 2147483647] FB_ID (17) = object id 37 IN_FENCE_FD (18) = -1 [-1 - 2147483647] CRTC_ID (20) = object id 33 IN_FORMATS (30) = blob-id 32 len 80 (immutable) FB 37 720x1280 XR24Statistics: Posted by dividuum — Thu Nov 07, 2024 11:00 pm — Replies 1 — Views 21