[PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

Jason Ekstrand <jason at jlekstrand.net> writes:

> I think I like option 1 (KEITHP_kms_display).  If the client knows the
> difference between render and primary for 2, then they are most likely
> already opening the master node themselves or at least have access to
> the FD.

Ok, I'll work on cleaning up that extension and renaming it. I have no
idea how to get new words into the Vulkan spec, but it would be good to
have that done too.

I guess the question is whether I should bother to leave the current
try-to-open-primary kludge in place. In good news, under X, both radv
and anv "fail" to use the primary device as another master is already
running, so at least we aren't running with a primary FD open?

> Sorry, I'm just not feeling all that opinionated about this at the moment.
> :-)

No more than I; either way is fine with me, if you're happy to use
something like the existing code I've got, that's even nicer.

> Clearly, we need systemd-edidd. :-)

A library would be nice; we have the edid data everywhere, we just don't
have it in a useful form except inside the X server and kernel.

> Yes, *if* it has a preferred resolution, we should return that one.  If it
> doesn't, we should walk the list and return the largest instead of just
> defaulting to 1024x768.  At least that's what the spec seems to say to
> me.

Oh. I totally missed that part. Yeah, that's just wrong. I've just
pushed a patch that finds the largest mode when there isn't a preferred
one. Oddly, I have no devices here which don't specify a preferred mode,
so it will be somewhat difficult to test...

> Yup.  Let's just drop INHERIT and only advertise OPAQUE.

Done.

I've updated my drm-lease branch with all of these changes merged into
the existing patches (and so noted), plus the new patch described above
which looks for the largest mode when no preferred mode is specified.

Thanks again for all of your careful review; while we haven't changed
any significant semantics, we have found a bunch of outright bugs in the
code.

-- 
-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/20180223/12a56491/attachment-0001.sig>