XInput 2: the big picture, relationship to toolkits

[Peter Hutterer]

n Thu, Aug 14, 2008 at 01:36:07PM -0400, Owen Taylor wrote:
> 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.

in this case the driver needs to cap off and stop sending motion events.

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

correct, just posting the key event will work fine.

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

I agree with Owen. For example, the wiimote has a 12 axes or so (IR, tilt,
motion and some on the nunchuck). They don't map to many other devices, and
keeping e.g. 23 axes around just so we can map them appropriately to "what
everyone knows" seems sub-optimal.

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

Having both device IDs in the event is good, it reduces the processing the
client has to do for potentially often-requested data. But the DCCE are still
useful, since it's the only way to get updated data w/o the roundtrip prone
for race condition.
 
That said, DCCE could be ditched if we expect clients to always hold all
information about all SDs locally instead of just interpreting them when
necessary. The expense of sending the DCCE seems less than that though :)

Cheers,
  Peter