On Wed, Jan 16, 2019 at 12:32:58PM -0800, Keith Packard wrote: > Adam Jackson <ajax@xxxxxxxxxx> writes: > > > 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. > > We do expose some of the quirks to user space, but not as a database, > and not consistently. Some of the quirks just match EDID data to drive > some decision (like non-desktop). Other quirks override some EDID data > that is 'wrong'. For these latter instances, I wonder if we shouldn't be > re-writing the EDID data that user space gets? Or at least making sure > the quirked values are available to user space? > > > 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. > > Hrm. For places where the kernel *does* parse the data, it would sure be > nice to have the kernel version to at least make that > consistent. Model/serial data used to select quirks seems like something > we should be exposing? > > I'm getting the feeling that either extreme approach (parse all of the > EDID data, or parse none of it) is not going to work and that our > current technique of picking some EDID-derived data to expose as > separate parsed values, and some to leave for user space to discover for > itself is where we'll be stuck for at least the near term. > > If we come to agreement that this approach is what we'll be doing, then > I'd like to have a couple of suggestions: > > 1) Document what we've got today Connector properties are documented here: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties I think we've caught up and have them all documented now, at least all the ones that have been standardized. There's not much, from a quick look we expose the following immutable props for userspace's benefit: EDID, PATH, TILE (this has been used for other composite screens, not just MST), non_desktop, "panel orientation". Plus vrr_capable, which is documented in a separate chapter. All the other properties are meant to be set, or not about parsing sink information. For all the other bits I think it'd be good to do a better job, but most likely we'll just muddle on. Exhibit A: The super consistent naming scheme for properties we have, see above :-) But in case we're going to do better, fully agree on documenting all this. -Daniel > 2) Document basic guidelines of when to expose parsed EDID-derived data > and when to just leave it in the EDID block for user space > > 3) Plan on exposing all values which the kernel *does* use internally > as parsed-out properties. Especially values which get quirked, > possibly exposing both the "raw" value and the "quirk" value. > > 4) Decide if we want to let user-space in on the quirking fun. I can > imagine a user-space helper that gets run at hot-plug time, reads > the EDID data and then pokes quirk values into the kernel. > > 5) Decide, as a matter of policy, whether the kernel will ever edit > EDID data that gets exposed to user space. I can think of good > reasons on both sides, but I think we need to hash out what the > kernel will do so that user space knows what's going on. > > I think what I want is for kernel and user space to at least be > operating on the same data, even if we end up re-implementing a pile of > code up in user space. > > -- > -keith > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
