Hey.
I've ported my software to use DRM to draw content on the 7" display. Right now I'm getting its 'preferred mode' property (It's a portrait 720x1280 mode), apply that transposed to the main VC4 DRM subsystem and let it render into a 1280x720 framebuffer using the writeback connector for hardware composition of multiple DRM planes. I then take that framebuffer, transpose it in software (![:|]( "Neutral")
) and then set it as the single plane on the 7" display. The result is a 1280x720 output on the 7" display (as well as on the first HDMI output).
I discovered this change (Enable Raspberry Touch 2 rotation with overlay) and thought that this might have added a way to avoid the software transpose I'm currently doing by allowing me to directly create a 1280x720 framebuffer to place on the 7" display. But despite having dtoverlay=vc4-kms-dsi-ili9881-7inch,rotation=90 in config.txt and video=DSI-1:720x1280M@60,rotate=270 in cmdline.txt, I don't see any change except that the initial Linux framebuffer console is rotated.
After following the linked patch above, I now think that all this change is doing is to signal any DRM user via an immutable "panel rotation" property how the panel is oriented and it's up to the respective software to then draw its content the right way up. So the frame buffer console driver probably respects that and wayland through GL composition gets the rotation for free.
Is that correct or am I missing some property I could set that would allow me to directly use a 1280x720 framebuffer object?
I've ported my software to use DRM to draw content on the 7" display. Right now I'm getting its 'preferred mode' property (It's a portrait 720x1280 mode), apply that transposed to the main VC4 DRM subsystem and let it render into a 1280x720 framebuffer using the writeback connector for hardware composition of multiple DRM planes. I then take that framebuffer, transpose it in software (
) and then set it as the single plane on the 7" display. The result is a 1280x720 output on the 7" display (as well as on the first HDMI output).I discovered this change (Enable Raspberry Touch 2 rotation with overlay) and thought that this might have added a way to avoid the software transpose I'm currently doing by allowing me to directly create a 1280x720 framebuffer to place on the 7" display. But despite having dtoverlay=vc4-kms-dsi-ili9881-7inch,rotation=90 in config.txt and video=DSI-1:720x1280M@60,rotate=270 in cmdline.txt, I don't see any change except that the initial Linux framebuffer console is rotated.
After following the linked patch above, I now think that all this change is doing is to signal any DRM user via an immutable "panel rotation" property how the panel is oriented and it's up to the respective software to then draw its content the right way up. So the frame buffer console driver probably respects that and wayland through GL composition gets the rotation for free.
Is that correct or am I missing some property I could set that would allow me to directly use a 1280x720 framebuffer object?
Statistics: Posted by dividuum — Wed Nov 27, 2024 1:27 pm