xserver: InputDevice hotplug configuration (Was: Re: [RFC] XInput hotplugger daemon)
Magnus Vigerlöf
Magnus.Vigerlof at home.se
Tue Mar 18 16:05:14 PDT 2008
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>
More information about the xorg
mailing list