Am Mo., 5. Okt. 2026 um 11:08 Uhr schrieb Thomas Zimmermann <[email protected]>: > 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. There's lots of different ways you could fix any specific error, with different tradeoffs and it all depends a lot on what the compositor is actually trying to do. The kernel can't make those kinds of policy decisions.
> > + * @DRM_MODE_ATOMIC_UNSPECIFIED_ERROR: this is the default/unspecified > > error. > > This one does not give a hint to what happens. Should userspace abort or > fall back to TEST_ONLY? That's up to userspace. It's the same as ret=-EINVAL today. > > + * @DRM_MODE_ATOMIC_INVALID_API_USAGE: invallid API usage(DRM_ATOMIC not > > + * enabled, invalid falg, page_flip event > > + * with test-only, etc) > > I've seen this being used in the i915 patch for a async flip. Could > mean anything there (format, driver specifics). Its purpose is to catch anything that the compositor is supposed to know it can't do - using unsupported formats, invalid combinations of properties (crtc active=1 without a connector), that sort of thing. It should never be anything driver specific though. > > + * @DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED: Property changed in async flip > > + * @DRM_MODE_ATOMIC_SCANOUT_BW: For a given resolution, refresh rate and > > the > > + * color depth cannot be accomodated. > > Resolution > > + * is to lower the refresh rate or color > > depth. > > + * @DRM_MODE_ATOMIC_CONNECTOR_BW: Refers to the limitation on the link > > rate on > > + * a given connector. > > + * @DRM_MODE_ATOMIC_PIPE_BW: Limitation on the pipe, either pipe not > > available > > + * or the pipe scaling factor limitation. > > + * @DRM_MODE_ATOMIC_MEMORY_DOMAIN: Any other memory/bandwidth related > > limitation > > + * other then the ones specified above. > > + * @DRM_MODE_ATOMIC_SPEC_VIOLOATION: Limitation of a particular feature on > > that > > + * hardware. To get to know the feature, > > the > > + * property/object causing this is being > > sent > > + * back to user @failure_objs_ptr in the > > + * struct drm_mode_atomic_err_code > > There codes don't seem actionable to me. Scanout and connector bandwidth are very directly actionable. I agree about the others though, adding these error codes should wait until there's a compositor actually using them for something. > > + char failure_string[DRM_MODE_ATOMIC_FAILURE_STRING_LEN]; > > I'd don't think we should return error strings from the kernel. If we > do, these strings will become uAPI. And I guarantee that someone will > start parsing them for information. We'll be in a situation where we > cannot ever change the strings. > > For error logging, we can put messages directly in the kernel log The error string is half the reason we need the API: When things fail on an end user system, we need to be able to find out what happened after the fact, without the user needing to have drm debug logging enabled and without them having to trigger the bug again (which can be very difficult to do). I think making the error string something more abstract like the file + line number of the failure would also be okay, if that solves the concerns about uAPI. We just need some way to figure out what happened after something goes wrong, which would usually involve diving through kernel sources anyways. > or you can build them in user space from within libdrm. libdrm doesn't have any of the information returned in the error string. - Xaver
