On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote: > Daniel Vetter <daniel@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
