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

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

On 24-03-2026 02:49, Xaver Hugl wrote:
>> 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?

There are scenarios where two pipes driving a single connector, in that 
case compositor will be informed on the unavailability of pipe, on the 
other hand, if a given pipe scaler factor couldnt be supported due to 
b/w limitation, that would fall into this category. The object pointer 
would precisely convey the property causing this error.


>
>> 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".

Added this based on the feedback from 
https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback

>> 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.

Understand that it cant be a default error, will add another entry 
DRM_MODE_ATOMIC_UNDEFINED_ERROR which would be the default one.


>> 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.

Got it as commented above, will add DRM_MODE_ATOMIC_UNDEFINED_ERROR 
which would be for default error.

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

> - Xaver