[Xorg] Input device hotplug

[Egbert Eich]

Kristian H=F8gsberg writes:
 > Hi all,
 > =

 > I've been working on making the X.org server hotplug aware with respec=
t
 > to input devices.  The current situation is that all devices must be =

 > setup in the config file and adding new devices requires config file =

 > editing and server restart.  What I've been trying to implement is tha=
t =

 > you can plug in an input device while the X server is running and it =

 > will show up as a new XInput device.
 > =

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

 > mechanism out of the X server.  By adding requests to add and remove
 > devices a client program can monitor hotplug events and tell the serve=
r =

 > to add or remove devices accordingly.

Having the discover mechanism live outside of the X server is only useful=
 if
it is generic to the system and not specific to X. Any program interested=

in input devices should be able to take advantage of its services.

While currently it is not possible to run multiple X servers on the
same system (multi seat) it might well be in the future. In this
case it must be made sure that only one of these servers connects to
the device and that after a replug the same server gets the device
reassigned. =

At the same time there may be valid reasons why multiple programs obtain
data from the same device. (The solution that comes to my mind is to
register MASTER and SLAVE applications and to make sure that only one =

MASTER app is allowed to open the device).

 > =

 > I have a prototype running were I've added AddInputDevice() and
 > RemoveInputDevice() in the XFree86-Misc extension:
 > =

 >    typedef struct {
 >        char*	name;
 >        char*	value;
 >    } XF86MiscDriverOption;
 > =

 >    Status XF86MiscAddInputDevice(Display *dpy,
 >                                  const char *identifier,
 >                                  const char *driver,
 >                                  XF86MiscDriverOption *options,
 >                                  int option_count);
 > =

 >    Status XF86MiscRemoveInputDevice(Display *dpy,
 >                                     const char *identifier);
 > =

 > i.e. the AddInputDevice arguments correspond to the InputDevice sectio=
n =

 > of the config file.  The implementation mimicks the server =

 > initialization sequence; it loads the driver, builds an option list fr=
om =

 > the given options, calls PreInit(), and adds the device.
 > =

 > In the prototype I'm using HAL (hal.freedesktop.org) on Linux to =

 > enumerate and discover devices.  Other systems could use other =

 > mechanisms, but HAL is intended to be cross platform, and a FreeBSD po=
rt =

 > is being discussed right now on the list.
 > =

 > One thing I'ld like to discuss is where to add the add and remove devi=
ce =

 > interface -- I dont think XFree86-Misc is the right place.  My first =

 > approach to this was that the new functionality should be an Xorg =

 > private interface, but I'm thinking that maybe it would be better if i=
t =

 > was a standardized extension to XInput.  In that case, is the proposed=
 =

 > interface too Xorg specific?

No, adding this to an extension would only make sense if a functionality
is to be network transparent. This doesn't seem to be the case for input
devices. Input devices pysically live on the machine the server exists
on. Therefore a local interface should suffice.
I basically had the same idea like you when I implemented the interface
for APM years ago. My first implementation used an extension however it
didn't seem to make much sense in using an X client which would communica=
te
with the server just to send information across that could be obtained
by the Xserver itself.
Therefore I decided to add an interface to the DDX splitting it into
a OS independent and OS dependent part.

The XInput extension may have to be extended to be able to send events
to notify clients about the new device. Also it may be useful to provide
more information about the device to the clients (for example some ID
or serial number) so the client is able to (re)identify devices.

 > =

 > Comments are welcome.  I'm currently trying to get my prototype cleane=
d =

 > up, and then I'll attach it to a bugzilla entry
 > =


I hope my comments have been helpful. This is certainly an importand issu=
e
which should be discussed.

Egbert.