On Wed, Jan 16, 2019 at 1:35 PM Pekka Paalanen <ppaalanen@xxxxxxxxx> 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. Maybe make it part of libdrm and import the shared files periodically like we do for driver ioctl interfaces? Alex > > 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 > _______________________________________________ > 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
