Difference between revisions of "Evdev"

Revision as of 11:55, 19 December 2007

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). 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.)