[RFC][PATCH] General axis valuator support

[Matt Helsley]

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