On Fri, Mar 5, 2010 at 12:12 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: > 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.
Ah, It seems that maybe he moved his devel branch to sf or he forgot to add his remote to freedesktop when he committed last. Checkout: http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=shortlog;h=refs/heads/devel >> >> 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 > I will mess around with this tonight. I left my stylus at home :-( -- Bryan Hundven bryanhund...@gmail.com ------------------------------------------------------------------------------ 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
