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

[Keith Packard]

Pekka Paalanen <ppaalanen at gmail.com> writes:

> we need some kind of a database to recognize HMDs in any case, right?
> It would be best if the database was shared, so that everyone could
> recognize all HMDs, at least as far as one can do that based on EDID.

Yeah, I think you've got some good ideas here. Here are some questions
which this raises:

 * What should we do with an HMD which is in the database but for which
   no application is installed on the host?

 * Entries in the database should probably have names an versions, so
   that clients could have some way to identify whether they support
   what has been connected. Would providing the manufacturer ID and
   product codes be sufficient here?

 * Should the database be visible and managed over X? Or should it be
   hidden from clients and only visible to the X server?

 * We want to generate events when the HMD is plugged in; how should
   clients select for these?

> If we had such a database, perhaps interfaced with a library, when how
> about Xorg using that library to automatically recognize and hide HMDs?
> That library would of course be also used by all HMD-supporting Wayland
> servers.

I'm not sure a library is necessary, if the database was a directory
full of files.

> If there was such a library, maybe it could also handle EDID parsing
> once and for all... a libinput for outputs?

Yeah, not a terrible idea, but possibly more yak shaving than we really
need to get into here.

> Btw. I was also told at #openhmd that some HMDs do not appear as
> connected outputs until you specifically turn it on via USB. So there
> is going to be a hotplug, and you'd want to avoid sending that to
> normal X11 clients so that they won't race with the special VR client
> grabbing it.

It'd still get 'hot plugged' in the X server when enabled over USB, so
we'll want to hide that from regular clients in some way.

-- 
-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.x.org/archives/xorg-devel/attachments/20170409/81a34b14/attachment.sig>