VK_EXT_aquire_xlib_display and kernel security concerns
Keith Packard
keithp at keithp.com
Tue Oct 17 00:49:57 UTC 2017
Andy Ritger <aritger at nvidia.com> writes:
> If the NVIDIA X driver finds an HMD display, it:
>
> (a) Marks it as disconnected.
> (b) Does not make its EDID available to RandR clients.
>
> So, unless I'm mistaken, RandR clients will see the HMD as an RandR
> output. But, perhaps the problem is that the RandR client cannot tell
> that the output is an HMD, since the EDID is not available?
It will look like a regular disconnected output...
> Item (b) was only an artifact of how the code is structured, not an
> intentional decision. To be fair, disconnected output with EDID sounds
> like a slightly odd state.
Well, the goal is to have regular X clients ignore the output, for which
reporting a Disconnected state seems the best way. The only question is
then how to report to 'special' clients that there is an HMD present on
the connector. We could:
a) Create a new request to query 'hidden' outputs
b) Report the 'connected' state in a new output property
c) Let the client infer that a valid EDID indicates that
a display is connected.
We would still send RROutputChangeNotify events when the device was
connected/disconnected so that applications could track the state of the
device, but of course the 'connection' status in that event would always
be Disconnected.
> Anyway, we can update the NVIDIA driver behavior to match whatever
> consensus we reach here.
Let's try to poke holes in the simple plan that Dave suggested above; I
can't see any offhand, but I haven't tried to implement it in the X
server or applications either.
Btw, was there any particular reason the acquire_xlib_display extension
used Xlib types instead of xcb types?
--
-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/20171016/32fa3274/attachment-0001.sig>
More information about the xorg-devel
mailing list