On Tue, Apr 4, 2017 at 3:02 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > 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 :-) > I don't know about vaprware. There were a number of attempts to provide static allocation if display resources over the years to solve things like custom zaphod configs and users wanting to use multiple heads for separate users (which currently ends up in various zephyr hacks IRC). Lots of patches were proposed, none landed. I think there is a definite use case there. Why do we need to make X aware of the lease stuff? What about having some pre-X configuration that decides how to split up the display resources. It could be user defined static or dynamic based on what is attached. You can just start X on the device nodes with whatever resources they are assigned. In the multi-user case, you can statically assign resources to each node; in the VR case, you can detect the HMD and automatically assign it's resources to a separate node or override if necessary. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
