How to get xinput reflect evdev driver's absinfo changes ?

[Peter Hutterer]

On Fri, Jul 27, 2012 at 09:55:59PM +0200, Yann Cantin wrote:
> Hi,
> 
> I'm currently working on a kernel input driver for a pointing device that need runtime
> calibration.
> 
> The xorg evdev driver correctly detect and use it, my calibration app update evdev's
> absinfo with a :
> 
> prop = XInternAtom(display, "Evdev Axis Calibration", False);
> ...
> XIChangeProperty(display, device_id, prop, XA_INTEGER, 32, PropModeReplace, data.c, 4);
> 
> and the pointing device works like a charm.
> 
> But : when a do a
> 
> xinput --list --long 11
> 
> after calibration, i get that :
> 
> USB eBeam 2650:1311                             id=11   [slave  pointer  (2)]
>         Reporting 3 classes:
>                 Class originated from: 11
>                 Buttons supported: 5
>                 Button labels: Button Left Button Middle Button Right Button Wheel Up Button Wheel Down
>                 Button state:
>                 Class originated from: 11
>                 Detail for Valuator 0:
>                   Label: Abs X
>                   Range: 0.000000 - 65535.000000
>                   Resolution: 0 units/m
>                   Mode: absolute
>                   Current value: 22032.000000
>                 Class originated from: 11
>                 Detail for Valuator 1:
>                   Label: Abs Y
>                   Range: 0.000000 - 65535.000000
>                   Resolution: 0 units/m
>                   Mode: absolute
>                   Current value: 43433.000000
> 
> 
> See the Range ? that's still the data gathered when the device is probed, without calibration.
> After calibration, the ranges should be 0 - screen-width and 0 - screen-height (the kernel
> driver does the maths).
> 
> This isn't a show-stopper (device is working) but i suspect that the input layer play
> ping-pong with the valuators :
> 
> driver/evdev --  xinput -- screen
>   0-1279     -> 0-65535 -> 0-1279 
> 
> So, is there a way to adapt xinput's valuators, or even to entirely disable scaling, as the
> kernel driver will throw valid screen coordinates ?
 
the evdev driver updates the axis ranges internally, but the server has (for
historical reasons) no facilities to update the axis range of a device at
runtime yet. So evdev simply scales the new range into the given range. If
the kernel changes at runtime, evdev has no way to detect this, and afaik
there's no kernel API to be notified of this either.

Cheers,
   Peter