[PATCH 1/1] Adding VK_KHR_display to mesa based on KMS

Keith Packard keithp at keithp.com
Wed May 31 22:41:04 UTC 2017


As part of my adventures to implement 'DRM leases', it turns out to be
easiest to just implement 'real' VK_KHR_display in mesa now, rather than
a pile of ugly kludges. Because DRM leases just provide a DRM master
fd with limited resource access, mesa doesn't have to care whether you
provide a 'real' master or a lease.

That means all of the mesa code is separate from DRM leases, and can
also be used to run applications directly on bare hardware.

The implementation of the KHR_display extension lives pretty much
entirely within the common vulkan code in
src/vulkan/wsi/wsi_common_display.c

The driver functions in radv simply call those functions, which means
this should be 'trivial' to enable in the anv driver, but I haven't done
that work.

To get the master FD into the driver, I've created a new extension,
VK_KEITHP_kms_display which provides a DRM master file descriptor that
the driver uses in place of creating it's own render node file
descriptor. There's a bit of a dance involved in making sure we use the
right driver; that could probably be improved.

There are a few bits of unimplemented functionality within the
KHR_display implementation:

 1) I don't dig the monitor name out of EDID. I'm thinking this
    should be done by the kernel and exposed as a property. It already
    has the code for this...

 2) plane and surface capabilities are 'faked'. These expose the range
    of source surface sizes and positions which can be used; obviously
    the hardware can do a lot more than display an image at full size.

 3) Planes in general. I'm exposing only a single plane per connector at
    this point. Obviously we'd want more.

 4) bpp/depth. For now, I'm assuming depth 24, 32bpp. I think I just
    need a driver hook to get this out of the image; I sure don't want
    to try and parse the format.

I haven't rebased this in a while; it's a few revs back on master. I'm
looking for general feedback and comments about the plan at this point;
this is the second implementation of the code, I'm entirely willing to
do at least one more to make it 'right'.

git://people.freedesktop.org/~keithp/mesa.git   khr_display

There are also some simple changes in the vulkan looader (replicated in
the relevant files in mesa) needed to gain access to the
VK_KEITHP_kms_display extension (thanks, Vulkan, for not exposing vendor
instance extensions by default)

git://people.freedesktop.org/~keithp/Vulkan-LoaderAndValidationLayers.git drm-leases

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-VK_KHR_display-and-VK_KEITHP_kms_display-to-radv.patch
Type: text/x-diff
Size: 74592 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170531/834c773b/attachment-0001.patch>
-------------- next part --------------

-- 
-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/dri-devel/attachments/20170531/834c773b/attachment-0001.sig>


More information about the dri-devel mailing list