liboutput: thoughts about shared library on top of DRM/KMS

[Daniel Vetter]

On Tue, Oct 8, 2019 at 4:36 PM Alex Deucher <alexdeucher at gmail.com> wrote:
>
> On Tue, Oct 8, 2019 at 5:32 AM Daniel Stone <daniel at fooishbar.org> wrote:
> >
> > Hi,
> >
> > On Mon, 7 Oct 2019 at 19:16, Keith Packard <keithp at keithp.com> wrote:
> > > Daniel Stone <daniel at fooishbar.org> writes:
> > > > I think there would be a load of value in starting with simple helpers
> > > > which can be used independently of any larger scheme, tackling that
> > > > list above.
> > >
> > > Yeah, a helper library that didn't enforce at tonne of policy and just
> > > let the user glue things together on their own is probably going to be
> > > more generally usable by existing and new systems.
> >
> > To elaborate a little bit, one of the reasons I'm loath to hide
> > complexity like transforms, colour management, and timing away in an
> > encapsulated lower layer, is because I have to expose all those
> > details anyway. Ultimately to make those work properly, we'll require
> > awareness not just in the compositor itself, but pushed through to
> > clients.
> >
> > Wayland already has facility for informing clients about output
> > transforms so they can render pre-rotated and avoid the
> > compositor-side transform; in order to make HDR and other colour
> > management (e.g. just simple calibration) properly we need to have
> > full plumbing back through to clients; doing timing properly,
> > particularly for multiple simultaneous clients, also requires a fair
> > bit of mechanics and back-and-forth.
> >
> > There's a lot that we could usefully share between all the users, and
> > having a shared library to help with that would be great. But the
> > thought of tucking it all away in an opaque layer which (*waves
> > hands*) just does it, gives me cold EGLStreams sweats.
> >
> > Maybe a good place to start is if we all listed the bits of code which
> > we'd be delighted to jettison?
>
> On the flipside, it would be nice to have one set of code to do
> modesets from userspace.  Certainly simplifies QA since in theory we
> should be seeing the same sequences from all apps using the helpers
> rather than every app rolling their own and getting it subtly
> different enough that strange things happen with different
> compositors.

For atomic drivers, and atomic userspace this really doesn't matter
anymore. Because userspace just assembles an overall update, and the
kernel applies that update no matter in which order userspace listed
the property/value/object triples.

It does somewhat matter for legacy kms (but not from a driver
validation pov, anything legacy can do can also be done as a legit
request through atomic), but I really can't care about that one much.
Imo better to just cut everyone over to atomic. The only thing that
might make sense is the fake atomic support, where userspace tries to
not be too dumb about a transition on drivers without atomic (i.e.
shut down crtcs first, then light up the new ones, to avoid in-between
state that oversubscribes available hw resources). But that's really a
niche thing.

> While we are on the topic, it would be nice to have a central place
> for robustness/context lost handling for compositors so we can
> properly handle GPU resets.  Not sure that is really possible though.

I think this blows up the scope too much and will break the project.
In the past there's been attempts at a libcompositor (and you need
that much to recover from context loss), and that never got anywhere
at all. I think the modular helpers approach has a much bigger chance
at success.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch