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

[Jason Ekstrand]

On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard <keithp at keithp.com> wrote:

> 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.
>

Once we're sure that's what we want, create an MR against the spec that
just adds enough to the XML to reserve your extension number.  That will
get merged almost immediately.  Then make a second one with the actual
extension text and we'll iterate on that either in Khronos gitlab or, if
you prefer, you can send it as a patch to mesa-dev and then make a Khrons
MR once it's baked.


> 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?
>

See also my comments about GEM handle ownership.


> > 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.
>

Yeah, in the scary new world of Wayland compositors, having an edid library
would be a very good thing.  No sense in having everyone fail to handle it
properly themselves.


> > 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.
>

Glad to help. :-)  I figure I should learn something about KMS one day and
reviewing this is as good an opportunity as any.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180223/e4b373b7/attachment.html>