From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Ekstrand Subject: Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM Date: Fri, 23 Feb 2018 16:51:04 -0800 Message-ID: References: <20180210044516.16944-1-keithp@keithp.com> <20180210044516.16944-2-keithp@keithp.com> <87mv0aw3fw.fsf@keithp.com> <87sh9rqnlf.fsf@keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0805098041==" Return-path: In-Reply-To: <87sh9rqnlf.fsf@keithp.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mesa-dev-bounces@lists.freedesktop.org Sender: "mesa-dev" To: Keith Packard Cc: ML mesa-dev , Maling list - DRI developers List-Id: dri-devel@lists.freedesktop.org --===============0805098041== Content-Type: multipart/alternative; boundary="001a1143d698f5e6df0565eaab7e" --001a1143d698f5e6df0565eaab7e Content-Type: text/plain; charset="UTF-8" On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard wrote: > Jason Ekstrand 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. --001a1143d698f5e6df0565eaab7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 23, 2018 at 3:43 PM, Keith Packard <keithp@keithp.com> wrote:
Jason Ekstrand <jason@jlekstrand.net> writes:

> I think I like option 1 (KEITHP_kms_display).=C2=A0 If the client know= s the
> difference between render and primary for 2, then the= y are most likely
> already opening the master node themselves or at least have access to<= br> > the FD.

Ok, I'll work on cleaning up that extension and renaming it. I h= ave 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 enou= gh to the XML to reserve your extension number.=C2=A0 That will get merged = almost immediately.=C2=A0 Then make a second one with the actual extension = text and we'll iterate on that either in Khronos gitlab or, if you pref= er, you can send it as a patch to mesa-dev and then make a Khrons MR once i= t's baked.
=C2=A0
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 alr= eady
running, so at least we aren't running with a primary FD open?

See also my comments ab= out GEM handle ownership.
=C2=A0
> 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 u= se
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 d= on't
have it in a useful form except inside the X server and kernel.

Yeah, in the scary new wo= rld of Wayland compositors, having an edid library would be a very good thi= ng.=C2=A0 No sense in having everyone fail to handle it properly themselves= .
=C2=A0
> Yes, *if* it has a preferred resolution, we should return that one.=C2= =A0 If it
> doesn't, we should walk the list and return the largest instead of= just
> defaulting to 1024x768.=C2=A0 At least that's what the spec seems = to say to
> me.

Oh. I totally missed that part. Yeah, that's just wrong. I'v= e 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.=C2=A0 Let's just drop INHERIT and only advertise OPAQUE.

Done.

I've updated my drm-lease branch with all of these changes merged into<= br> 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. :-)=C2=A0 I figure I should learn something about KMS one day and = reviewing this is as good an opportunity as any.
--001a1143d698f5e6df0565eaab7e-- --===============0805098041== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVzYS1kZXYg bWFpbGluZyBsaXN0Cm1lc2EtZGV2QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21lc2EtZGV2Cg== --===============0805098041==--