[RFC] XInput hotplugger daemon

[Magnus Vigerlöf]

On söndag 16 mars 2008, Daniel Stone wrote:
[...]
> > > So, with this, the Wacom driver would take an fdi, device name,
> > > whatever, and open it up, see that it's a Wacom tablet, and add all
> > > three devices.  Does this seem sensible?
> >
> > I wouldn't mind a more simple structure of the InputDevices inside the
> > server, but I don't see it will do much difference to the hotplugging
> > process as such.
>
> It's not a silver bullet, but it would help if we restructured to let
> the driver decide how to do the devices, rather than 1:1, no?

If we change the responsibility of the driver and also add a decent interface 
for the configuration of these over the wire-protocol... Yeah, maybe.

[...]
> > As I see it pointing devices are a bit different. Mice and other devices
> > that only report relative movements can be handled just as the keyboards
> > are handled, but the ones with a defined value range? (for now only X&Y
> > matters, but I wouldn't be surprised to see that this might change)
> >
> > The wacom driver allow the user to define how to translate the active
> > area of one tablet into one or more InputDevices. First by branching on
> > type (stylus/eraser/cursor/pad), second by branching on the serial id of
> > the tool, and third by branching on where in the active area the tool is
> > used. I don't see pushing this kind of configuration down to the kernel
> > as a way to solve this for the XServer.
> >
> > The number of types can easily be defined by the tablet vendor & model,
> > but the second one can only be configured by the user as can the third
> > one. So you see, the user config here is a vital part of defining the
> > resulting InputDevices. It would also mean that the InputDevices could
> > change as users log out/in as well... Worst driver possible? Maybe.. ;)
> >
> > So for me the natural way of handling hotplugging at the moment is:
> > HAL->daemon->XSever
> >
> > Where the daemon would be where we put the user configuration and thereby
> > the decision which InputDevices to add. Start it when [gkx]dm starts so
> > we can handle hotplugging devices while noone is logged in. Then restart
> > it as the user as a part of the X initialization process (i.e. calling
> > the scripts in /etc/X11/Xsession.d/*). A nice thing with this approach
> > would be that the devices could be reset by the daemon that is started
> > when [gkx]dm is started when the user log out.
> >
> > However, if the XServer would expose the internals, which drivers are
> > loaded, currently defined InputDevices, allow a configuration tool to
> > manipulate all aspects of the definition of them (add, remove, ...) over
> > a well defined protocol I guess that would make me change my mind. But I
> > do believe in keeping that kind of complexity outside the server and only
> > expose a simple API (as we have today).
>
> Urgh.  I guess the problem is that you then add multiple paths into the
> X server, which is bad.

Mmm... You mean we would have both HAL->XServer and HAL->daemon->XServer? 
Well, use only one of the two, not both... I've already figured out that they 
don't work well together, but this is a configuration issue.
If you want to make changes in the InputDevice configuration you should just 
talk with the daemon.

> You say that it splits on tool IDs.
That's one of three different things we branch on when selecting the 
InputDevice that we should be generating evets for in the driver, yes.
> What about if we provided subdevice IDs?
You mean something like the ethernet devices with their logical interfaces? 
Mmm.. Interesting.. (Volito_2:stylus, Volito_2:stylus:1, ...)
> This could be then used for either the tool or area, with a 
> descriptor attached, and then the only configuration you need is to set
> up the separate areas.  You don't need any separate daemon to handle
> hotplugging while not logged in, as you've just added the device and
> you're assuming every tool is a separate subdevice for now. gdm probably
> doesn't care. 

The key issue I have is that noone can know prior to looking at the user 
configuration how many InputDevices there will be for a specific tablet. But 
if we could define additional subdevices or subsubdevices on the fly this 
should not be a problem.

If we combine more configuration logic in the driver with subdevice definition 
and a better configuration interface, then you definitely have me 
interested...

There are some more exotic needs if you have two tablets of the same model 
attached, then it would be preferable to restore the configuration to the 
devices according to some connectivity identification. This is crucial if 
someone connects two LCD-tablets at the same time (yes, people do...). We 
*really* want to ensure that they don't move the pointer on the wrong 
screen :)

Keeping uniqe names should be solved unless you have two devices of the same 
kind, I think we should do something to address this in some way..

When gdm is running it should be enough if you can use the attached devices. 
It's a bonus if any calibration information is kept, but other than that...

> Configuring the separate areas would be reasonably easy, too: we already
> have AbsArea providing a poor approximation of this.

We've been using the Min/Max values on X&Y valuator axis together with 
multiple InputDevices so far to archieve this.. I'll have to look into how 
the AbsArea can be/is used...

> Does this sound reasonable? It's still user-guided, but we still always
> keep fully automated device addition/removal.  Of course the user can
> always dynamically enable and disable devices and configure them, but we
> stick to the principle of 'only way for devices to be added and
> removed'.

Having only 'one way' to do these things has been one of my major concern too. 
We need to define the whole idea more before I'll buy it. I'd like to 
see/write the use-cases for how to handle mice, keyboards, and of course 
tablets through the hotplug life-cycle. But I think this has potential to be 
something really nice.

> It's a somewhat contrived usecase (most people who aren't X/Wacom
> hackers would probably be fine with just losing the space, to be honest),
> but I think it's still doable.

You're right, let's put it this way: The wacom driver is pretty flexible today 
and I'd like to try to keep this flexibility in some way even if we hotplug 
the devices. But let me keep track of that part while we continue the 
discussion/...

> Cheers,
> Daniel

This is pretty major work we're talking about here, so which is the best part 
to start with?

A new device-structure internally in the server?
The protocol needed for the configuration?
Use-cases for managing different device types?
Let Magnus read the XInput extension so he know what it can do?
... other things?

Cheers
  Magnus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.x.org/archives/xorg/attachments/20080317/fb9cca9f/attachment.pgp>