[Mesa-dev] [PATCH 1/3] radv: Add VK_KHR_display, VK_KEITHP_kms_display and VK_EXT_direct_mode_display [v2]

[Keith Packard]

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.

-- 
-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.freedesktop.org/archives/mesa-dev/attachments/20170802/eb960d6e/attachment.sig>