(For modern atomic commits, not the legacy modeset API.)
I’m interested in stuff like what minimum set of properties are required on CRTCs or planes when activating or deactivating a connector. There’s very good documentation at
https://www.kernel.org/doc/html/v4.14/gpu/drm-uapi.html showing the expectations on drivers who implement KMS. But I didn’t find the equivalent stuff that would show how to write a guaranteed-portable KMS application.
I find that it’s easy to write DRM masters that generally work on canonical drivers like the integrated Intel GPUs, but show odd behaviors with forked vendor DRM drivers. It would be really nice to be able to point to a spec and say either that userspace is doing things by the book (so the bug must be in the driver) or that userspace was unintentionally relying on undefined driver behavior.
In practice, there are lots of working examples in libdrm or a reference compositor like Wayland. But those don’t typically have inline comments to differentiate between required and elective behavior.
Does anybody know whether something like that exists?
-Matt
