On Thu, Jan 17, 2019 at 8:59 PM Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > > 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? We could also merge libdrm into the kernel ... Just as a wild idea to consider at least. I think it would also help in other areas, keeping the headers in sync, documenting the uapi properly, and all that. Would lockstep libdrm release with kernel releases, but most drivers+igt fixed that by just having copies of the headers in their tree. -Daniel > > 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
