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. -- -keith
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
