(→X11 evdev driver) |
|||
(One intermediate revision by the same user not shown) | |||
Line 122: | Line 122: | ||
==[http://www.bedroomlan.org/~alexios/coding_evrouter.html evrouter] and the Griffin Powermate== | ==[http://www.bedroomlan.org/~alexios/coding_evrouter.html evrouter] and the Griffin Powermate== | ||
− | Let's say you have two of them and you want to use one for horizontal scrolling and one for vertical (like an etch-a-sketch, heh). Create ~/.evrouterrc like this: | + | Let's say you have two of them and you want to use one for horizontal scrolling and one for vertical (like an etch-a-sketch, heh). And you want to map the "buttons" to generate key events instead of mouse-like button clicks. (This is something the X11 evdev driver cannot be configured to do.) Create ~/.evrouterrc like this: |
<pre> | <pre> | ||
"Griffin PowerMate" "event7" any key/256 "XKey/KP_Enter" | "Griffin PowerMate" "event7" any key/256 "XKey/KP_Enter" | ||
Line 137: | Line 137: | ||
</pre> | </pre> | ||
It's possible to avoid using the actual /dev/input/event nodes but then how to tell the two apart? It's not like they have serial numbers. (They ought to... it would make things easier.) | It's possible to avoid using the actual /dev/input/event nodes but then how to tell the two apart? It's not like they have serial numbers. (They ought to... it would make things easier.) | ||
+ | |||
+ | ==Find processes which are already reading input devices== | ||
+ | find /proc -lname "/dev/input*" | xargs ls -al |
Latest revision as of 09:56, 4 January 2012
X11 evdev driver
Here are some kludgy hacks for the X11 evdev 1.1.5 driver.
The Griffin Powermate has issues because it's detected as having 17 buttons (16 directions of rotation plus one actual button, apparently.) This patch hardcodes the last button as being the first (button 1):
--- /mnt/other-gentoo/usr/src/xf86-input-evdev-1.1.5/src/evdev_btn.c 2007-11-28 14:50:17.000000000 -0700 +++ src/evdev_btn.c 2007-12-12 16:36:04.000000000 -0700 @@ -161,7 +161,10 @@ map = Xcalloc (sizeof (CARD8) * (pEvdev->state.btn->buttons + 1)); for (i = 0; i <= pEvdev->state.btn->buttons; i++) - map[i] = i; + if (i == 19) + map[i] = 2; + else + map[i] = i; xf86Msg(X_CONFIG, "%s (%d): Registering %d buttons.\n", __FILE__, __LINE__, pEvdev->state.btn->buttons); @@ -187,8 +190,8 @@ return Success; blocked = xf86BlockSIGIO (); -// for (i = 1; i <= pEvdev->state.btn->buttons; i++) - xf86PostButtonEvent (device, 0, 1, 0, 0, 0); + for (i = 1; i <= pEvdev->state.btn->buttons; i++) + xf86PostButtonEvent (device, 0, i, 0, 0, 0); xf86UnblockSIGIO (blocked); return Success; @@ -332,7 +335,7 @@ state->btn->callback[button](pInfo, button, ev->value); button = state->btn->map[button]; - xf86PostButtonEvent (pInfo->dev, 0, 1, ev->value, 0, 0); + xf86PostButtonEvent (pInfo->dev, 0, button, ev->value, 0, 0); } int
The Toughbook CF-28 touchscreen's extents are misreported at some level; this patch hardcodes them to values I determined experimentally on one particular machine:
--- /root/xf86-input-evdev-1.1.5/src/evdev_axes.c 2007-12-12 16:34:15.000000000 -0700 +++ xf86-input-evdev-1.1.5/src/evdev_axes.c 2007-11-28 14:37:19.000000000 -0700 @@ -49,7 +49,7 @@ #include <xf86_OSproc.h> -#undef DEBUG +#define DEBUG 1 static char *rel_axis_names[] = { "X", @@ -232,8 +232,10 @@ xf86Msg(X_ERROR, "ioctl EVIOCGABS (%d) failed: %s\n", i, strerror(errno)); continue; } - state->abs->min[state->abs->map[i]] = absinfo.minimum; - state->abs->max[state->abs->map[i]] = absinfo.maximum; +// state->abs->min[state->abs->map[i]] = absinfo.minimum; +// state->abs->max[state->abs->map[i]] = absinfo.maximum; + state->abs->min[state->abs->map[i]] = (i == 0 ? 140 : 284); + state->abs->max[state->abs->map[i]] = (i == 0 ? 3810 : 3904); } } @@ -278,10 +280,12 @@ int conv_x, conv_y; for (i = 0; i < 2; i++) + { + xf86Msg(X_CONFIG, "scale[%d]: %d.\n", i, state->abs->scale[i]); state->axes->v[i] = xf86ScaleAxis (state->abs->v[i], 0, state->abs->scale[i], - state->abs->min[i], state->abs->max[i]); - + (i == 0 ? 140 : 284), (i == 0 ? 3810 : 3904)); + } EvdevConvert (pInfo, 0, 2, state->abs->v[0], state->abs->v[1], 0, 0, 0, 0, &conv_x, &conv_y); @@ -437,8 +441,12 @@ xf86Msg(X_ERROR, "ioctl EVIOCGABS failed: %s\n", strerror(errno)); return !Success; } - state->abs->min[state->abs->map[i]] = absinfo.minimum; - state->abs->max[state->abs->map[i]] = absinfo.maximum; + //state->abs->min[state->abs->map[i]] = absinfo.minimum; + //state->abs->max[state->abs->map[i]] = absinfo.maximum; + + state->abs->min[state->abs->map[i]] = (i == 0 ? 140 : 284); + state->abs->max[state->abs->map[i]] = (i == 0 ? 3810 : 3904); + j++; } @@ -506,7 +514,9 @@ xf86Msg(X_CONFIG, "%s: AbsoluteScreen: %d.\n", pInfo->name, k); state->abs->scale[0] = screenInfo.screens[state->abs->screen]->width; + xf86Msg(X_CONFIG, "%s: scale[0]: %d.\n", pInfo->name, state->abs->scale[0]); state->abs->scale[1] = screenInfo.screens[state->abs->screen]->height; + xf86Msg(X_CONFIG, "%s: scale[1]: %d.\n", pInfo->name, state->abs->scale[1]); } else { if (k != -1) xf86Msg(X_CONFIG, "%s: AbsoluteScreen: %d is not a valid screen.\n", pInfo->name, k); @@ -683,7 +693,7 @@ return !Success; for (i = 0; i < axes; i++) { - xf86InitValuatorAxisStruct(device, i, -1, -1, 0, 0, 1); + xf86InitValuatorAxisStruct(device, i, 0, -1, 0, 0, 1); xf86InitValuatorDefaults(device, i); }
Neither of the above patches are production-quality - just quick hacks to make it work for now. There is already a newer version of the evdev driver (1.2.0) which is rather differently written (somewhat more difficult to hard-code hacks like these), and I have not yet figured out proper solutions to these issues.
evrouter and the Griffin Powermate
Let's say you have two of them and you want to use one for horizontal scrolling and one for vertical (like an etch-a-sketch, heh). And you want to map the "buttons" to generate key events instead of mouse-like button clicks. (This is something the X11 evdev driver cannot be configured to do.) Create ~/.evrouterrc like this:
"Griffin PowerMate" "event7" any key/256 "XKey/KP_Enter" "Griffin PowerMate" "event7" any rel/7/-1 "XButton/6" "Griffin PowerMate" "event7" any rel/7/1 "XButton/7" "Griffin PowerMate" "event8" any key/256 "XKey/Return" "Griffin PowerMate" "event8" any rel/7/-1 "XButton/4" "Griffin PowerMate" "event8" any rel/7/1 "XButton/5"
And to auto-run it in KDE, create ~/.kde/Autostart/evrouter.sh:
#!/bin/bash /usr/local/bin/evrouter /dev/input/event8 /dev/input/event7
It's possible to avoid using the actual /dev/input/event nodes but then how to tell the two apart? It's not like they have serial numbers. (They ought to... it would make things easier.)
Find processes which are already reading input devices
find /proc -lname "/dev/input*" | xargs ls -al