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

[Daniel Vetter]

On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote:
> Daniel Vetter <daniel at ffwll.ch> writes:
> 
> > Also if this confuses VR, then another reason why we want to make leases
> > invariant and only allow pure revoke, not changing the list.
> 
> I'm not sure why you want this to be asymmetrical, nor why you would
> expect lessees to be any more competent at dealing with hotplug than the
> lessor.
> 
> One use case already proposed for this API was to allow for multi-seat,
> where the lessee would be an existing window system, which we already
> accept as being incompetent at dealing with resource hotplug. I imagine
> that in this case, a newly plugged monitor would be detected by the
> multi-seat manager (logind?) and added to one of the existing leases,
> along with a suitable CRTC resource. For this to work, the lessee will
> need to already know about those resources and only have their
> connectivity status hidden.

The multi-seat thing sounds like vapourware, I think we should care about
the vr use-case for now, and only that one. And for that restricting stuff
is perfectly fine. Of course we can design the entire thing in a way that
doesn't draw us into a corner in the future right away, but that's mostly
on the implementation side. 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. 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 :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch