[RFC] XInput hotplugger daemon

[Daniel Stone]

On Mon, Mar 17, 2008 at 08:04:28PM +0100, Magnus Vigerlöf wrote:
> 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.

Right; the two are independent, but both useful in and of themselves.

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

Sure, but I'd rather have one way that input devices were added to the
server, always.  Less coder to debug, fewer opportunities to screw it
wrong. :)

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

Yep.

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

Hmm ... actually, this looks a lot like the device hierachy in MPX.  The
Wacom device is a virtual device which spans the devices stylus, eraser,
whatever.  These child devices can vanish or appear at any point, but
they all get aggregated to the master device by default.  Check out
Peter's work on this in MPX, because this actually sounds a lot like the
semantics you like (you're free to use the aggregator or individual
devices, can grab the aggregator to grab everything or just device by
device, etc).

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

Right. :)

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

o/\o

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

Sure, so you just expose a GUID property if you can uniquely identify
that tablet, and the user configuration stuff can key off that.

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

Meh.  Wacom Intuos3, Wacom Intuos3 (2), Wacom Intuos3 (3), whatever.  Of
course, users can rename them.

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

Yep, that's fine.  You could stash calibration info in HAL if need be,
providing at least _something_ for the whole system.

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

It just allows you to change min/max (in a rather dumb way), basically.
But if you could add and remove child input devices, this should really
solve this.  Your driver can just decide which device to send to.

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

Yeah, this has been a real pain in my arse and something I was a bit
daft to not define before (consider the initial D-Bus work the initial
experiment, and HAL to be something that fits my current hypothesis), so
hopefully I can bash something out on the plane this weekend.

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

Sure.  I've jumped on the Wacom list now, too.

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

Let me start at a draft API for this.  I think we can have something
running reasonably quickly, but I need to reconcile my current set of
input hacking branches first.

> The protocol needed for the configuration?

This is pretty trivial, and I believe we can key it off RandR
properties, basically.

> Use-cases for managing different device types?

I'll write this up when I can (got a bunch of pending board stuff to do
in particular, bleh).

> Let Magnus read the XInput extension so he know what it can do?

Yes, the MPX paper in particular is really worth reading, and a lot of
the stuff Peter's posted in wearables.unisa.edu.au/mpx/.

> ... other things?

Remember to sleep every now and then. ;)

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080318/19bf7081/attachment.pgp>