From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Keith Packard" Subject: Re: [PATCH 1/3] drm: add connector info/property for non-std displays Date: Thu, 19 Oct 2017 09:27:32 -0700 Message-ID: <87d15jp0gb.fsf@keithp.com> References: <20171016042909.6901-1-airlied@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0172773785==" Return-path: Received: from elaine.keithp.com (home.keithp.com [63.227.221.253]) by gabe.freedesktop.org (Postfix) with ESMTP id A7EC86EAD7 for ; Thu, 19 Oct 2017 16:27:34 +0000 (UTC) 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: Daniel Stone , Dave Airlie Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0172773785== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Daniel Stone writes: > Why not add a client cap which hides 'non-standard' displays > completely from non-aware clients? That way you can keep the connected > status as is, and clients either never see the HMD or will be able to > check the property. Most clients are display servers, and it looks like we're settling on using the display server as the way to enumerate all of the displays (as direct enumeration through DRM non-master FDs involve rather drastic permissions changes in the kernel). This means that display servers are going to have to change to both see these displays while keeping them from being part of the desktop. So, while I guess it might be useful to hide HMD from existing display servers with a bit like this, I don't think there's any particular long-term benefit? > Either way, I'm still not convinced doing this in the kernel makes any > sense. fbdev. We want to keep the HMD dark until there's something 'real' to show on it. If you accept that fbdev needs to know this, then there's no way to avoid maintaining a database in the kernel. Maybe what we need is some way to load additional database entries into the kernel at boot time from a file in the initrd? And if you want a user-space database too, then maybe the kernel data should be generated from that and dumped into the initrd? One version of the truth is hard enough to deal with; I'd hate to have two. > We need the shared EDID library anyway in order to deal with the quirk > tables replicated between the kernel/Xorg currently, so that's going > to happen pretty soon regardless of whether or not the kernel gets its > own database. Yeah, we'll presumably need this support in the Vulkan KHR_display extension too, so sharing EDID support up in user space between all of these entities seems like a great idea. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlno0nQACgkQ2yIaaQAA ABGtqxAAnatMm7U/6W9gN/JYD/y5MYjqRGF/pYrRqk1x4ZyHz+w7K6gwfAxXzqlR T1VWQtz4Nmaf+UibiQgvwKrMJOa5rKfdur3CgU0e4O06HgMgHIQkuH3CboCSkCGZ MqhZE2knn654MUVDz2dVmpeOX5B74bVOn6/oxmeCYxlbojs2h2JmF1uYRnnJqCMq d2ipZYAbYwpfWWXo2QQIhv7SB3UIym5XoGnLcBo2dE2Bws5Zwjg29/Kl5+hdjInn BhZRd7ZWKmBXjEfWRWgMNH6VmU8/f9xkUFsgUSqOGNFCtAFpju+2/di7TaVVfgLo trfb6l77xn36w9vNzdAM3UjhKsJM+j3CN/Jka6y0HqU1T05+ioPDOwvoIDwbLDrh 5HWbgt1fJOh+qY13IPxjB+nEFCoFqjG7w3Ya9xEihBYYIPx4rxrYHzzo/0By9q5Z NjmMXoDRPqYfvuCZGVmYLonOr2vnSZvSuIIOgx9RR22ruJQOy5FZigiVlk6nB5u6 AnYCbN4f416I/Rjbs4keJNgoG1s9xuo718374/wmakaL1MsV8aEz59V/CZwB4DCq +HxMDnSmyyTDXkPWcxqL869If/h8/TgdV5wdC52yvv3AYqS8upCJs7KN+busGy8X wJQMoHzybZM46BhuRLhvFaUNGfmmr42tVfW3RkughWQ+fn5P5zc= =fwXC -----END PGP SIGNATURE----- --=-=-=-- --===============0172773785== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0172773785==--