On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote: > Daniel Vetter <daniel@xxxxxxxx> 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. If the quirks can be re-encoded back into an EDID representation, then this sounds like a fairly good approach to me. > > 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. > I agree. It seems likely that whatever happens (some) userspace is still going to implement (some) EDID parsing functionality, so it's hard to reason about what belongs where. Shared code in userspace (libdrm?) may well be better than exposing it from the kernel. If it is exposed by the kernel, then it's still non-obvious to me how the kernel exposes that information/interpretation. Adding a property for every potentially-useful field really doesn't scale well, and what fields are useful isn't obvious - e.g. serial string vs serial no., as mentioned by Simon. Uma's recent series: "Add HDR Metadata Parsing and handling in DRM layer"[1] is a good example of more stuff which userspace would want to parse out of the EDID (supported display colorimetry and transfer functions). It would be nice to avoid duplicating all the CEA extension parsing code, but the EDID/CEA data structure is extensible by design. So the kernel API would need to be similarly extensible, or we'll just balloon loads of properties... and then the kernel API would likely just end up just looking similar to the CEA block anyway. Cheers, -Brian [1] https://lists.freedesktop.org/archives/dri-devel/2018-December/200154.html > -- > -keith > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
