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
