XInput 2: the big picture, relationship to toolkits

[Chuck Robey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Hutterer wrote:
> On Thu, Aug 14, 2008 at 01:14:43PM -0400, Owen Taylor wrote:

I finally decided to cut ALL of the context.

I'd like to put in my 2 cents, but with the understanding that even though I
know the code better than I did yesterday (and that's been true for the last 60
days) I still don't come close to what several of you do, so I'm not going to be
insulted if you don't pay proper homage to this.  I do have things I would like
to have looked at.  Understand 2 items: I like to be listened to, but not agreed
with, so if you just let it lie (but at least let me have my input) I will be
gloriously happy that you let me get my 2 cents in.  Secondly, I have been
spending all of my time with graphic tablets, so that's my personal bias, and it
probably comes out all too clearly.

(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.  Seeing as
there are no docs on much of this stuff, I really think that more attention
ought to be given to naming that has more real meaning, so that folks aren't
directed sideways, even if you end up with longish names out of it.

(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?  With some reserved for WMs and some
for Apps?  With a configurable way to signal their use, like perhaps a stylus
button, or maybe simply moving the stylus pointer, with Proximity off, to the
reserved area?  For the case of a tablet, this would be a hugely appreciated
option, I think, although it might go over with a thud for mice.  Also, although
I haven't got one of these, touch-sensitive screens might like the same sort of
handling of function keys as my idea for tablets.  Touch sensitive screens are
falling in price nowadays, I think they're gaining in popularity.

(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.  It's something that is a basic need of tablets, and ignoring it
in usage, docs, and configuration is really wrong.  Proximity is in the case
like TipPressure because (on tablets) it looks entirely like buttons.  What
seems to be happening is that devices are intercepting those keys at a lower
level, and simply reporting them as Proximity events.  Seeing as all tablets
need both TipPressure and Proximity, well, it could be done better.  I would
suggest that the way that Proximity is handled is a whole lot closer to being
the right way to handle it. TipPressure ought to have it's own case, so a driver
could intercept that value and report it explicitly.  I would have both
TipPressure and Proximity handled with variables with the name of TipPressure
and StylusContact.  Remember, with the low level of docs that exists, giving
things names that clear up a lot of the confusion is really more valuable than
you might think.

I have more ideas, but I prioritized, and I'll be happy at letting it go with
this.  (OK, I had my say, I honestly won't push this further).  Thanks for
listening.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkil/NAACgkQz62J6PPcoOk8UACggWV8McofxunW2mkkMGurSABE
Ib4AoKSfFOFBj0fPSpkxZHOehW0Xqvw9
=KiC/
-----END PGP SIGNATURE-----