From Electron Cloud
Jump to: navigation, search
([http://www.bedroomlan.org/~alexios/coding_evrouter.html evrouter] and the Griffin Powermate)
 
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