[Xorg] XInput Hotplug Additions

Kristian Høgsberg krh at bitplanet.net
Tue Aug 3 14:48:28 PDT 2004

Jim Gettys wrote:
> Hi Kristian,
> First, I applaud your wading in and making progress.
> But I'm seriously wondering if XAddInputDevice is the
> right approach.

This was mostly to get the ball rolling and see that it could be done.

> 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.

Right, I'm not particularly attached to the approach that I've taken and 
I realize that it's problematic letting any user with display access ask 
the server to open any file.  Another thing, which Alan also mentioned, 
is that it's difficult to do this in an implementation independent 
manner.  Even if you can standardize on what arguments to pass to the 
XAddInputDevice() call, the meaning of those arguments will be server 
specific (e.g. what drivers are available, what options do they support 
etc.)  A hotplug daemon that want's to support several server 
implementation will have different code paths for each server it supports.

> 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).

D-BUS doesn't let you pass file descriptors, so I guess that's out.

> 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.

Wouldn't it be better to do 2 and 3 in one go, i.e. send a request 
saying "setup a new input device, use this filter, use this fd".  That 
avoids state in the protocol and makes the whole setup simpler.

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

I like this idea, I think you described something similar at GUADEC.
As I understand your suggestion, the access to the servers hotplug 
socket is unpriviledged and security is enforced by letting the user 
open the device file.

So we should try to figure out what kind of interface the server should 
expose on this local socket and what kind of protocol to use.  I can't 
see that we would need anything more than add device and remove device 
requests.  The add device request passes the fd, the name of the filter 
to use, and possibly a set of options for that filter.

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

Yes, I have this bit in the patch also.  You select the 
DevicePresenceNotify event using the XInput XSelectExtensionEvent().

> 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.

For configuring devices, there are two mechanisms: feedbacks and device 
controls, and I must admit I'm not sure what the difference is.  They 
both allow clients to change behaivour of a device that you've opened 
with XOpenDevice().

> 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)...

I dont think it'll be harder to implement either, it's just that 
initially I wanted to avoid making up another protocol but rather use 
the existing X protocol.


>                          - Jim
> On Mon, 2004-08-02 at 20:10, Kristian Høgsberg wrote:
>>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 */
>>	);
>>	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.
>>xorg mailing list
>>xorg at freedesktop.org

More information about the xorg mailing list