XInput 2: the big picture, relationship to toolkits

[Owen Taylor]

On Thu, 2008-08-14 at 14:57 +0300, Daniel Stone wrote:

> On Wed, Aug 13, 2008 at 05:45:40PM -0400, Owen Taylor wrote:
> > I also haven't looked here at device keys ... the past experience was that
> > it was almost impossible to meaningfully use the Wacom soft keys in apps,
> > but I forget the details of why that was case.
> 
> If you find out, let me know, but I'm willing to bet the answer involved
> differing keymaps, which is now solved.

It's very fuzzy at this point. If I had to guess it was:

 - it was very hard to get to the soft keys without moving the pointer
   up to the top of the screen near the soft keys.
 - if the pointer wasn't over the application, the soft keys didn't get
   delivered to the application.

As long as your window manager is in "click to focus mode", then the
keys should now get delivered through the master device to the input
focus window, solving this issue.

> > The master/slave setup makes this, if anything, worse, since
> > it continually mutates the master device to look like one or
> > the other slave device, but there is no actual indication of
> > what slave event one of these master events come from that
> > I'm aware of.
> > 
> > One possible fix here would be to add another type of 
> > device information class .. ExtendedValuatorInfo, say that
> > contains extra information per axis.
> 
> Meh.  I think the best thing to do here is what we've done with buttons:
> rather than sending ExtendedButtonInfo, everyone knows what button n
> means.  No need to XKBify Xi.

If it was just x,y and an optional pressure, that would work. But
possible axes just for Wacom tablets include:

 x, y, pressure, 
 tilt-x, tilt-y, wheel position (for a pen/airbrush)
 rotation, "throttle" (for a puck)

I don't think a fixed numbering works well. Not only do you have 
inefficiency in sending extra dummy valuators in every event,
the application has no way of knowing what valuators are actually
there, and what are just there to get things numbered correctly.

> > Device Identity
> > ===============
> > 
> > While position is position, pressure is pressure and applications  
> > shouldn't have to worry about device identity when reading axis values, 
> > applications do need the ability to determine what device is sending 
> > an event. A drawing program might want to make tool selection per
> > device, for example.
> > 
> > This comes up with Wacom tablets, because the Wacom drivers create
> > a device for each "tool" you can use on the tablet (different pens, 
> > airbrush, mouse, etc.) That is arguably an abuse of the XInput
> > system, but without extending XInput in this area, it's the only
> > feasible way to do it. And it conceivably useful in the case where
> > there are multiple actual devices sending events (mouse vs. tablet,
> > say.)
> > 
> > So, there needs some way of telling what slave device sent an event
> > delivered from the master device. I don't have an easy solution for
> > this. One thing to consider is getting rid of the wholesale mutation
> > of the master device (a lot of messy code in the server), and just
> > send a "CurrentSlaveDeviceChanged" type event. Since master devices
> > are only revealed to XInput 2 clients, there is some degree of 
> > compatibility for this.
> 
> My thinking was just to have two device IDs: originating device (the
> physical device actually responsible for the event), and delivering
> device (i.e. if you select on a master and not a slave, the master).
> This, AFAICT, gives the clients all the information they need while
> avoiding the inherent raciness and complexity that comes with having to
> constantly round-trip to work out how their input event should be
> interpreted (and the associated spike in input latency).

That certainly simpler than tracking via DeviceClassesChangedEvent,
though as Peter points out that does allow it without extra round
trips.

- Owen