On Sun, 2009-01-11 at 19:37 -0800, Matt Helsley wrote:
> Currently X, Y, and PRESSURE are special case axes in xf86-input-evdev.
> This patch supports axes in a more general way. There are a few open
> questions and TODOs:
> 
> TODO:
>       Add REL axes. Since we currently limit evdev devices to 
>               exclusively REL or ABS axes we can reuse the same vals 
>               buffer in the device structure.
> 
>       In theory there can be more than MAX_VALUATORS axes. Often there
>               will be less than MAX_VALUATORS axes. This either fails
>               to fully support a device or wastes a space. Should
>               probably switch to dynamically-allocated values but this
>               means we need an UnInit function.
> 
>       Needs testing. Currently I've only got devices that
>               support up to three axes. A nice Wacom tablet that
>               supports tilt might be able to test more axes with
>               some small testing-specific kernel/X driver hacks.
>               Any other ideas for testing?
> 
>       I'd like to move EvdevCacheCompare() above EvdevProbe() -- it
>               means we can get rid of all but the GRAB ioctls() from
>               EvdevProbe().
> 
>       Put back the button-as-ABS_PRESSURE test.
> 
> QUESTIONS:
>       Is this the only code that needs to test and count bits or can 
>               we make these pieces common somehow?
> 
>       There are still locations that special-case X and Y:

I forgot to finish the question here. Should we leave these as special
cases?

>               1. TOUCHPAD dx, dy calculation
>               2. Axis-swapping (would require an axis-mapping)
>               3. Axis-inversion
>               4. Calibration

<snip>

>       The swap, scale, inversion, and calibration transforms look like
>               they are done in the wrong order; we wind up using Y's
>               min and max to invert X if we've swapped the axes. I'd
>               think we'd want to swap later if not last...

And here: Am I just not thinking straight about these?

Does X have any layers to handle:
        REL <-> ABS conversion (switch_mode?)
        Axis inversion
        Other valuator transforms (e.g. calibration?)
        Axis mapping/swapping

in a more driver-agnostic way than using evdev-specific mechanisms? Also
I'd like to know how the calibration bits are meant to work. Can I get
any pointers to documentation/code on these parts?

Thanks!

Cheers,
        -Matt Helsley

_______________________________________________
xorg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xorg

Reply via email to