[Xorg] XInput Hotplug Additions

[Jim Gettys]

Hi Kristian,

First, I applaud your wading in and making progress.

But I'm seriously wondering if XAddInputDevice is the
right approach.

Somehow or another, the X server needs to be informed
of new devices, (and their removal to their control).

It might seem natural to do this by extending the X protocol
directly, as you've done.  The particular suggestion you've made
has a lot of configuration file specific sorts of information
in it; others have expressed concerns here.

But I'm suspecting this will beg a lot of other questions best
left unasked, particularly around security.

X is generally a priviledged process (currently root
on most Linux systems), and does not run as the user's
protection domain.

So by exposing the device name and/or drivers to clients, there is
an immediate need to deal with security consequences of doing
so.  Otherwise, unpriviledged X clients can start playing
nasty games that they should't be able to, by accessing
files/drivers they shouldn't.

Now X in general needs better security than it currently does; but
right now, we don't have the right expertise in the community
to take these on directly.  We can probably make some cookie
mechanism work here, if we have to.


But here is an alternative approach, that keeps all this
from being exposed to clients directly and keeps OS independence.

0) The X server listens for new input devices somehow 
(say unix domain socket).

1) A new device appears.  The systems' hotplug facility
interacts with the user, and determines that the device is
to be assigned to the particular X server for this session
(or every time the system boots).

This also allows the hotplug facility to do lots around
device initialization and configuration, driver loading,
etc; it can be priviledged, change protections, ownership,
etc, on the user's behalf as hotplug generally does.

This device might be local, or remote.

2) Via some protocol over this socket (might be dbus, might be 
some other protocol, as simple as the current name/value pairs
used in the current configuration file nightmare), the X server 
is told to set up the new input device).

3) If so, after initialization, 
the socket associated with the device gets sent to
the X server (via send()), along with some information to allow
the X server to filter the byte stream (or do the right IOCTL's),
via some interface, for delivery of events after the device
has been initialised.

There would likely be three such filters (on Linux):
  a) existing serial devices (if we care)
  b) evdev devices.
  c) remote devices via some (yet to be determined) wire
     protocol.

4) The socket closing signals the X server that the device has
gone away.

Events would be sent to (interested) clients notifying them
of new devices coming and going.

The big issue I see is figuring out how device calibration
and configuration should occur; we'd like X UI's to be
buildable to share as much as they can across different
device classes.  I need to study the X Input
extension further.

In any case, I'm suspecting that keeping the hotplug
details invisible from clients can avoid many security issues,
and in fact, isn't much harder to implement...  The ddx
interface for XInput didn't look all that daunting (as oppossed
to the 10K lines of mess of the serial drivers themselves, for
N different devices)...

                         - Jim




On Mon, 2004-08-02 at 20:10, Kristian Høgsberg wrote:
> Hi,
> 
> I've been doing some work on the XInput hotplug functionality that was 
> discussed on this list some weeks ago.  I have put a patch in bugzilla, 
> http://freedesktop.org/bugzilla/show_bug.cgi?id=971.  At this point, 
> I've added two requests to XInput:
> 
> 	extern int      XAddInputDevice(
> 	    Display*            /* display */,
> 	    _Xconst char*       /* name */,
> 	    _Xconst char*       /* driver */,
> 	    XDeviceOption*      /* options */,
> 	    int                 /* nOptions */
> 	);
>  
> 
> 	extern int      XRemoveInputDevice(
> 	    Display*            /* display */,
> 	    _Xconst char*       /* name */
> 	);
> 
> with
> 
> 	typedef struct {
> 	    char *name;
> 	    char *value;
> 	} XDeviceOption;
>  
> 
> The idea is that the arguments given to XAddInputDevice() corresponds to 
> the options you can give in an xorg.conf InputDevice section, e.g.
> 
> 	Section "InputDevice"
> 	        Identifier  "Mouse0"
> 	        Driver      "mouse"
> 	        Option      "Protocol" "IMPS/2"
> 	        Option      "Device" "/dev/input/mice"
> 	        Option      "ZAxisMapping" "4 5"
> 	EndSection
> 
> could be configured at runtime from an X client as
> 
> 	XDeviceOption options[] = {
> 	  { "Protocol", "IMPS/2" },
> 	  { "Device", "/dev/input/mice" },
> 	  { "ZAxisMapping", "4 5" },
> 	};
> 
> 	XAddInputDevice(dpy, "Mouse0", "mouse", options, 3);
> 
> Which will load the "mouse" driver if it's not already present, and add 
> the device "Mouse0".
> 
> When a new device is added, a DevicePresenceNotify event is sent to 
> interested clients.  The event does not contain any information about 
> the change, clients should use XListInputDevices() to find out what 
> devices are available.
> 
> I've also attached a tar-file with a few sample applications: xadddev 
> and xrmdev are commandline utils to add and remove input devices, 
> get-event demonstrates how to select the DevicePresenceNotify event and 
> finally, input-daemon, which is a simple example of how a daemon could 
> listen for system hotplug events using HAL and add and remove input 
> devices accordingly.
> 
> I think it would be cool if we could have this or similar functionality 
> in the next release again (i.e. not the one scheduled for August).  At 
> the  moment I guess people are busy with the upcoming release, but I 
> would greatly appreciate comments and feedback on this stuff.
> 
> Kristian
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg