(no title)
casta | 1 year ago
Also, you could not cache a config as valid. The configuration validity depends on the current state of the display controller. For example, if a configuration of planes on one CRTC can be set might depend on how much bandwidth is currently required by another one. I remember having to get rid of framebuffer compression on one monitor if another monitor had a resolution above a certain threshold.
Planes rotation property can be 0,90, 180 and 270, you can also flip them: https://www.kernel.org/doc/html/v4.12/gpu/drm-kms.html#c.drm.... If I remember correctly I implemented/upstreamed a few of these properties support for Rockchip display controllers.
If you can rotate a specific buffer will likely depend on your display controller plus if it's tiled or not though, since rotating a linear buffer is going to destroy BW.
If you are writing code only for one specific display controller you can look at the drivers and just figure out which configs are ok.
If your DP supports it, you don't need to GPU composite for screenshots, you can use the write back connector.
dividuum|1 year ago
Yep. At least now the Pi's implementation does cause kernel tracebacks or lockups any more. Was rough in the beginning :-}
Flipping is supported (but not 90/270 rotation) and I use that together with a recently added transpose feature in the Writeback connector to support mirroring the primary VC4's output to the minimal DRM implementation of the official 7" display.
I'm using the Writeback connector to support screenshots, but copying every plane's configuration would be too much sometimes, so I heuristically compose some framebuffers via GL and then only place the remaining framebuffers (including the GL one) on Writeback and HDMI.