xserver: InputDevice hotplug configuration (Was: Re: [RFC] XInput hotplugger daemon)

[Magnus Vigerlöf]

On måndag 17 mars 2008, Daniel Stone wrote:
[...]
> > 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. :)

Let's get the ideas of how to handle devices into code and have 1.5 as target 
(optimistic? perhaps, but I'm willing to work for that). When this is in the 
code I promise that I'll throw away xinputhotplugd with a smile :)

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

True, a hierachy oriented around the physical device instead of an input 
focus. I don't see exactly how the events should be aggregated in this 
hierarchy though.. Should the top device change the properties as the MD does 
in MPX or would it be better to let it interpret the raw data according to 
the parameters it has defined?

How usefull would it be to able to access the 'raw' data/full value range from 
the tablet easily? For calibration/configuration purposes this would be nice, 
but you could always define a new subdevice for this temporarily...

So when I connect my tablet (Volito2) something like this would happend:

Wacom driver get called to see if it can handle it. It can, so it register 
Volito 2 as a root device, it also adds a stylus, eraser, cursor, and pad as 
subdevices to the root.

Do we need to keep down the number of devices that send core-events? If so, 
only those devices that has a physical counterpart should be set up as 
core-sending devices by default (the driver will know this). This could be 
overridden by user configuration. For the Volito2 only the stylus would send 
core-events. Mmmm.. For mice or keyboards only the top node should be needed, 
there's no need to have more levels for those devices, are there?

How about defining properties for the individual devices that the driver 
defines? Maybe a recommendation is enough as arbitrary options is on the way 
in? (calibration!)

That would be the automatic part, and we would have:
* Volito 2
* Volito 2:stylus (serial=any,core)
* Volito 2:eraser (serial=any)
* Volito 2:cursor (serial=any)
* Volito 2:pad (serial=any)

The user configuration is added and I want to have a correct aspect ratio 
between tablet and my screen. Either change the :stylus device or define a 
subsubdevice (:stylus:1), I'll go for the latter for the time being 
(rationale: the 'new' device would be a part of the bigger one, a different 
serial id would however be a completely different tool). If this tablet would 
have support for serial id of the styluses and I had two, I would add a 
second subdevice for this stylus (:stylus1). That would result in (the 
configuration of the devices would need to turn on/off core sending as the 
configuration is changing):
* Volito 2
* Volito 2:stylus (serial=any)
* Volito 2:stylus:1 (serial=any,maxY=xxx,core)
* Volito 2:stylus1 (serial=6532)
* Volito 2:stylus1:1 (serial=6532,maxY=xxx,core)
* Volito 2:eraser (serial=any)
* Volito 2:cursor (serial=any)
* Volito 2:pad (serial=any)

Lots of devices would get added this way, but it would be easy for the 
application to access both the more limited devices that the user has 
configured as well as the whole device.

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

There's no uniqe HW identity available as far as I know. So we 'll have to 
rely on vendor/model and where it's connected. But that was my plan with my 
daemon anyway..

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

I'm willing to do some of the work too, so don't put too much on your own 
to-do list so you end up in the same situation as with the rescaling 
stuff :-|

> > The protocol needed for the configuration?
>
> This is pretty trivial, and I believe we can key it off RandR
> properties, basically.

Mmmm.. RandR.. You know, for a tablet PC there's a need to rotate the tablet 
when we rotate the screen (the *tablet* of the tablet PC that is ;) ).. It 
would be nice if this could be coordinated somehow. Also the X&Y axis would 
switch so this change must be propagated to all users of the InputDevice.

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

No worries, that item tends to climb to the top once every day at least ;)

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/20080319/7ab2f0a1/attachment.pgp>