Re: [PATCH v4 00/13] drm: Add DRM_MODE_ATOMIC_RESET flag

[Daniel Stone]

Hi Maxime,

On Fri, 18 Sept 2026 at 15:18, Maxime Ripard <mripard@xxxxxxxxxx> 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. This allows userspace to describe the desired end state
> declaratively, without caring about the current state or the full set
> of properties.

Thanks for bumping this - I had the original patch in my queue to look
at after the hackfest, but it got lost in an unfortunate tab
explosion.

I think it would be good to document more clearly that 'default
state', generally, means 'everything disabled'. Of course stuff like
colour properties and max_bpc and whatever will likely have different
values (where 'default state' means 'enough to get a basic 32bpp image
displayed if you don't care about the details'), but I think
explicitly calling out that planes + CRTCs + connectors will all be
disabled would be useful.

I can't find any holes in the implementation though, and I like the
uAPI. I'd do the same thing for Weston as for Mutter: in our
backend->state_invalid loop where we loop through setting all
planes/CRTCs/connectors as disabled when we aren't just issuing
incremental state updates, we'd ignore that and go straight to the
STATE_RESET path.

I wonder if we also want some kselftests along the lines of the VKMS
IGT test, i.e. for drm_atomic_helper_connector_hdmi_reset_tests[] to
make sure that the assumptions hold after init -> apply different
state -> reset state.

Regardless, series is:
Reviewed-by: Daniel Stone <daniels@xxxxxxxxxxxxx>

... with my reading-kernel-code and evaluating-uAPI hats both on.

Cheers,
Daniel