On Wed, Jan 16, 2019 at 08:35:26PM +0200, Pekka Paalanen wrote: > On Mon, 7 Jan 2019 17:07:09 +0000 > Brian Starkey <Brian.Starkey@xxxxxxx> wrote: > > > 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 > > I would agree with an effort to establish a userspace EDID parsing > library in any case. As mentioned above, there will probably be too > much to expose via kernel UABI, or it will become just another > encoded format that again should have a shared parser library in > userspace. > > Would it be possible to architect the library so that it would be > shared with the kernel? Maybe the quirks database could be shared > with the kernel as well? That way both kernel and userspace would > more or less agree on the parsing details. IIRC long ago I did manage to build drm_edid.c in userspace. My idea was to potentially fuzz it without oopsing the kernel. But I didn't get beyond just making it build before getting distracted by something shinier. Taking that further would involve pulling the edid parser into a userspace helper entirely. Unfortunately that would open up the big can of "how do we parse the edid during boot?" worms. But I do kinda like the idea of not having the kernel parse untrusted input directly. -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
