From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Keith Packard" Subject: Re: Expose more EDID fields to userspace Date: Thu, 17 Jan 2019 13:36:45 -0800 Message-ID: <87munzufte.fsf@keithp.com> References: <20181224102300.GB30772@dvetter-linux.ger.corp.intel.com> <20190107100214.GY21184@phenom.ffwll.local> <87y37wmpdp.fsf@keithp.com> <20190107170708.rb4ewo7ufake2mwe@DESKTOP-E1NTVVP.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0757937022==" Return-path: Received: from elaine.keithp.com (home.keithp.com [63.227.221.253]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2D4E36F585 for ; Thu, 17 Jan 2019 21:36:47 +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: =?utf-8?Q?St=C3=A9phane?= Marchesin , Brian Starkey Cc: Simon Ser , nd , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org --===============0757937022== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable St=C3=A9phane Marchesin writes: > I don't have strong feelings for against this approach, but if we do this, > I think we should ensure we keep providing the original EDID to user spac= e. > The contents of EDIDs have so many implications that even the kernel isn't > always in the best position to decide if a rewrite is a good idea. Yeah, I think I've talked myself out of modifying EDID too. What I'm thinking this afternoon is that we should ensure that every value derived from EDID, (and potentially modified by the kernel), needs to be exposed to user space so that it too can play with the same information. If we could get a common EDID parsing library shared between kernel and user space, that would at least give everyone the same view of the data. > For a simple example, we can look at the max pixel clock which is reported > in the EDID. If the EDID gets rewritten with a lower pixel clock that > matches what the link can do, user space loses the ability to pop up a UI > dialog telling the user that if they were using a better cable, they could > get higher resolutions. Something similar already happens today with some > display dongles which decide to rewrite EDIDs based on their own > limitations. It prevents user space from showing a dialog recommending a > better dongle. Of course one could argue the dongle is protecting itself > here :) Oh, that's a fine point -- what this exposes is that user space should be able to see the lower pixel clock value which the kernel is using. And doing that separate from the EDID data means it can explain what's going on. > FWIW for Chrome OS we do parse the color space in user space, since as you > mention this isn't available through the DRM properties. If this isn't used by the kernel, then doing it in user space is probably the right plan. > Tangentially related, the content of these color points is often very... > "buggy". We have to do some sanity checking before deciding to use it or > not. That's why I think that even with all the information parsed by the > kernel, you still need another layer... Right, having a shared library and database for these kinds of quirks would be awesome. > Yes I like the idea of parsing in user space, since it doesn't require new > kernel changes at all, and typically updating a user space library is > simpler than changing kernel versions. Frankly it feels to me that the > kernel doesn't really have a business here except passing through the raw > EDID contents to a component which knows better. Agreed, as long as we also fix the kernel to tell user space what it's doing with the EDID data, especially where it's modifying values. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlxA9W0ACgkQ2yIaaQAA ABG1IxAAnkDzwsxjsEY9yrz8l6D6Sy8HdqjXndouZFUQ2LiuXrbuay9rhLWBfuol G0xY8RlamHViSj5XDUdwhN9A95Wl5gY6vDLhQr5LySz7aFSfZg4z/gZGx0R1YalY /OG/4JyLbAjCcOWf+Is1YTbD8LRF5VJTvtBNp2ssx6SP1ofJ2PAnG4yg9/yMeToI SiUvNdXNGnSEG0emmYp4S+PWsC/aR4DRVMfHSlYbn5Sp2FThqjMB6KU8V5goi15Y RO6iEIhh3h70wcIvd0Leoh5X4BxFjqNBH82KzfrWpEiYqerZESCBvKF6tHV4xduA 92fVFWo8abBwmZOjaHVdrngwuKSQg3qOKqhBXeZHJwblF51dWMJyXyI0Mhgzh4aA NUPfSj1czacxUmSkRyqQwxjXB4laCOdRAhpCXIYyHtqqnis5vLTJRbckCFWaLPjP NA6jxod83lI5m/i9EDFG+I5CKMLcYHcrfkLWt98xQ1hcMYLt64cXScMttMOltno7 mJPZ7Ekmu3Ni696jmYdVSNWS77go9jThs4kstqx+rJrDAKi5cMLg1tuL9KB1Fc0f XlYduPAYRw9Lkcx/5w8P45ZM3hlcIjb37QSaso/o1/FBWbNwlE24YWMWMHbgC4DL 9mThC0pS83XWOuiLXP8x5zIetHnYL1o/ejU1dyww6xMaCOqiKEo= =iD3R -----END PGP SIGNATURE----- --=-=-=-- --===============0757937022== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0757937022==--