[PATCH evdev] Export device node as property.

Peter Hutterer peter.hutterer at who-t.net
Tue Feb 1 21:32:54 PST 2011


There is currently no mapping between XI devices and physical devices other
than what can be extracted by parsing the Xorg logfile. Add new property
"Device Node" to the driver to export the open device file.

The client is responsible for detecting if the device is on the same host
and converting the data into a more useful format (e.g. sysfs path).

Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
---
Got poked again for this at LCA. turns out what I asked Peter to do ages
ago isn't actually feasable. I wanted this to be in the server so the
drivers can share this property without re-implementation everywhere. Now,
this doesn't work as the server can read the 'Option "Device"' value but
there's no guarantee that the content of that is actually the device patch.
e.g. synaptics may use "auto-dev".

So here's a re-implementation that simply sets the property to the device
path the driver opened. Everything else is up to the client, it's quite
simple to get the sysfs path from the device node (about 5 lines with
libudev).

The bit that goes in the server is the property name so we can at least
"standardise" on that.

 man/evdev.man |    3 ++-
 src/evdev.c   |   22 +++++++++++++++++++++-
 src/evdev.h   |    4 ++++
 3 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/man/evdev.man b/man/evdev.man
index adb3f8d..a202ae8 100644
--- a/man/evdev.man
+++ b/man/evdev.man
@@ -66,7 +66,8 @@ is used. Buttons not specified in the user's mapping use the default mapping.
 .BI "Option \*qDevice\*q \*q" string \*q
 Specifies the device through which the device can be accessed.  This will 
 generally be of the form \*q/dev/input/eventX\*q, where X is some integer.
-The mapping from device node to hardware is system-dependent.
+The mapping from device node to hardware is system-dependent. Property:
+"Device Node" (read-only).
 .TP 7
 .BI "Option \*qDragLockButtons\*q \*q" "L1 B2 L3 B4" \*q
 Sets \*qdrag lock buttons\*q that simulate holding a button down, so
diff --git a/src/evdev.c b/src/evdev.c
index 74dd04d..9f8e003 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -113,6 +113,7 @@ static Atom prop_calibration;
 static Atom prop_swap;
 static Atom prop_axis_label;
 static Atom prop_btn_label;
+static Atom prop_device;
 
 /* All devices the evdev driver has allocated and knows about.
  * MAXDEVICES is safe as null-terminated array, as two devices (VCP and VCK)
@@ -2200,6 +2201,23 @@ EvdevInitProperty(DeviceIntPtr dev)
     EvdevPtr     pEvdev = pInfo->private;
     int          rc;
     BOOL         invert[2];
+    char         *device_node;
+
+    /* Device node property */
+    device_node = strdup(pEvdev->device);
+    prop_device = MakeAtom(XI_PROP_DEVICE_NODE,
+                           strlen(XI_PROP_DEVICE_NODE), TRUE);
+    rc = XIChangeDeviceProperty(dev, prop_device, XA_STRING, 8,
+                                PropModeReplace,
+                                strlen(device_node), device_node,
+                                FALSE);
+    free(device_node);
+
+    if (rc != Success)
+        return;
+
+    XISetDevicePropertyDeletable(dev, prop_device, FALSE);
+
 
     if (pEvdev->flags & (EVDEV_RELATIVE_EVENTS | EVDEV_ABSOLUTE_EVENTS))
     {
@@ -2278,7 +2296,9 @@ EvdevSetProperty(DeviceIntPtr dev, Atom atom, XIPropertyValuePtr val,
     InputInfoPtr pInfo  = dev->public.devicePrivate;
     EvdevPtr     pEvdev = pInfo->private;
 
-    if (atom == prop_invert)
+    if (atom == prop_device)
+        return BadValue;
+    else if (atom == prop_invert)
     {
         BOOL* data;
         if (val->format != 8 || val->size != 2 || val->type != XA_INTEGER)
diff --git a/src/evdev.h b/src/evdev.h
index e68f7f2..73c9acb 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -80,6 +80,10 @@
 #define MAX_VALUATORS 36
 #endif
 
+#ifndef XI_PROP_DEVICE_NODE
+#define XI_PROP_DEVICE_NODE "Device Node"
+#endif
+
 #define LONG_BITS (sizeof(long) * 8)
 
 /* Number of longs needed to hold the given number of bits */
-- 
1.7.3.5



More information about the xorg-devel mailing list