On 2025-07-30 06:16, Arun R Murthy wrote:
> Add user readable error codes for failure cases in drm_atomic_ioctl() so
> that user can decode the error code and take corrective measurements.
>
Thanks for doing this work.
> @@ -1541,6 +1548,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> ret = drm_atomic_commit(state);
> }
>
> + /* update the error code if any error to allow user handling it */
> + arg->reserved = state->error_code;
Once we do this we paint ourselves into a corner.
It's nice that we have this reserved field since it allows us to
extend the atomic ioctl without the need to define a new one.
When we discussed this at the Display Next Hackfest [1] we came
to the conclusion that we would want:
- an enum to show what is the issue
- a string that can be logged to display verbose information
about the failure
- an optional array of KMS object IDs participating in the failure
We could define these in a new struct
struct drm_mode_atomic2 {
__u64 failure_reason;
__u64 failure_string;
__u32 drm_object_ids[MAX_FAILURE_OBJECT_IDS]
__u64 reserved;
}
that we link to via the drm_mode_atomic->reserved field.
Your approach of flags, as opposed to an enum, would allow reporting
of multiple failures. Do we think drivers would ever make use of it?
Normally check short-circuits when a failure/limitation is hit.
Harry
[1] https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback
