XInput 2: the big picture, relationship to toolkits

[Chuck Robey]

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

Peter Hutterer wrote:
> 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?

After all the trouble I went to, to emphasize my relative unfamiliarity, I still
get zero slack ... OK, while I am VERY aware it's a protocol, no, I wasn't aware
that you folks were only discussing the protocol.  I had put it in my past
(which means, to me, that I went a deleted the mails), but is that true, no one
else made comments about implementation?  OK.
> 
>> (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.

I was trying to emphasize the difference in usage between someone using a mouse,
and someone using a tablet.  The mouse user must associate app key areas with
laid-aside screen areas.  The tablet user alone may instead have areas of the
tablet laid aside (sort of like the physical desktop versus the logical one),
and have that area be totally independent of any screen area.  I thought that
that distinction was important, and it wasn't clear to me that it was in folks
minds, so I raised it.

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

I didn't say I wasn't aware of how other drivers seem to  have done this; I
think I was clear in saying that the methods needed to be more explicitly done,
not to just silently allow the 3rd axis to be assigned to TipPressure.  Also, my
own tablet has Proximity handled as the first button.  If that's common in
tablets, then I was suggesting that it be made more obvious that Proximity is
the usage of a particular button.

And if all of this is off topic because you folks are only discussing the
protocol, then you can just ignore this all. because none of it is pointedly
aimed at the protocol.  I do sort of like dealing with Protocol design, but 100%
of my attention here is in Xinput coding, I've had no time whatever to examine
the protocol aspects of things.  All of the comments I saw, they didn't _seem_
to me to be talking about protocol.

> 
> Cheers,
>   Peter

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

iEYEARECAAYFAkioSpUACgkQz62J6PPcoOld3QCfSdaJp/g5g60hb8pR7oI6IqqQ
jYsAn1ihN2dKOyeFvgrdaEqwsoqsP+os
=8evT
-----END PGP SIGNATURE-----