All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events" 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.