I think this belongs here instead of the USB list. I believe that this is
not just a USB problem, but a kernel problem, because PCMCIA as well as
other devices create the same kind of issue, which is "how does an
application know when a hot swappable devices has been plugged in?".
I do not believe that Jim is not on the kernel mailing list and he should be
CCed.
--George
George France, france@crl.dec.com
Cambridge Research Laboratory, Compaq Computer Corporation
One Kendall Square, Building 700 MS: CRL
Cambridge, MA 02139 USA
-----Original Message-----
From: jg@pa.dec.com [mailto:jg@pa.dec.com]
Sent: Monday, May 01, 2000 3:08 PM
To: linux-usb@suse.com
Cc: keithp@suse.com
Subject: [linux-usb] X support for USB devices...
How can the X server find out if there are new USB devices?
Efficiently, in particular.
Here's the scenario:
It is time to deal with the X Window System input extension, to support
the various devices that can be plugged into USB.
Almost everything needed is already there: the X extension to deal with
a plethora of input devices already exists, and applications which use
the extension will get ported (or written from scratch).
USB, however, presents an issue not explored when the X Input extension
was designed nearly 10 years ago:
devices are hot plug and can come and go.
Having to mess with your X server, and restart your X server isn't
an acceptable situation: we need this all to be dynamic, with devices able
to come and go as you plug/unplug devices.
Detecting devices that evaporate during an X session is easy: I presume
that an open file descriptor returns ENODEV in this case (please correct
me if this isn't the case, and explain why this isn't the right behavior).
The server can then "do the right thing" and get rid of its knowledge of
the device.
Getting the X Input extension to "do the right thing" is also pretty easy:
there is a ListInputDevices protocol request which can be made to scan
for new devices; this is the first thing an application using various
input devices will execute. New keyboards can be dealt with easily,
even without the input extension, as the X protocol already informs clients
when the keyboard mapping changes: this is built into every application
in the X library. There is already support in the input extension to allow
a user to set which input devices are their core keyboard and mouse devices.
The (simple) missing piece in the X server side is that there is no event
to inform the client that input devices have come or gone. This is simple
to add as an upward compatible minor revision to the X Input extension.
Clients that care to know that devices have come or gone can then call
ListInputDevices and refresh their knowledge.
But to support this, we need some way to be informed when the state of
the USB bus has changed. Scanning the devfs file system can be done when
this happens, and we can discover devices that have been unplugged by
ENODEV, but we need a cheap way to to know when to look for new devices. We
can't afford to do it when there is no change in the USB bus: a system
call of any sort on a per X request basis doesn't make it for performance
reasons, much less looking through a file system to find differences.
Is there some device we can select on that will return if the configuration
of the USB bus changes? This would fit the bill just fine: we can teach
the X server to then "do the right thing".
- Jim Gettys
-- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com--------------------------------------------------------------------- To unsubscribe, e-mail: linux-usb-unsubscribe@suse.com For additional commands, e-mail: linux-usb-help@suse.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:09 EST