Re: [PATCH v11 1/7] drm: Define user readable error codes for atomic ioctl

[Jani Nikula <jani.nikula@linux.intel.com>]

On Mon, 05 Oct 2026, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> I have serious doubts about these failure codes. The core issue to me is 
> that when the kernel driver detects an impossible commit, it probably 
> knows best how to fix it. Yet the failure codes often lack actionable 
> meaning.

From a different perspective, one of my concerns is that not only the
error codes become ABI, but also the behaviour becomes ABI.

When you're doing atomic check, you usually bail out at the first
problem you can't wiggle around. It's hard or impossible to figure out
the next problem or a bigger problem, because you've just detected you
have a configuration you can't support anyway. You hit the first problem
and you report that.

Now, let's assume userspace adapts to an error code, retries with
different settings, and things work. What if we want to do atomic checks
in a different order in the driver, because it makes sense or is better
or whatever. Is it a regression to report a different error code because
we now do the checks in a different order? Is that painting ourselves in
the corner?


BR,
Jani.


-- 
Jani Nikula, Intel