Proposal for RandR version 1.6, Leases and EDID-based output grabs
Keith Packard
keithp at keithp.com
Tue May 2 14:45:25 UTC 2017
Pekka Paalanen <ppaalanen at gmail.com> writes:
> I was under the impression that if you have a VR application running on
> the HMD, it necessarily also implies that you have a VR compositor
> running, which means that there is always some process providing a valid
> image to the HMD. (At least in end-user setups.)
Yes, I think the point I was trying to make was that X should never
attempt to talk to the HMD and provide an image.
> I assumed that means there are no VR apps nor a VR compositor that
> could handle the HMD. In that case I think the HMD should be always
> off.
Agreed.
> I presume that if "desktop" is set to "true", it implies that the HMD
> is capable of showing a simple 2D canvas in stereo without any special
> rendering and with the default video mode. That is, creating a sort of
> a virtual 2D monitor. That would be nice.
I was thinking that 'desktop' would be true for non-HMD displays that
didn't need the VR compositor. If you've got a VR compositor and want to
paint the desktop inside the VR environment, then I think you'd want to
create a synthetic monitor and hand images from that to the VR
compositor each frame.
> FWIW, it all sounds good to me!
>
> I don't really have an opinion on XML vs. JSON, I'm just happy it's not
> another ad hoc format.
Yeah, I think we're done with ad-hoc formats. I've done both XML and
JSON, and JSON is way easier to hand write, but we already use XML in a
bunch of places, so the necessary libaries are already linked into the
server...
--
-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/20170502/2ffb0eb5/attachment.sig>
More information about the dri-devel
mailing list