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

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

[Joe Peterson]

[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]

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


[-- Attachment #2: evdev.c.patch --]
[-- Type: text/x-patch, Size: 6776 bytes --]

--- linux-2.6.12/drivers/input/evdev.c.orig	2005-08-15 11:12:15.000000000 -0600
+++ linux-2.6.12/drivers/input/evdev.c	2005-08-15 11:12:11.000000000 -0600
@@ -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);
 }
 

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Vojtech Pavlik]

On Mon, Aug 15, 2005 at 11:27:56AM -0600, Joe Peterson wrote:

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

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

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

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Joe Peterson]

Vojtech Pavlik wrote:
> On Mon, Aug 15, 2005 at 11:27:56AM -0600, Joe Peterson wrote:
> 
> 
>>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.
> 
> 
>>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.
> 
> 
> 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.
> 

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

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Vojtech Pavlik]

On Mon, Aug 15, 2005 at 12:00:37PM -0600, Joe Peterson wrote:

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

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.

> Perhaps this could be fixed, but it might be a lot more
> involved.  Why was /dev/input/mice created? 

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.

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

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

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

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

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Joe Peterson]

Vojtech Pavlik wrote:
>>>>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).
>
>>
>>
>> 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.


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.


>>>>Perhaps this could be fixed, but it might be a lot more
>>>>involved.  Why was /dev/input/mice created?
>
>>
>>
>> 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, 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.


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


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.


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


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


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


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

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Dave Neuer]

On 8/15/05, Joe Peterson <joe@skyrush.com> wrote:
> 
> So, overall, I agree that we should not invent hacks to make up for
> another software package's problems...

but also wrote:

> If the kernel could handle that aspect, it would make all programs more stable.

which seems a little contradictory.

However, Joe continued with:

> It does not sound right to push the handling of the intermittent nature
> to each user program.

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

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Vojtech Pavlik]

On Mon, Aug 15, 2005 at 04:06:04PM -0400, Dave Neuer wrote:

> On 8/15/05, Joe Peterson <joe@skyrush.com> wrote:
> > 
> > So, overall, I agree that we should not invent hacks to make up for
> > another software package's problems...
> 
> but also wrote:
> 
> > If the kernel could handle that aspect, it would make all programs more stable.
> 
> which seems a little contradictory.
> 
> However, Joe continued with:
> 
> > It does not sound right to push the handling of the intermittent nature
> > to each user program.
> 
> 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.
 
Yep. Exactly so.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Joe Peterson]

Dave Neuer wrote:
> On 8/15/05, Joe Peterson <joe@skyrush.com> wrote:
> 
>>So, overall, I agree that we should not invent hacks to make up for
>>another software package's problems...
> 
> 
> but also wrote:
> 
> 
>>If the kernel could handle that aspect, it would make all programs more stable.
> 
> 
> which seems a little contradictory.

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.

> However, Joe continued with:
> 
> 
>>It does not sound right to push the handling of the intermittent nature
>>to each user program.
> 
> 
> 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.

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

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Helge Hafting]

Joe Peterson wrote:

>Dave Neuer wrote:
>  
>
>>On 8/15/05, Joe Peterson <joe@skyrush.com> wrote:
>>
>>    
>>
>>>So, overall, I agree that we should not invent hacks to make up for
>>>another software package's problems...
>>>      
>>>
>>but also wrote:
>>
>>
>>    
>>
>>>If the kernel could handle that aspect, it would make all programs more stable.
>>>      
>>>
>>which seems a little contradictory.
>>    
>>
>
>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.
>
>  
>
>>However, Joe continued with:
>>
>>
>>    
>>
>>>It does not sound right to push the handling of the intermittent nature
>>>to each user program.
>>>      
>>>
>>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.
>>    
>>
>
>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...
>  
>
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

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Jon Smirl]

On 8/15/05, Joe Peterson <joe@skyrush.com> wrote:
> 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.

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
jonsmirl@gmail.com

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Jon Smirl]

On 8/15/05, Jon Smirl <jonsmirl@gmail.com> wrote:
> The xorg evdev input driver is here:
> http://cvs.freedesktop.org/xorg/driver/xf86-input-evdev/

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
> jonsmirl@gmail.com
> 


-- 
Jon Smirl
jonsmirl@gmail.com