Alex Deucher <alexdeucher@xxxxxxxxx> writes: > I think there is a definite use case there. I agree. What we're missing right now is someone interested in driving an implementation of that use case to help define the right interfaces. Lacking that, we're not likely to come up with a good solution on our own. I think that's what Daniel is concerned about -- specifying something in the absence of an implementation using it. I took a stab at this and added the ability to change leases on the fly, and to create 'sub-leases' from an existing lease. He's pushing back on those features, and I think his reasons are sound. > 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. For multi-user, this makes a lot of sense; you'd want the system to allocate resources between users to allow them to operate fairly independently. For single-user with a hot-plugged HMD, I'd suggest that having X involved makes a lot of sense -- you may have to interact with the user to reduce resource consumption so that the HMD can be driven successfully, and that will involve poking at the X configuration. > 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. I don't think we've precluded this for a multi-user environment, and I think it's a good plan in the abstract. I will, however, suggest that asking for VR applications to wait for the desktop environment to be re-architected so that display resources can be centrally allocated by a new 'display resource manager' seems like a rather steep requirement. What I do want to ensure is that these two use cases can both be supported by the kernel interfaces we define, and that we can work in user space on either design going forward. If you'd like to start exploring the design of such a central service, that'd be awesome. -- -keith
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
