There isn't a totally clean and generic solution that we can think of, but there may be a slightly dirty one that would work. I might see if I can put it together quickly tomorrow.
. Just discovered this thread by lazily browsing the forum! Right now in my software I transparently (as much as that's possible) fall back to rotating videos using OpenGL textures instead of DRM framebuffers for 90/270 rotations. Happy to see that there might be a more performant(?) solution now?I'm currently using atomic commits. From what I understand, rotating would now require me to activate one of the two(?) writeback crtcs with a fake WxH mode, assign the to-be-rotated framebuffer so fills that area. Then set the writeback's target FB to one with size HxW. And then commit that along with other stuff intended for HDMI. Correct? I guess it's not possible to use the target FB within the same commit to place that on one of the HDMI displays? So there would always be at least one frame of additional latency?
Statistics: Posted by dividuum — Wed Aug 21, 2024 9:09 pm