On Fri, Mar 5, 2010 at 1:47 PM, Bryan Hundven <bryanhund...@gmail.com> wrote:
> On Fri, Mar 5, 2010 at 6:33 AM, Chris Bagwell <ch...@cnpbagwell.com> wrote:
>> I see some cleanup logic that I don't understand that fixes when it
>> thinks its an eraser but really is a stylus... but I do not see the
>> opposite cleanup to fix stylus that are really erasers (see
>> isdv4Parse(), around line 513). Perhaps having the device, you
>> understand the comment in code better about "sideswitch".
>
> line 523 (on devel branch). On the stylus I have, there is a red tip,
> a button on the side and the eraser.
> I'm guessing that the sideswitch is this button on the side.
> On Windows, when you hold down the button and touch the screen with
> the tip it presses the 2nd input (mouse) button. Granted that is all
> configurable from userspace.
Ahh, I get it now. Thanks.
Something strange is going on with Peter's git. It can't see these
changes. Its the "devel" branch, right? Everything on freedesktop
shows at least 8 days old.
>
> I'm not sure about:
> 514 cur_type = (ds->buttons & 4) ? ERASER_ID : STYLUS_ID;
> Mostly the (ds->buttons & 4). In this case, would this be the side button?
No, it seems to be using a pseudo-button 3 (bit 3 = 0x04) to represent
when your using eraser.
Because your still seeing "bad magic" messages, I've got a concern
that we are throwing out packets that are related to going out of
proximity. If this occurs, we will never switch tools because for
case of pen to eraser, it will only make this decision on transition
from out of proximity to in proximity. That work around logic related
to side button seems to be related to why eraser to pen always works.
It seems that in error cases, the current code is throwing away to
much data. It would be hard to ever get back in sync this way. Can
you search in wcmISDV4.c and look for this code:
/* Coordinate data bit check */
if (data[0] & 0x40) /* control data */
return common->wcmPktLength;
else if ((n = wcmSerialValidate(common,data)) > 0)
return n;
And change that "return n;" to "return 1;". What I'm hoping this does
is makes wcmSerialValidate in next run scan the buffer for beginning
of next valid packet instead of throwing out a whole wcmPktLength
worth of data always. If the basic concept works then there are some
better cleanups to be made.
That may allow you to start seeing that out-of-proximity message. You
may also try experiment and have the "return common->wcmPktLength;"
also be a "return 1;" so a similar scan will occur.
Chris
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
