XInput 2: the big picture, relationship to toolkits

[Chuck Robey]

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

Chuck Robey wrote:

Because of some system instability injected because of all of my X testing, I
didn't think that this went out (the machine crashed moments later, and didn't
get into the send cache at all).  It's my normal tack, to go back and heavily
edit my mails before I send them.  This one didn't get the editing.  A bit
embarrassing, although I did mean all of it in actuality, I wouldn't have said
it this way at all.

All caused by a very unstable driver I have.  I'm *sort-of* sorry...

> 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
> 
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

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

iEUEARECAAYFAkipvlwACgkQz62J6PPcoOmCqQCbBSS4q22OvMRkUbYvqDfuNnaw
hZMAl1Dd3c5ecWsnWoYdJdEriWXH+mc=
=bunN
-----END PGP SIGNATURE-----