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

Daniel Stone daniel at fooishbar.org
Tue Oct 8 09:31:56 UTC 2019


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?

Cheers,
Daniel


More information about the dri-devel mailing list