Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Daniel Vetter]

On Tue, Apr 04, 2017 at 08:53:45AM -0700, Keith Packard wrote:
> Daniel Vetter <daniel at ffwll.ch> 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