> 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. I don't think there's a middle ground between the two, KMS is too complex for that. > >>> + * @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. > 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. > 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 driver an individual error code. I don't think that is feasible (and then that error code would be uAPI). > 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. > 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. - Xaver
