Hi Michel,

On Fri, Jul 10, 2026 at 07:01:29PM +0200, Michel Dänzer wrote:
> 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.

Ack.

> > 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)

My initial reaction when we discussed it on IRC was that the conversion
from reset to atomic_create_state is going to remove reset, so by the
time it's merged, an out-of-tree driver that wouldn't implement
atomic_create_state would not compile.

That being said, I just remembered that i915 implements neither, so it's
a good thing to have indeed.

Maxime

Attachment: signature.asc
Description: PGP signature

Reply via email to