Stéphane Marchesin <stephane.marchesin@xxxxxxxxx> 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 space. > 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. -- -keith
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
