Input device design (3)

Joe Krahn krahn at
Fri Sep 2 12:31:34 PDT 2005

Jim Gettys wrote:
> On Fri, 2005-09-02 at 15:17 +0200, Waldo Bastian wrote:
>  > On Wednesday 31 August 2005 19:16, Jim Gettys wrote:
>  > > On Wed, 2005-08-31 at 02:56 -0400, James Cloos wrote:
>  > > > BTW, just to be clear, I (at least) wasn't thinking of having the
>  > > > actual i/o events go through this os-dependant, external server,
>  > > > but rather just the initial discovery and hotplugging of i/o 
> devices.
>  > > >
>  > > > I was expecting the external server to notify the X server of the
>  > > > locations of the devices.  Ie, on Linux it could tell the X server
>  > > > that /dev/input/event5 just appeared, is a pointer, and should join
>  > > > the set of core pointers.  Or that eg /dev/input/event2 went away
>  > > > and should be close(2)ed.  Et cetera.
>  > >
>  > > Exactly, though I think the X server can find out itself when 
> devices go
>  > > away: it will get an error on the file descriptor, so it isn't clear a
>  > > close message is needed (unless we want to be able to take away a 
> device
>  > > already assigned to the X server...  Hmmm...)
>  > >
>  > > Do people think we need to be able to retrieve input devices once
>  > > assigned to the X server.
>  >
>  > For completeness I would add it.
> I agree.
>  >
>  > A more interesting problem is how such disappearing devices should be 
> handled
>  > at the X Client side. Should they removed from XListInputDevices? (I 
> think
>  > so) What about X clients that have the device open with XOpenDevice? 
> Should
>  > device ID's be reused?
>  >
> The question is whether we want running applications to break when input
> devices evaporate under them.  In this case, the application gets errors
> it isn't expecting, and probably dies.
> Another strategy is to have the device just go "idle", and requests to
> manipulate it get ignored.  If the same device gets plugged in again
> (which begs an interesting question about whether we can find out or
> guess it is the same device), things might continue where it left off,
> using the same device ID.  I don't think device ID's should get reused
> any sooner than necessary, unless we believe it is for the same device.
> This has some attractive robustness properties.
> I think it must be possible for clients to track the coming and going of
> devices, if they are interested.  We'll have to add to the extension a
> bit to make this possible.
IRIX has always handled "offline" devices, and it was useful. You 
manually configure the server with a list of devices. Those devices are 
listed in te X device list no matter what. So, you start an application 
that uses the dialbox, it checks to see that you have one, and connects 
to it. The app is happy, but just doesn't get any events. Then the users 
sees that his dialbox got unplugged, plugs it in, and is also happy as 
dialbox events start going to the app.

I much prefer manual control of every device added or removed from X, 
with an "offline" state for devices that you have but may not always be 
plugged in. But, some people think the device list should always reflect 
exactly what is plugged in at that moment.

So, it needs to be configurable. This is where the X Client management 
of devices comes in. When one exists, it should be told when a device is 
disconnected, and it gets to decide what to do. Without an X client 
manager, I can think of two good built-in default hotplug policies:

1) Always list exactly what the config says is there, and leave it 
listed even if it is offline at the moment.

2) Dynamically add/remove everything that the OS tells X is [dis]connected.

As for handling this in the X protocol, the core X code has always had 
an "Off Devices" list. I think this is where 'zombie' devices can be 
put; they are removed from Device Lists, but still have state info.

I think all that is needed is a few more XDeviceInfo.use enums, like 
IsOffline (inactive but still valid), and IsRemoved. But, the use value 
needs some re-design anyhow, to properly represent multiple core devices.


More information about the xorg mailing list