XInput 2: the big picture, relationship to toolkits

[Peter Hutterer]

On Fri, Aug 15, 2008 at 06:01:52PM -0400, Chuck Robey wrote:
> (1) there are some things that I think could be named better.  An entire class
> of things, like xf86SetStrOption(), these things all GET stuff, and can only be
> called "Set"s if you want to play lawyer-justification word games. 

you are aware that the X Input Extension is a protocol specification and has
little to nothing to do with the driver/server API?

> (2) on the subject of App Keys ... first, were people thinking on this, for the
> case of graphic tablets, that you could have physical areas of the screen
> reserved as the equiv. of function keys?   

I don't see what's so special about app keys. The driver reserves an area on
the device that triggers a key event rather than a pointer event (or the other
way round). This can be done right now, the only issue is the communication
with the driver to set up these areas at runtime. We now have a general
purpose configuration framework, so I presume nothing stops a device from
utilising these app keys.

> (3) there is a problem (in my own opinion, now) with both TipPressure and
> Proximity.  Know here that my deep experience is all of 1 device deep, but I'm
> going to report this as if  it's a common point, and let you judge if I'm right.
>  First, the TipPressure is something that needs to be handled explicitly.  Right
> now, you just put it up as the Z axis, and rely on faith that it's going to be
> handled right.  

We haven't had a mechanism to relay to the client what a certain axis means.
Over time, Z has become the default for pressure.  As you probably saw in
earlier emails in this thread, both Owen and I have suggested ways to get
around this issue.

Cheers,
  Peter