While the basic Vulkan Display context can theoretically drive the
display without the involvement of any non-Vulkan code, that prevents
us from using VAAPI acceleration. When initialising VAAPI without a
window system, we need to provide it with an opened DRM render fd
corresponding to the device to use.
In the context of using VK_KHR_display, that means we need to identify
which DRM device matches the selected Vulkan device, and then open its
render fd and set the necessary state that VAAPI expects to find.
With that done, the normal VAAPI<->Vulkan interop can kick in and we
get working acceleration
If a plane is not connected to any displays, we won't set an entry in
the mapping of planes to displays. So ensure these unset entries are
null and skip them.
Fixes#8913
This is the Vulkan equivalent of the drm context for OpenGL, with
the big difference that it's implemented purely in terms of Vulkan
calls and doesn't actually require drm or kms.
The basic idea is to identify a display, mode, and plane on a device,
and then create a display backed surface for the swapchain. In theory,
past that point, everything is the same, and this is in fact the case
on Intel hardware. I can get a video playing on a vt.
On nvidia, naturally, things don't work that way. Instead, nvidia only
implemented the extension for scenarios where a VR application is
stealing a display from a running window system, and not for
standalone scenarios. With additional code, I've got this scenario to
work but that's a separate incremental change.
Other people have tested on AMD, and report roughly the same behaviour
as on Intel.
Note, that in this change, the VT will not be correctly restored after
qutting. The only way to restore the VT is to introduce some drm
specific code which I will illustrate in a separate change.
Christoph Heinrich