From: Joe Peterson <joe@skyrush.com>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: linux-input@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"
Date: Mon, 15 Aug 2005 12:00:37 -0600 [thread overview]
Message-ID: <4300D845.8070605@skyrush.com> (raw)
In-Reply-To: <20050815174558.GB1450@ucw.cz>
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
next prev parent reply other threads:[~2005-08-15 18:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-15 17:27 Joe Peterson
2005-08-15 17:45 ` Vojtech Pavlik
2005-08-15 18:00 ` Joe Peterson [this message]
2005-08-15 18:57 ` Vojtech Pavlik
2005-08-15 19:39 ` Joe Peterson
2005-08-15 20:06 ` Dave Neuer
2005-08-15 20:13 ` Vojtech Pavlik
2005-08-15 20:23 ` Joe Peterson
2005-08-16 8:38 ` Helge Hafting
2005-08-15 20:24 ` Jon Smirl
2005-08-15 21:05 ` Jon Smirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4300D845.8070605@skyrush.com \
--to=joe@skyrush.com \
--cc=linux-input@atrey.karlin.mff.cuni.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®