From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Keith Packard" Subject: Re: Expose more EDID fields to userspace Date: Mon, 07 Jan 2019 07:57:54 -0800 Message-ID: <87y37wmpdp.fsf@keithp.com> References: <20181224102300.GB30772@dvetter-linux.ger.corp.intel.com> <20190107100214.GY21184@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1148160312==" Return-path: Received: from elaine.keithp.com (home.keithp.com [63.227.221.253]) by gabe.freedesktop.org (Postfix) with ESMTPS id DBF2E6E7F4 for ; Mon, 7 Jan 2019 15:57:55 +0000 (UTC) In-Reply-To: <20190107100214.GY21184@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter , Simon Ser Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org --===============1148160312== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Daniel Vetter writes: > Best to pull in some other compositor people and get them to agree. From a > kernel pov I'm fine with whatever userspace preferes. Hrm. It would be good to have everyone using the same interpretation of EDID data; in particular, where the kernel has quirks that change the interpretation, user space should be consistent with that. Unless we expose all of the EDID data, then user space may still have to parse EDID. If the kernel has EDID quirks, it might be good to to make those affect the "raw" EDID data visible to use space so that values the kernel supplies separately are consistent with values extracted from the "raw" EDID data. Doing this in the kernel does make it harder to quickly supply fixes for a specific user space application. This will probably lead to kludge-arounds in user space that could depend on kernel version. Perhaps these EDID capabilities in the kernel should be versioned separately? I see good benefits from having user space able to see how the kernel is interpreting EDID so that it can adapt as appropriate, but we should be cautious about moving functionality into the kernel that would be more easily maintained up in user space. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlwzdwIACgkQ2yIaaQAA ABFLKQ//cfnB03kRu5TkFBLU1MoG/nQMw8Ke3wu2ryLjoffYhp70uKOTB9AxSxEu 1DSODCutSkOrvZjxN/xWjblTPhy4Ud2A764PMs/Np+0uKEZ0aAfby+0qJMEp4X3o T07DMRxUipHtfUenJyj/rX8WMipgniEPp3TWbZ13MBLLbEPPvigE+ybnpjbx0UHK zCIiBRwWN4NMImMBWex/LQpiE2LKFr1zn9AcIQfpQP8xzrDThqNOSd3cXoGtixgn +PC9EKaJi1MP778RcjWgKq1qH8YY3+mUrRR3EF3DNxw96QyrH8Ne4bVkW5MarADr CjRmgGAdtqzbfGWGeafYiahz3jC4vYwNtnbqaGVWNnV2hC8kPO/6XDPbq9MLQb0D 4pdBliMTqk/Y/s1KfAN3yHxlxQ8LKfxmJxUzsCnorT2fV5E4M08BcDev1EYishzZ A76ySR++o1yj66Oc7paGVgVvnn5Vk2be0y++lMoAEmxbbyiozUBw0nxoPLCxYCpp o9m5BjHlYibk9MpF9Z9hCttn6lQl2wYI7TcvxttRcsa0c/yf2gRf9T9BJ7y0InqL PHZlTDu1ciatZeBWLlgvZ1vYcw0J5CJgjOdoRifi8zQBdmy8jmw6iV3eBom6z0FW hIEh/jn8ZFzKbyT6zaEmGboYJzAuHTAD4rUHNM6ldhqDOtGR+mk= =0r8G -----END PGP SIGNATURE----- --=-=-=-- --===============1148160312== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1148160312==--