> 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
