The drm atomic test is not only to verify if it's "correct", it is also used to check if the display controller can scan out that configuration of planes/buffers, given buffer modifiers, plane properties/sizes, etc. and current status of the display controller. If it can't, you probably need to simplify the configuration via some GPU compositing.This is what we were doing on ChromeOS.
dividuum|1 year ago
I'm also falling back to GL composition in some cases or while taking screenshots to avoid composing twice (HDMI + Writeback) if the scene is too complex or if other restrictions make that mandatory: Planes can only be rotated 0/180 degrees on the Pi HVS, so rotating a video to a portrait orientation is done on the GPU.
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.