On Tue, Apr 04, 2017 at 08:53:45AM -0700, Keith Packard wrote: > Daniel Vetter <daniel@xxxxxxxx> writes: > > > The multi-seat thing sounds like vapourware, I think we should care about > > the vr use-case for now, and only that one. > > Ok, I can live with that, even if I like the idea of a slightly more > general solution. > > > For VR itself I'd go as far as saying that probably our "create lease" > > ioctl should have only the semantics we need to pass one crtc+primary > > plane for pageflipping in a VR compositor, expressed in a flag. > > Yeah, we can't express planes through X anyways. I'll leave the kernel > API with multiple planes as that's actually simpler than having it > validate that only a single plane is in the lease. > > > All the details about additional corner cases are just so unclear to > > me (and there's not even a clear use case that will materialize) that > > I don't think having the uapi is worth it. Too close to the "I'll > > regret this immediately" bucket :-) > > Removing the 'ChangeLease' ioctl eliminates a bunch of complexity in the > code, and means I don't even have to think about sending events. I'll > also go ahead and remove the ability to hide resources from the lessor. > > Thanks, as always, for your thoughtful review. > > ps -- Any thoughts on whether the X request should include the mode to > use? Doing that would let us restrict the lessee from setting modes, > and avoid potential resource issues with the window system. However, it > would also require providing a scanout buffer in the request. Yeah I think that's a pretty neat idea to reduce the lease complexity even more. If the VR compositor is unhappy and wants a different mode, it can simply nuke the lease and as for a new one. Forgot to say that :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
