On 7/8/26 18:08, Maxime Ripard wrote: > > Userspace currently has no atomic way to bring a display pipeline back > to a pristine state. A compositor that wants to start from a known > baseline must explicitly set every property on every KMS object to its > default value, which requires tracking which properties exist and what > their defaults are. This is fragile and must be updated every time a > new property is added to the kernel. > > This series introduces a new DRM_MODE_ATOMIC_RESET flag for the > atomic ioctl. When set, the kernel fills the commit with default > states for all KMS objects before applying the properties supplied in > the request. Properties not explicitly included remain at their > defaults (CRTCs inactive, planes disabled, connectors unbound, and so > on). This allows userspace to describe the desired end state > declaratively, without having to care about the current state or the > full set of properties.
Nice! > Patch 8 wires it all up by adding DRM_MODE_ATOMIC_RESET to the atomic > ioctl. The new flag should be accompanied by a new DRM_CAP_* cap, so user space knows when the new flag is valid. > This series is untested and relies on all drivers implementing the > atomic_create_state hook, which is not yet the case. The conversion > is actively in progress but not complete, so this will not work as-is > today. As discussed on IRC, the new cap could be made conditional on the atomic_create_state hook being available. That would allow this series to land before all in-tree drivers are converted. (As a bonus, it would also avoid issues with out-of-tree drivers which might not support the atomic_create_state hook) -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
