James Jones <[email protected]> writes: > Understood. In that case, no displays should be enumerated on the > "rendering hardware" device in Vulkan, unless the driver vendor opts for > heroics.
We try to avoid software heroics where possible. > Right, but normal processes don't need the display node, or aren't > supposed to. I assumed apps that need direct-to-display would have > elevated permissions on systems configured to require it, or use > "acquire" extensions, potentially combined with native secondary auth > mechanisms, to get access. This is why it bothers me that "normal user > access" doesn't include display enumeration. Imagine a multi-user setup where each display server controls only a subset of the available resources. In that configuration, an application would enumerate the available resources using the display server and would not attempt to use resources assigned to another user. For privileged users, I've proposed an extension which passes the master FD into Vulkan as the instance is created. The implementation would then use this to directly enumerate the display resources for use without the acquire_xlib_display extension. > Once a method is finalized to expose HMDs without having desktops pick > them up, we can probably switch to that behavior. We'll have to review > the proposed disconnected-but-has-EDID idea above. Currently, we have > an option to force exposure of HMDs, but then they just look like normal > displays to userspace. That sounds entirely compatible -- when 'visible', the connected status becomes active again. > Is the discussion with Daniel Vetter captured somewhere so I can read > up on the objections? I couldn't find it with a naive Google or DRI > devel search. It was part of the kernel review of the proposed DRM lease mechanism: https://www.spinics.net/lists/dri-devel/msg154108.html > However, if there are one or two commands that could benefit from a > display connection, an alternative design would be to make an > extension that provides the connection info to those commands and > scope it's availability to Vulkan to be the duration of those > commands. Hrm. The device need not retain persistent access to the X connection; it could enumerate all of the resources necessary for the rest of the API each time it is called. Essentially, the application would need to call it each time it wanted to bring that cached information up to date. That seems like a bit of a bodge; the question is whether it's worth duplicating the enumeration APIs to avoid this. Here's a proposed list of APIs which would need to be duplicated with an additional argument: vkGetPhysicalDeviceDisplayPropertiesKHR vkGetPhysicalDeviceDisplayPlanePropertiesKHR vkGetDisplayPlaneSupportedDisplaysKHR vkGetDisplayModePropertiesKHR Note that we would have to duplicate these again to support another display server. > Note I still don't think it's a good idea to enumerate outputs not > reachable by the rendering device anyway, so I don't see this as a > positive for telling Vulkan more about X. Agreed -- that's a point in favor of having the enumeration done through the existing Vulkan API with the addition of a connection to the display server -- the Vulkan implementation would then be free to trim the list down to those devices it can reach. I've proposed adding a 'CONNECTOR_ID' property to each output in the xf86-video-modesetting driver so that Vulkan can map between X outputs and DRM connectors. I'd think the nVidia driver could do something similar so that it would know which X resources were reachable from the nVidia renderer. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
