Hi
Am 05.10.26 um 16:00 schrieb Xaver Hugl:
That's not a policy decision. User space is free to do what ever it
wants. What I have in mind is a hint from the kernel what to do next.
There's a lot of different ways a commit could be fixed, and telling
the compositor things like "turn off this plane" wouldn't give the
compositor any actionable choices except giving up or exactly
following the hint.
If you meant much higher level things like
- reduce scanout bandwidth
- reduce connector bandwidth on this connector
- do a modeset
that's exactly what the proposed API does.
That's only half of the error codes.
I don't think there's a middle ground between the two, KMS is too
complex for that.
You don't have to lecture me on the complexity of KMS. It's actually
not that complex; it's huge in size, but that's a different problem.
+ * @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.
I don't see how this could be useful except for the prototype that come
with this series. It's so broad in meaning that it's almost meaningless.
It's useful because it tells the compositor that the failure is caused
by an implementation error in the compositor, instead of some driver
or hardware limitation. It doesn't need to be meaningful outside of
that, a developer later debugging what went wrong can use the error
string to figure it out.
The XDC presentation made it sound as if the goal was to improve
compositor quality of service. With this series, it sounds more like
it's for debugging purposes. Those are distinct problems and I ind it
confusing. I'd like to suggest to focus on one problem first.
And error codes don't have to be driver specific to be meaningful. I
already brought up DRM's mode-status code as example. They are not
specific to any mode, display or hardware. Yet they clearly state what
went wrong with the mode.
I think that only works because the mode isn't specific to any display
or hardware. Atomic commit failures are often specific to some
combination of driver, GPU and display.
The display-mode error codes are almost all related to hardware and
display limitations. They are not related to any specific hardware
device. The goal for KMS error reporting should be to to build
something similar one a wider scope. Additional details about driver,
GPU and display are available today. There's no need for more interfaces
there.
You could to this with detailed and precise error codes plus the object
on which it failed.
They can never be detailed enough to exactly pinpoint specific edge
cases, unless you give literally every single return path in every
No. We give every error condition an individual error code; not every
return path. These are distinct things.
Some examples:
- For planes, the given format and sizes might be unsupported. Those
would be error codes.
- For the CRTC, most driver's atomic checks tests the mode against the
hardware limits. Existing display-mode constants tell us what to expect
there.
- Encoders and connectors often mirror these properties on a lower
level, such as bus formats, bus transfer rates, etc. They could likely
reuse some of the error codes.
- Then there are cases where pipeline stages cannot be connected with
each other. That's another distinct error code.
Apart from these plain atomic states, DRM exposes many settings as typed
property. These can likely be subsumed under a number of generic error
codes. For example
- Most properties can have an invalid-value error
- Numeric properties can have additional value-too-low and
value-too-high errors.
If you have properties that conflict with each other; return a list of
their ids with a conflicting-values error code.
With all this, user-space compositors have plenty of information to
create bug reports or try to resolve the problem automatically.
driver an individual error code. I don't think that is feasible (and
then that error code would be uAPI).
Yes, the codes will be uAPI. There are already plenty of defines and
constants everywhere in the kernel's uAPI. There are already >130 errno
code in the uAPI. If we need another 100 or 200 error codes for KMS, I'd
be fine with that.
Filename + line is even worse. None of this is even close to stable.
I'll nak this as much as possible.
That's the point? It's supposed to be not stable, so it doesn't become uAPI.
You must be new here. Anything that goes through the uAPI channels is
de-facto uAPI. If a program in user space might rely on it, it cannot be
changed.
IF you want to get filenames or lines or any other volatile information,
you can get them via debugfs. It's designated to be unstable.
I also don't buy the argument about diving through kernel sources. Not
doing that should be the goal here because it is what we currently do.
I don't think that's something you can ever fully get around. Just the
very hardware specific error cases alone make it impossible.
With KMS, we have been able to build a hardware-neutral interface for
programming the display pipeline. I don't believe that error codes are a
special exception from that.
Best regards
Thomas
- Xaver
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri, (HRB 36809, AG Nürnberg)
