Daniel Vetter <daniel@xxxxxxxx> writes: > Yeah I think that's a pretty neat idea to reduce the lease complexity even > more. If the VR compositor is unhappy and wants a different mode, it can > simply nuke the lease and as for a new one. Forgot to say that :-) Not sure it changes the lease complexity, but it reduces the potential interference with the X server after the lease is created. Hrm. Thinking about the impact on X a bit more, this seems hard - you can't just display the root window in the HMD, so you need a frame buffer to use. The VR compositor can construct this knowing the planned X mode, but, we then have to wire it through the whole X mode set infrastructure, which is not exactly set up to do that. I'll go look at the code in more detail, but I suspect the easiest plan will be to have the VR compositor set its own mode. That may fail if X is consuming too many display resources, but that doesn't seem significantly different from having the lease fail. This doesn't change the kernel API at all, so we can figure out the X bits separately from the kernel bits. -- -keith
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel