Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

Xaver Hugl
2026-03-23T21:19:37Z

> Have added the remaining error codes to the enum
> drm_mode_atomic_err_code, will push as part of patchset 11.
I think it would be best to limit the enum values to actionable
things. Connector and scanout bandwidth sound useful and pretty
straight-forward to me, but the three other new values don't seem
useful for compositors at the moment.

> DRM_MODE_ATTOMIC_PIPE_BW
Compositors aren't aware of pipes. What would they do with that information?

> DRM_MODE_ATOMIC_MEMORY_DOMAIN
> DRM_MODE_ATOMIC_SPEC_VIOLOATION
I can't think of anything a compositor would do differently with these
vs. "unspecified_error".

> As far as the enum INVALID_API_USAGE is concerned, there is a certain
> understanding on the
> usage of the atomic_ioctl, any miss in that would fall in this
> category.
Invalid API usage would mean the compositor did something it can know
in advance is wrong based on the KMS API. It can't be used as the
default value.

> Some of them include
> - Driver doesnt support atomic, but still atomic_ioctl being used
> - Invalid/Junk flags
> - Async flip not supported
> - Flag page flip event along with test only is not supported
> If changing this INVALID_API_USAGE to UNSPECIFIED_ERROR makes more
> sense, I can change that.
No, they're two different things. We need both, and unspecified_error
needs to be the default for when the driver doesn't set anything more
specific.

- Xaver