I’m trying to find some sort of formal document showing the thou-shalts and though-shalt-nots of userspace DRM applications’ interaction with the KMS UAPI.<div dir="auto"><br></div><div dir="auto">(For modern atomic commits, not the legacy modeset API.)</div><div dir="auto"><br></div><div dir="auto">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 <div dir="auto"><a href="https://www.kernel.org/doc/html/v4.14/gpu/drm-uapi.html">https://www.kernel.org/doc/html/v4.14/gpu/drm-uapi.html</a> 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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Does anybody know whether something like that exists?</div><div dir="auto"><br></div><div dir="auto">-Matt</div></div>