On Tue, Oct 8, 2019 at 4:36 PM Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > > On Tue, Oct 8, 2019 at 5:32 AM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > > > 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? > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
