[casta]

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]

Right. The number of times I got an EINVAL just to discover yet another reason was quiet something :) (Is there a better way to discover the true reason other than scrolling back through dmesg?)

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]

When I worked on it, there was no other way to check if a configuration could be set. I remember suggesting to kernel folks to add some another way, in particular 'cause sometimes we had to allocate some massive buffer just to be told you had to composite.

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]

> The configuration validity depends on the current state of the display controller.

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.