From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Keith Packard" Subject: Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM Date: Fri, 23 Feb 2018 15:43:08 -0800 Message-ID: <87sh9rqnlf.fsf@keithp.com> References: <20180210044516.16944-1-keithp@keithp.com> <20180210044516.16944-2-keithp@keithp.com> <87mv0aw3fw.fsf@keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1527860131==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jason Ekstrand Cc: ML mesa-dev , Maling list - DRI developers List-Id: dri-devel@lists.freedesktop.org --===============1527860131== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. 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. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlqQpwwACgkQ2yIaaQAA ABFpUhAAofQXz9hkbBoyWYONDAjtDYmBroNxhyIrayAyhyhXTIoBLX/bNV8kP40w RSdqVMxWuaHXM4MEloWiD0faD0kUb1l7Gc3NvoSGIKxSXUgX2GYDvWiHFyuSARYk BstTU5748U/SDdJOkGRk7e7XNOPnSSqjx4T3mbD5xCRaHyWdyp5TZxyJdvBhQB0N xZ1U4pSxMdL72YfADLtqwQxlLrrgQ2yoMzUZRrH8YJp1XHNbVMox6+pkFdAIfyza 3D6Lv5/41i2QwLi+DsakxBy5/Szn7/zu4M7nHRH1FnMvYNfe78P691dzmrmKDYYY vHHDaMyHna7mjs4Jlg12ohCcs7gIy0hH8qaS7Uj1NeZeL35iPnLNzQimzfplPeAs QgT9vS0SjSxq2tvpzFkd8pCAozVk6Vji26fkfR0fC+g7cCr/9eOnt8nVia402doi pLFtqXENxyv9qEpoHu0HjYPOWe0gXF2oyKIdvMBr+Ng0R63cMC3RDlqlgccBbUHI rMunn4nkaxwTjl3gANQiHxLtcSX8gydJdGZ2xLSeR7Dvz90qF0p6d4XTYpSbS4zu sfUGhPd9pksCGTeIR9WoVQ5RA9tBxN3wmw8QpgAfIbRilxcVp1CkLzayCNujl2pJ hTqlod0lTaXCMmm8buRvZeCZgbtF+p1PnVQVos3UQdI97vhXnPE= =1uGM -----END PGP SIGNATURE----- --=-=-=-- --===============1527860131== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1527860131==--