to drivers/input/evdev.c to add mixer device "/dev/input/events"

I, and a growing number of others, have been having trouble with using touch screen devices in Linux, particularly the motorized ones that fit into car dashboards. The problem is that these devices, which have a USB touchscreen (often the eGalax brand), turn off when the screen is retracted, causing Linux to remove and/or disconnect the event device in /dev/input.

Using udev to assign a persistent symlink to the device was the first thing I tried, but it does not solve the problem, since X windows does not see the device when it turns back on, even if it's the same name. I (and others) have tried hacks like changing virtual terminals, etc. to get it back, but these are not elegant solutions are are problematic.

Anyway, I finally decided the thing I needed was something like /dev/input/mice, since it is always there for X to see, even if the device is off during boot. But the mousedev devices are not the right data format for use with the touch screens (you need "event" ones). So I hacked evdev.c and added "/dev/input/events", which is a mixer as well and catches all events from event0, event1, etc.

This works great, and I think it would be a great addition to the Linux kernel. I would like to submit this patch, and I hope it can be made a part of the Linux kernel. However, I would feel more comfortable if someone (the maintainer?) could look over my changes and verify that they are done correctly. I had a few open questions that resulted from the fact that evdev is slightly different than mousedev:

For example, in evdev_open, I had to check evdev->handle.dev for non-zero before making the input call (evdev_mix has a zero in this pointer), or of course I would get a seg fault. I also got a lockup later that I fixed by making other similar checks for a zero handle.dev, but since these checks were not necessary in mousedev, I would like to verify that this is the correct way to deal with it.

Another thing is the "grab" concept in evdev. I check for handle.dev to be non-zero before I let grab get set, and I do not know every aspect of the grab mechanism, so I hope this is the right thing to do.

Anyway, I hope my change is valuable. I (and others) would love to see it appear in the official kernel source. I attached the patch.

Thanks, Joe

@@ -8,8 +8,17 @@
  * the Free Software Foundation.
  */
 
+/*
+ * Modified 2005-8-12  Joe Peterson
+ *
+ *     - Added persistent mixer device "/dev/input/events"
+ *       (analogous to mousedev.c's "/dev/input/mice")
+ *
+ */
+
 #define EVDEV_MINOR_BASE	64
 #define EVDEV_MINORS		32
+#define EVDEV_MIX               31
 #define EVDEV_BUFFER_SIZE	64
 
 #include <linux/poll.h>

@@ -42,11 +51,13 @@ struct evdev_list {
 	struct list_head node;
 };
 
+static struct input_handler evdev_handler;
+
 static struct evdev *evdev_table[EVDEV_MINORS];
+static struct evdev evdev_mix;
 
-static void evdev_event(struct input_handle *handle, unsigned int type, unsigned int code, int value)
+static void evdev_handle_event(struct evdev *evdev, unsigned int type, unsigned int code, int value)
 {
-	struct evdev *evdev = handle->private;
 	struct evdev_list *list;
 
 	if (evdev->grab) {

@@ -74,6 +85,14 @@ static void evdev_event(struct input_han
 	wake_up_interruptible(&evdev->wait);
 }
 
+static void evdev_event(struct input_handle *handle, unsigned int type, unsigned int code, int value)
+{
+	struct evdev *evdev = handle->private;
+
+        evdev_handle_event(evdev, type, code, value);
+        evdev_handle_event(&evdev_mix, type, code, value);
+}
+
 static int evdev_fasync(int fd, struct file *file, int on)
 {
 	int retval;

@@ -86,7 +105,10 @@ static int evdev_flush(struct file * fil
 {
 	struct evdev_list *list = file->private_data;
 	if (!list->evdev->exist) return -ENODEV;
-	return input_flush_device(&list->evdev->handle, file);
+        if (list->evdev->handle.dev)
+            return input_flush_device(&list->evdev->handle, file);
+        else
+            return 0;
 }
 
 static void evdev_free(struct evdev *evdev)

@@ -95,6 +117,24 @@ static void evdev_free(struct evdev *evd
 	kfree(evdev);
 }
 
+static int mixdev_release(void)
+{
+	struct input_handle *handle;
+
+	list_for_each_entry(handle, &evdev_handler.h_list, h_node) {
+		struct evdev *evdev = handle->private;
+
+		if (!evdev->open) {
+			if (evdev->exist)
+				input_close_device(&evdev->handle);
+			else
+				evdev_free(evdev);
+		}
+	}
+
+	return 0;
+}
+
 static int evdev_release(struct inode * inode, struct file * file)
 {
 	struct evdev_list *list = file->private_data;

@@ -108,10 +148,15 @@ static int evdev_release(struct inode * 
 	list_del(&list->node);
 
 	if (!--list->evdev->open) {
-		if (list->evdev->exist)
-			input_close_device(&list->evdev->handle);
-		else
-			evdev_free(list->evdev);
+		if (list->evdev->minor == EVDEV_MIX)
+			return mixdev_release();
+
+		if (!evdev_mix.open) {
+			if (list->evdev->exist)
+				input_close_device(&list->evdev->handle);
+			else
+				evdev_free(list->evdev);
+		}
 	}
 
 	kfree(list);

@@ -121,13 +166,16 @@ static int evdev_release(struct inode * 
 static int evdev_open(struct inode * inode, struct file * file)
 {
 	struct evdev_list *list;
+	struct input_handle *handle;
+	struct evdev *evdev;
 	int i = iminor(inode) - EVDEV_MINOR_BASE;
 	int accept_err;
 
 	if (i >= EVDEV_MINORS || !evdev_table[i] || !evdev_table[i]->exist)
 		return -ENODEV;
 
-	if ((accept_err = input_accept_process(&(evdev_table[i]->handle), file)))
+        if (evdev_table[i]->handle.dev)
+            if ((accept_err = input_accept_process(&(evdev_table[i]->handle), file)))
 		return accept_err;
 
 	if (!(list = kmalloc(sizeof(struct evdev_list), GFP_KERNEL)))

@@ -138,10 +186,18 @@ static int evdev_open(struct inode * ino
 	list_add_tail(&list->node, &evdev_table[i]->list);
 	file->private_data = list;
 
-	if (!list->evdev->open++)
-		if (list->evdev->exist)
-			input_open_device(&list->evdev->handle);
-
+	if (!list->evdev->open++) {
+		if (list->evdev->minor == EVDEV_MIX) {
+			list_for_each_entry(handle, &evdev_handler.h_list, h_node) {
+				evdev = handle->private;
+				if (!evdev->open && evdev->exist)
+					input_open_device(handle);
+			}
+		} else
+			if (!evdev_mix.open && list->evdev->exist)
+				input_open_device(&list->evdev->handle);
+        }
+        
 	return 0;
 }
 

@@ -157,7 +213,8 @@ static ssize_t evdev_write(struct file *
 
 		if (copy_from_user(&event, buffer + retval, sizeof(struct input_event)))
 			return -EFAULT;
-		input_event(list->evdev->handle.dev, event.type, event.code, event.value);
+                if (list->evdev->handle.dev)
+                    input_event(list->evdev->handle.dev, event.type, event.code, event.value);
 		retval += sizeof(struct input_event);
 	}
 

@@ -268,20 +325,24 @@ static int evdev_ioctl(struct inode *ino
 			return 0;
 
 		case EVIOCGRAB:
-			if (arg) {
+                        if (evdev->handle.dev) {
+                            if (arg) {
 				if (evdev->grab)
 					return -EBUSY;
 				if (input_grab_device(&evdev->handle))
 					return -EBUSY;
 				evdev->grab = list;
 				return 0;
-			} else {
+			    } else {
 				if (evdev->grab != list)
 					return -EINVAL;
 				input_release_device(&evdev->handle);
 				evdev->grab = NULL;
 				return 0;
-			}
+			    }
+                        } else {
+                            return 0;
+                        }
 
 		default:
 

@@ -427,6 +488,9 @@ static struct input_handle *evdev_connec
 	evdev->handle.private = evdev;
 	sprintf(evdev->name, "event%d", minor);
 
+	if (evdev_mix.open)
+		input_open_device(&evdev->handle);
+
 	evdev_table[minor] = evdev;
 
 	devfs_mk_cdev(MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor),

@@ -452,8 +516,11 @@ static void evdev_disconnect(struct inpu
 		wake_up_interruptible(&evdev->wait);
 		list_for_each_entry(list, &evdev->list, node)
 			kill_fasync(&list->fasync, SIGIO, POLL_HUP);
-	} else
+	} else {
+		if (evdev_mix.open)
+			input_close_device(handle);
 		evdev_free(evdev);
+        }
 }
 
 static struct input_device_id evdev_ids[] = {

@@ -476,11 +543,28 @@ static struct input_handler evdev_handle
 static int __init evdev_init(void)
 {
 	input_register_handler(&evdev_handler);
+
+	memset(&evdev_mix, 0, sizeof(struct evdev));
+	INIT_LIST_HEAD(&evdev_mix.list);
+	init_waitqueue_head(&evdev_mix.wait);
+	evdev_table[EVDEV_MIX] = &evdev_mix;
+	evdev_mix.exist = 1;
+	evdev_mix.minor = EVDEV_MIX;
+
+	devfs_mk_cdev(MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + EVDEV_MIX),
+			S_IFCHR|S_IRUGO|S_IWUSR, "input/events");
+	class_simple_device_add(input_class, MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + EVDEV_MIX),
+				NULL, "events");
+
+	printk(KERN_INFO "events: event device common for all events\n");
+
 	return 0;
 }
 
 static void __exit evdev_exit(void)
 {
+	devfs_remove("input/events");
+	class_simple_device_remove(MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + EVDEV_MIX));
 	input_unregister_handler(&evdev_handler);
 }
 

I really think this is the wrong way to go. Much better would be to fix the X driver (are you using evtouch or something else?) to notice the disconnect of the device (it'll get -ENODEV) and connect of the device (a hotplug event is issued, a select() on /proc/bus/input/devices returns as readable) and re-open the device.

It's not really possible to mix the events from all devices together, namely touchscreens, since mixing of ABS_* events is undefined.

Vojtech Pavlik
SuSE Labs, SuSE CR

I am using evtouch, but I had read that X itself has an issue with devices that are not "always there" and that X does not [yet] seem to be designed to handle hotplugging well (for example, device names need to be hard-coded in xorg.conf, so a changing device name on plugging will not work). Perhaps this could be fixed, but it might be a lot more involved. Why was /dev/input/mice created? It does correct the issue of unplugging and plugging mice (as well as its obvious feature of allowing multiple mice, of course)? It keeps X happy by shielding it from the plugging/unplugging.

If the mixing of event devices is problematic, what about simply the idea of a persistent event device that always "exists" to the user of the events but will reattach if the HW is plugged/unplugged (the device name assigned could be made constant using a udev symlink)? This could solve the problem without mixing all events. In my case, I have one touch screen only (as most people would), so the mixing works in my case, of course.

-Joe

You just need to list all the possible names, as far as I know, which isn't too bad. And udev takes care of it anyway.

To make 2.6 work with existing applications. It's scheduled to be removed. I definitely don't want to add more workarounds for X limitations to the kernel - that only defers fixing X.

Yes. But X really needs to start caring about hotplug. I've heard that latest builds are moving into that direction (though I didn't try myself yet).

The event device always exists until it's closed. It'll return -ENODEV on any operation, but is discarded only after the last application closes it.

What exact change of behavior do you need? If you want the kernel to match the newly plugged-in device to the existing, open, unattached, evdev node, well, that's near impossible to do solely in the kernel.

Vojtech Pavlik
SuSE Labs, SuSE CR

One problem is that with a touch-screen closed (physically, as in a car in-dash model), the USB interface is off, so when Linux boots, it will not see the device, since it does not exist yet. X actually will hang if you give it a device that is not there when X starts - pretty ugly.

In a car environment (just as an example) you often want to start up with the screen closed, but when you pop open the screen, you want the system to be waiting for your input. Now, in the present situation with devices, the system will be hung, and even if it were not, X would not see the device appear, since it does not like to see devices go away and come back.

Yes, I agree that X should behave better, and you should not need hacks to work around these issues.

There is another issue though: if you look at any web site about touch screens or tablets, they will tell you to see what event device shows up for the device, and put that in xorg.conf. This involves looking at /proc/bus/input/devices by hand (could be different for each system and order of things that happen during boot) and locating the device by vendor name, etc. This works and is predictable only if devices are never plugged or unplugged.

Udev has the great feature of letting one define the name or symlink for a particular device, but this does not solve the problem with X, which will never see the device again if it detaches and re-attaches.

I think that, for input devices, there is a fundamental issue, in that unpredictable device names and intermittent devices are hard to deal with for programs looking for them, and udev is not the easiest to configure to fix the naming issue, unless you know what you are doing. Programs should be able to operate even without an input device connected (it would just not see events). Perhaps this means fixed pseudo-devices that represent the different kinds of input devices possible or configured and are always present (and just start talking once a device hooks up)... I could imagine a config file that lets a user list devices they want on the system all the time, as well as info about how the system would identify the real hardware. I know udev does this partially, but it does not make the device itself persistent - only the name.

I agree... And there maybe be situations in which a user program or X should be able to get notified of disconnects and reconnects and do the right thing. But maybe a pseudo-device layer that presents a predictable interface to X would prevent X from having to deal with this
- maybe user programs (including X) should not have to deal with disconnect and connect events with regard to hotplugging. I can see all sorts of bugs involving this mechanism. Centralizing the hotplug issue might be more stable (it already exists as the hotplug and udev systems). If there were simply a way to flag a device as "always should exist and stay there," the problem could be solved this way. My hack basically does this for my case.

It looked to me like the event dev file disappeared from the /dev/input dir once the USB turned off. Are you saying that if it is then re-plugged, it should come back as the same name if the program did not close it? I saw it coming back as, e.g., "event2" after being "event1". This is all with X running. The X driver ("evtouch") also got a disconnect event, but it never seemed to get the subsequent connect - not sure what was at fault).

The big problem that I ran into (and there a bunch of other touchscreen users frustrated by this) is that I needed X to accept the device name I gave it even if the device was not present at boot. Also, even if the device unplugs and replugs, the device X attached to needed to stay there the whole time so X and/or its drivers didn't give up on it and never listen or attach again. That's why I created /dev/input/events, which is there at boot and always there (like /dev/input/mice). The event layer takes care of attaching the real device to this mixer, and X never knows anything was happening with plugging/unplugging.

So, overall, I agree that we should not invent hacks to make up for another software package's problems, but perhaps input devices, especially ones that sometimes are not there at boot or not there all the time, should be treated in a way that lets programs stay ignorant of the intermittent nature of the devices. It does not sound right to push the handling of the intermittent nature to each user program. If the kernel could handle that aspect, it would make all programs more stable. And most of those "plug and unplug" events, even if handled by X or other programs, would really be unnecessary in most cases. In the case of a touchscreen, there is no need for X to know it switched off and back on again - it just needs to keep listening for touch events. For X to be "hotplug aware" in this sense only adds complication, I would think. At least if there were a mode in the device/hotplug/udev stuff to make a "permanent" device (from boot, and always), you could spare the program all of that.

Interesting discussion!
-Joe

which seems a little contradictory.

However, Joe continued with:

Indeed. Each user program should not care about it. An event/hotplug library should, and the user programs should use that. Like d-bus/HAL.

Dave

Yep. Exactly so.

Vojtech Pavlik
SuSE Labs, SuSE CR

What I was trying to say (and didn't say very well!) is that I agree that "hacks" should not be created to mask other problems, but perhaps there are ways to solve the problem in the kernel (or in user-space programs like udev) that are not hacks and that generally make things more elegant all around.

Right. Or, if it makes sense, I was proposing that a new kind of device (or device mode) that makes a device ever-present could prevent needless handling of plugs and unplugs in applications or X, if that's appropriate. /dev/input/mice is such a device, acting as a catch-all for mouse events (and as a byproduct, the specific mouse device chosen arbitrarily does not matter to the app). If it's a hack (as Vojtech says), maybe there is a way to get the same functionality in a less hackish way. But Vojtech is right that the kernel should not read config files or set "policy," so perhaps something like udev is the right place for that kind of thing...

-Joe

Vojtech is right. The problem is in X and should not be fixed in the kernel. You need to complain about this on the Xorg lists.

http://lists.freedesktop.org/mailman/listinfo/xorg

In your example you missed the case of someone having X running and they plug in a new device that X has never seen before. The Linux kernel has a hotplug system that tracks all of these plug in/out events. The problem is that X is not using the hotplug system when it should. X could even track your display being open/closed if it was listening to the hotplug events.

The xorg evdev input driver is here:
http://cvs.freedesktop.org/xorg/driver/xf86-input-evdev/

Jon Smirl
[email protected]

I see it is not there yet. Here is the old one:
http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/input/evdev/

Jon Smirl
[email protected]

Is the kernel really needed for this trick, or could a daemon similiar to gpm do the job instead? I.e. the daemon reads the evdev device (when it is there) and writes to a FIFO. X pulls events out of the other end of that FIFO. If the device goes away, the daemon simply waits for it to reappear, possibly hooking into hotplug if that helps. The FIFO does not go away, so X is happy. X just waits till events appear again.

Helge Hafting