> The application needs to know which parts of the controller map to which
> field anyway, right? So the protocol should define a standard for what
> goes where; certain physical inputs may be represented in multiple
> fields. Presumably for device-independence at the application level,
> all ranged inputs would be scaled to the same thing.
>
> So, for example, if all the inputs were 32-bit unsigned integers (big,
> but not too nasty for alphas), you'd have button-down be -1 (i.e.
> 0xffffffff) and button-up be 0. Then apps checking for clicks could
> just test for zero, while things which wanted pressure/velocity could
> test the actual value.
okay for the 32-bit everywhere... but we still need to know the
actual range used by the device. 0 is no pressure, 15 is 100% pressure.
The application need to know the range, unless the driver returns
something like 0x0fffffff for 50% pressure.
But I think that we must *NOT* standardize which axis goes where,
because it would limit us to what is standardized. If you says
X is field 1, Y is 2, Z is 3, pressure is 4... what will you do
when there will be a 4th axis, like rotation ? You just can't
forecast all the needed axis. Don't you agree ?
> You know, this is all starting to sound like a cross between a mouse
> protocol and MIDI...
I don't know MIDI... but you make me think about something
somewhat fun... test the power of unix (and the sound of
linux) : cat /vmlinuz > /dev/midi ...
each kernel is a piece of art ;-)
alex
-- \\-----------------------------------------------------------\\ // Alexandre Maret -- Linux : The choice of a GNU generation // \\ amaret@infomaniak.ch -- http://www.infomaniak.ch/~amaret \\ //-----------------------------------------------------------//