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

[Keith Packard <keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1150 bytes --]

Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> 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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel