[Mesa-dev] [PATCH 1/3] radv: Add VK_KHR_display, VK_KEITHP_kms_display and VK_EXT_direct_mode_display [v2]
keithp at keithp.com
Wed Aug 2 18:30:13 UTC 2017
Emil Velikov <emil.l.velikov at gmail.com> writes:
> Is the VK_KEITHP_kms_display spec available somewhere?
I haven't written one yet. I'll go draft one.
> Since there are multiple companies [participating in Mesa] with
> Khronos membership, could we make this an EXT extension? Once
> everything else is settled in, of course.
I'm easy; I didn't want to step on any namespace toes, so I picked
something else. Can I just assert EXT for the name and be ok?
> I think it makes sense to spit the VK_KHR_display +
> VK_EXT_direct_mode_display bits from the patch. AFAICT they're used by
> 2/3 and 3/3 which are already well defined extensions.
You can't use VK_KHR_display+VK_EXT_direct_mode_display without one of
VK_KEITHP_kms_display or VK_EXT_acquire_xlib_display as the latter two
extensions are how you actually get a VkDisplayKHR device, so I'm not
sure it would be useful to split those apart?
> This way we could land them, while the new extension [and kernel bits]
> are being refined.
VK_KEITHP_kms_display doesn't depend on the kernel bits; it just
requires that the application open the kernel
device. VK_EXT_acquire_xlib_display does depend on the kernel changes,
but only through the X extension which is where the 'lease'
originates. So, that's a pretty long dependency chain.
I should reconstruct my kms_display demo so that it doesn't use a lease;
right now, the application does all of the X stuff itself to create a
leased DRM master, but it could just open /dev/dri/card0. That would
provide a simple test case for the first patch which was independent of
the X server and kernel.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the mesa-dev