[Xorg] XInput Hotplug Additions

[Jim Gettys]

On Tue, 2004-08-03 at 17:48, Kristian Høgsberg wrote:
> 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.

No, I don't think it is an issue here.

I'm thinking of the case to allow the design to deal with new
device types.

If you look at the porting document for XInput, it looks as though
the X server can be educated about pretty arbitrary input devices, with
pretty arbitrary combinations of keys, buttons, locators, displays,
etc...

It is an incremental process.

You say: Here's a new device.
It has some buttons,
it has some keys,
it has N axes,
and so on....

to allow pretty arbitrary devices to be described.  I'm actually
reasonably impressed at the ideas behind the design.

I don't understand how to do this in a one step process.

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

To set up a device, we may have to do a whole sequence of
operations.  E.g.

a) load the correct device driver
b) set it into a known sane state

It isn't clear to me that we want both/either of those in
the module loaded into the X server.

So we can let hotplug get things into a state that
X can use, and, rather than X having to reopen the device,
and thereby potentially have to reinitialize it, pass the
file descriptor to the X server when it is ready to go.

If you detect the idea to keep as little as possible in the
X server, you're right.

This is analogous to the work we want to do to get display
mode setting *out* of the X server.

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

It is the setup of new devices where the interface has to be reasonably
rich; or you can't support arbitrary devices.

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

Yeah, I have to scratch my head some.  It also looks like some stuff
is missing (e.g. control for force feedback joysticks.

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

Yup.