mirror of https://lore.kernel.org/lkml/
 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 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®