[systemd-devel] [RFC PATCH] udev: add an "abs-override" builtin to override EV_ABS data

[Peter Hutterer]

On Thu, Mar 19, 2015 at 01:54:46PM +0100, David Herrmann wrote:
> Hi
> 
> On Thu, Mar 19, 2015 at 10:52 AM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > This builtin parses properties in the form
> > EV_ABS_OVERRIDE_00="<min>:<max>:<res>:<fuzz>:<flat>"
> 
> The concept sounds good. hwdb is definitely the place to put this,
> rather than static kernel fixups.
> 
> > and applies them to the kernel device. Future processes that open that device
> > will see the updated EV_ABS range.
> >
> > This is particularly useful for touchpads that don't provide a resolution in
> > the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974).
> >
> > All values in the property are optional, e.g. a string of "::45" is valid to
> > set the resolution to 45.
> >
> > The order intentionally orders resolution before fuzz and flat despite it
> > being the last element in the absinfo struct. The use-case for setting
> > fuzz/flat is almost non-existent, resolution is probably the most common case
> > we'll need.
> 
> If a field is left empty, should it take the kernel-provided values?
> This way, you could just order it logically and leave stuff you don't
> wanna change empty.

yeah, it does that anyway (which is why the parser looks a bit weird), but
the basic principle is: fetch absinfo from device, update any value given in
the property, reload absinfo to device. Any missing value will simply be
ignored, so the example of ::45 really only updates the resolution and
leaves the rest as-is.

if we leave the order as in the absinfo, a resolution update would be
::::45. given that I don't expect the fuzz/flat to ever be updated that only
adds a source for bugs (and I suspect most ppl would think of an axis in
terms of min/max/resolution anyway).

> > ---
> > This is just an RFC for now, a couple of questions remain:
> > * we need this for touchpads, but this seems something that could be more
> >   generic and have it's own ruleset, possibly depending on ID_INPUT_TOUCH*
> >   or so
> > * input_id is already called and opens the device, we could merge this in
> >   there
> 
> Don't get confused by the name of this builtin. It's legacy. We should
> probably also merge 'keyboard' into it.
> 
> Talking about the 'keyboard' builtin: why not merge both? They serve
> the same purpose, fixing wrong kernel mapping/data. You could even
> rename the prefix to "evdev" ('input' is reserved..), and then put
> both into the same file. You could re-use the matching we have in
> place for keyboards. I think it would work well enough for all other
> input-devices, too. It uses the input-modalias, and device-name+dmi as
> fallback. Ok, the "atkbd:" is special to keyboards, but just ignore
> it.

ack, will send the patches asap.

Cheers,
   Peter