[Xorg] Input device hotplug

[Egbert Eich]

Kristian H=F8gsberg writes:
 > Egbert Eich wrote:
 > > Keith Packard writes:
 > >  > =

 > >  > Around 19 o'clock on Jun 23, =3D?ISO-8859-1?Q?Kristian_H=3DF8gsbe=
rg?=3D wrote:
 > >  > =

 > >  > > The overall design I'm thinking of is to keep the device discov=
ery =

 > >  > > mechanism out of the X server.
 > >  > =

 > >  > I think that's probably the right design.
 > > =

 > > Provided it is generic and not X specific. =

 > =

 > The main idea behind keeping the discovery mechanism out of the server=
 =

 > was that different systems can use different mechanisms.  On GNOME or =

 > KDE desktops I think it would make good sense to use HAL for detection=
 =

 > (which is generic and system-wide), but an embedded system may well wa=
nt =

 > to use something more lean.

It depends on if you want to implement different system specific mechanis=
ms
into the clients by adding them to the toolkits or if you want to abstrac=
t
away things from the clients (and the toolkits) by putting the system
dependent  functionality into one central place (the Xserver) which expos=
es
a uniform interface to its clients.
So far the paradigm was to do the latter. =

The advantage of this was (and the reason for the paradigm) that all clie=
nts
(including those which where not written using any major toolkit) only ha=
d
to be developed for a single interface.
This is even more importand in a heterogenious networked environment.
If the discovery mechanism was to be integrated into the client the clien=
t
would have to be able to talk to all the different systems and all detect=
ion
mechansims would have to be network transparent.

Therefore the Xserver would obtain information about new input devices
locally and advertise newly added devices to interested clients thru
the XInput extension. The client could advice the Xserver to 'grab'
the device and keep it until either the client or the Xserver terminates
(and automatically reclaim it when replugged) or the device is unplugged =

(policy depends on the environment).

 > =

 > Also, by moving the mechanism to an X client daemon, you can implement=
 =

 > desktop specific policy in the daemon. For example, in the GNOME =

 > environment you could have a daemon that reads per user settings for =

 > input devices from GConf.

It would require the X client daemon to run on the machine the Xserver is=

running on or the discovery mechanism would have to be network transparen=
t.

We should explore if we cannot achive the same thing by designing an
X abstraction for the device detection carefully that we can implement
a policy on top.
In the past this has not always been done, rather X extensions often
were designed in a way to meet exactly the specific requirements at
the time.

 > > =

 > > When we do this we should try to fix other issues with the XInput
 > > extension. It's a while back since I've looked at it but there are
 > > some things that immediately strike ones eyes just reading the specs=
=2E
 > =

 > Do you remember what specifically was the problem?  I was thinking of =

 > adding a link to a new XInput page in the "Development" section on =

 > http://freedesktop.org/XOrg, is that okay?  We could use that for =

 > collecting the suggestions that come up.
 > =


That sounds like a good idea.

What I remember right now:
1.a. Clearify meaning of device type and device name in the XDeviceInfo =

     struct. Type is an Atom form a fixed list. =

  b. A device type touchpad is meaningless as it doesn't describe what =

     device (stylus, eraser, mouse etc.) is attached.
2. Make device controls more flexible. A device control currently =

   is an XID. Make it an Atom.

Egbert.