Griffin Powermate evdev setup

[Peter Hutterer]

On Wed, Apr 29, 2009 at 06:56:47AM -0500, David Hagood wrote:
> I'd like to ask a more general question about devices which, like the
> Powermate, don't really fit into either the "Keyboard" or "Pointing
> device" classes:
> 
> To what extent *should* X support these devices?
> 
> Let's examine a ShuttlePro - a jog wheel, a spinner, 15 buttons. It's
> not really a keyboard, as the buttons don't really have any defined
> mapping other than "Button 1" ... "Button 15". It's not a pointing
> device.
> 
> Applications like Kino recognize it and can use it to do editing
> control, in which case the jog wheel and the spinner are logically
> distinct from the mouse's wheel. Kino supports this device by going
> directly to the underlying /dev/input/event device, and not through X.
> 
> Now, that works - and perhaps that is how it should be: X concerns
> itself with pointers and keyboards, and we let other things be handled
> outside of X.
> 
> HOWEVER, that approach has several problems:
> 1) No remote access: I cannot run a program on another machine and have
> it use the Shuttle unless the Shuttle is supported by X.
> 2) No arbitration between applications: If Kino and some other program
> Foo both "understand" the Shuttle and want to use it, and I change input
> focus from Kino to Foo, how do we route the events correctly? Do the
> programs close the device when the lose input focus, and re-open it when
> the regain focus? Do they ignore events when not focused?
> 3) Less portable code - going to /dev/input/event5 may be fine under
> Linux, but is it supported under the *BSD kernels? under the Mac's X
> server? under Solaris/Irix/AIX?
> 
> You can generalize this to things like joysticks and game pads - as far
> as I can see, there is little difference between a Shuttle and my PS3
> DualShock as far as things like this go.
> 
> Has there been a design decision where support for devices like this
> should live?

evdev already does axis and button labelling, and that is built into XI2 so
that the server enforces it to some extent (still needs help by the driver of
course).

So if you have a device that only has REL_X, REL_Y, BTN_LEFT, BTN_BANANA, the
driver labels it accordingly and you can query this information by reading the
matching properties. All the client needs to do then is to map the
buttons/axes to the functionality as desired.
There's room for a global configuration in the desktop environment (e.g. make
REL_DIAL always map to scroll) but that's not really up for X to decide.
 
Cheers,
  Peter