On Wed, 2019-01-16 at 20:35 +0200, Pekka Paalanen wrote: > 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. If the kernel wanted to expose its quirks db somehow the library could certainly be taught to use it. However there are likely to be quirks relevant only to userspace (see below), making the kernel carry that doesn't make a ton of sense. > 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... It's still not the worst idea, I'd be happy to revisit it. Part of the problem with the idea is that EDID parsing is not unambiguous. There are several fields for "physical output size" with slightly different semantics, which one do you want? There are both structured and free-form ways to encode monitor name and serial number. There are multiple ways to ask for 1920x1080, how many slightly different timings do you want? Some more-modern displays have DisplayID blocks too, which we're not fetching, and which can easily disagree with EDID; which version of reality would you like? Me personally I'm happy to make policy decisions about this kind of thing, but there are likely to be cases where a display server wants to make more subtle decisions, in which case it's likely to ignore any "cooked" queries you might of the library and instead try parsing the data itself. Many of these decisions currently don't affect the kernel at all (we don't use physical size for anything, but userspace thinks it wants to know about DPI...). > 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. This could be interesting. I'd half-written DDC/CI support for drm a while ago, which would allow us to expose that kind of thing. But to be broadly useful you'd want to mirror the same kind of knobs for like platform backlight control, and so far the kernel has steadfastly refused to believe it can possibly associate a backlight controller with a drm output in any userspace-useful way. - ajax _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
