Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Keith Packard]

Daniel Vetter <daniel at ffwll.ch> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170404/e501a393/attachment.sig>