Hi,

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.

The first patch is a small cleanup aligning __drm_colorops_state with
the naming convention used by the other atomic state tracking
structures.

Patches 2 through 6 extract the state insertion logic from each
drm_atomic_get_*_state() function into standalone helpers. This is
needed because the new fill_with_defaults path creates states through
atomic_create_state() rather than atomic_duplicate_state(), so it
cannot go through the existing drm_atomic_get_*_state() functions.

Patch 7 adds drm_atomic_commit_fill_with_defaults(), which uses those
helpers to populate a commit with pristine states for every object in
the device.

Patch 8 wires it all up by adding DRM_MODE_ATOMIC_RESET to the atomic
ioctl.

Open question: should DRM_MODE_ATOMIC_RESET require
DRM_MODE_ATOMIC_ALLOW_MODESET? A full state reset will change CRTC
active states, which is effectively a modeset. Without requiring it,
a reset could pass flag validation but fail later at atomic_check in
a confusing way.

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. Sending it now to get early feedback on the approach.

Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
Maxime Ripard (7):
      drm/atomic: colorop: Rename state to state_to_destroy
      drm/atomic: Create function to insert CRTC state into a commit
      drm/atomic: Create function to insert plane state into a commit
      drm/atomic: Create function to insert colorop state into a commit
      drm/atomic: Create function to insert private obj state into a commit
      drm/atomic: Create function to insert connector state into a commit
      drm/atomic: Allow filling a commit with pristine object states

Sebastian Wick (1):
      drm/atomic-uapi: Add DRM_MODE_ATOMIC_RESET flag

 drivers/gpu/drm/drm_atomic.c        | 327 +++++++++++++++++++++++++++++-------
 drivers/gpu/drm/drm_atomic_helper.c |   2 +-
 drivers/gpu/drm/drm_atomic_uapi.c   |  13 ++
 include/drm/drm_atomic.h            |  19 ++-
 include/uapi/drm/drm_mode.h         |  14 +-
 5 files changed, 307 insertions(+), 68 deletions(-)
---
base-commit: cff96362794a5c1f3adb013b4a46c7233149a629
change-id: 20260708-drm-reset-state-flag-2fb2b5711f97

Best regards,
-- 
Maxime Ripard <mripard@kernel.org>

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

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

Hi,

Thanks for working on this, it'll be great to finally have this solved properly.

> Open question: should DRM_MODE_ATOMIC_RESET require
> DRM_MODE_ATOMIC_ALLOW_MODESET? A full state reset will change CRTC
> active states, which is effectively a modeset. Without requiring it,
> a reset could pass flag validation but fail later at atomic_check in
> a confusing way.
The compositor may use the same CRTC states, modes etc; whether or not
the commit actually ends up requiring a modeset depends entirely on
the exact contents of the commit. So I definitely wouldn't require
ALLOW_MODESET.

- Xaver

Hi Xaver,

On Wed, Jul 08, 2026 at 08:25:36PM +0200, Xaver Hugl wrote:
> Hi,
> 
> Thanks for working on this, it'll be great to finally have this solved properly.
> 
> > Open question: should DRM_MODE_ATOMIC_RESET require
> > DRM_MODE_ATOMIC_ALLOW_MODESET? A full state reset will change CRTC
> > active states, which is effectively a modeset. Without requiring it,
> > a reset could pass flag validation but fail later at atomic_check in
> > a confusing way.
>
> The compositor may use the same CRTC states, modes etc; whether or not
> the commit actually ends up requiring a modeset depends entirely on
> the exact contents of the commit. So I definitely wouldn't require
> ALLOW_MODESET.

Just to make sure we're on the same page, you're saying that when using
the reset flag, the compositor is expected to fill the state with enough
that a modeset is unlikely to happen anyway?

Maxime

Am Do., 16. Juli 2026 um 10:26 Uhr schrieb Maxime Ripard <mripard@kernel.org>:
> > The compositor may use the same CRTC states, modes etc; whether or not
> > the commit actually ends up requiring a modeset depends entirely on
> > the exact contents of the commit. So I definitely wouldn't require
> > ALLOW_MODESET.
>
> Just to make sure we're on the same page, you're saying that when using
> the reset flag, the compositor is expected to fill the state with enough
> that a modeset is unlikely to happen anyway?

I'm saying that it's no different from a "normal" commit, and should
just follow the normal rules for whether or not a commit needs
allow_modeset. You can't make assumptions about which properties the
compositor will or will not set.

- Xaver

On Fri, Jul 17, 2026 at 03:03:10PM +0200, Xaver Hugl wrote:
> Am Do., 16. Juli 2026 um 10:26 Uhr schrieb Maxime Ripard <mripard@kernel.org>:
> > > The compositor may use the same CRTC states, modes etc; whether or not
> > > the commit actually ends up requiring a modeset depends entirely on
> > > the exact contents of the commit. So I definitely wouldn't require
> > > ALLOW_MODESET.
> >
> > Just to make sure we're on the same page, you're saying that when using
> > the reset flag, the compositor is expected to fill the state with enough
> > that a modeset is unlikely to happen anyway?
> 
> I'm saying that it's no different from a "normal" commit, and should
> just follow the normal rules for whether or not a commit needs
> allow_modeset. You can't make assumptions about which properties the
> compositor will or will not set.

Ah, I see what you mean now, thanks. It makes total sense indeed, I'll
drop that part from the cover letter.

Maxime