Re: [PATCH v11 1/7] drm: Define user readable error codes for atomic ioctl

["Murthy, Arun R" <arun.r.murthy@intel.com>]

On 05-10-2026 19:30, Xaver Hugl wrote:
>> That's not a policy decision. User space is free to do what ever it
>> wants.  What I have in mind is a hint from the kernel what to do next.
> There's a lot of different ways a commit could be fixed, and telling
> the compositor things like "turn off this plane" wouldn't give the
> compositor any actionable choices except giving up or exactly
> following the hint.
>
> If you meant much higher level things like
> - reduce scanout bandwidth
> - reduce connector bandwidth on this connector
> - do a modeset
>
> that's exactly what the proposed API does.
>
> I don't think there's a middle ground between the two, KMS is too
> complex for that.
>
>>>>> + * @DRM_MODE_ATOMIC_INVALID_API_USAGE: invallid API usage(DRM_ATOMIC not
>>>>> + *                                  enabled, invalid falg, page_flip event
>>>>> + *                                  with test-only, etc)
>>>> I've seen this being used in the i915 patch for a async flip.  Could
>>>> mean anything there (format, driver specifics).
>>> Its purpose is to catch anything that the compositor is supposed to
>>> know it can't do - using unsupported formats, invalid combinations of
>>> properties (crtc active=1 without a connector), that sort of thing. It
>>> should never be anything driver specific though.
>> I don't see how this could be useful except for the prototype that come
>> with this series.  It's so broad in meaning that it's almost meaningless.
> It's useful because it tells the compositor that the failure is caused
> by an implementation error in the compositor, instead of some driver
> or hardware limitation. It doesn't need to be meaningful outside of
> that, a developer later debugging what went wrong can use the error
> string to figure it out.
>
>> And error codes don't have to be driver specific to be meaningful. I
>> already brought up DRM's mode-status code as example. They are not
>> specific to any mode, display or hardware. Yet they clearly state what
>> went wrong with the mode.
> I think that only works because the mode isn't specific to any display
> or hardware. Atomic commit failures are often specific to some
> combination of driver, GPU and display.
>
>> You could to this with detailed and precise error codes plus the object
>> on which it failed.
> They can never be detailed enough to exactly pinpoint specific edge
> cases, unless you give literally every single return path in every
> driver an individual error code. I don't think that is feasible (and
> then that error code would be uAPI).
>
Yes at cases of error where driver feels that a change in the 
drm_mode_object/property can overcome the failure will be reported.
>> Filename + line is even worse.  None of this is even close to stable.
>> I'll nak this as much as possible.
> That's the point? It's supposed to be not stable, so it doesn't become uAPI.
Even I feel that expose kernel file name and line number is unnecessary 
for the user log. We anyway have this in dmesg and will be debugged upon.
>> I also don't buy the argument about diving through kernel sources. Not
>> doing that should be the goal here because it is what we currently do.
> I don't think that's something you can ever fully get around. Just the
> very hardware specific error cases alone make it impossible.

To differentiate the hardware specific error we have SPEC_VIOLATION 
error code for which compositor may not be able to take corrective 
measurement. Compositor upon getting this should look for alternative 
such as software/gpu composition.  Logging this will have debugging in 
the kernel.

Thanks and Regards,
Arun R Murthy
--------------------

> - Xaver