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. I've been dreaming of a "liboutput" that would e.g. parse EDID, generate CVT video mode timings, and whatnot that all display servers more or less will duplicate. Once upon a time Ajax started minitru IIRC... Another thing for "liboutput" was a device description database, whose first use would have been the "non-desktop" property. Because we don't expose monitors through udev to have udev rules tag them with interesting bits. Imagine this: monitors exposed as devices via udev, tagged with helpers as regular monitor, HMD, TV, projector, ... and all EDID fields decoded as well. And quirks in hwdb. But I suppose that won't happen, because a "monitor device node" would have no other use. Except... programmatical monitor controls? Like backlight, brightness, contrast, and so on. Ah, nevermind. :-) Thanks, pq
Attachment:
pgp8XH4YcijfC.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
