Emil Velikov <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
