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

[Alex Deucher]

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.

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.

Alex