Hi, On Mon, 7 Oct 2019 at 19:16, Keith Packard <keithp@xxxxxxxxxx> wrote: > Daniel Stone <daniel@xxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
