On Tue, Mar 2, 2010 at 4:51 PM, Ping Cheng <[email protected]> wrote: > On Tue, Mar 2, 2010 at 10:24 AM, Chris Bagwell <[email protected]> wrote: >> On Tue, Mar 2, 2010 at 12:12 PM, Ping Cheng <[email protected]> wrote: >>> Do you know what might be the cause of the jump? A pure raw data >>> issue or something in the code? >> >> Two things: 1) The kernel bug related to loss of event send when both >> fingers have same data. 2) Gesture logic in xf86-input-wacom needs >> some updates (no single finger gestures for example). It still has >> bugs related to finger 2 data sneaking threw and causing jumps. >> You've addressed it in latest linuxwacom and I've addressed it, >> although a different way, in bamboo branch. > > Did you try my "workaround"? Can you email me (myself) your patch for > the fix? I am lazy today.
I don't have hard data yet on if its working since I've been concentrating on master branch were gestures don't really work at all. I'll report back when I have more data. > >> We still need to decide if my related kernel patch should/could go in. > > I have no problem to use your patch. However, since we are making a > workaround, the patch would be easier to be accepted by kernel.org if > it is simple. That's why I am trying to work around the raw data part > without touching anything else. > My may concern with work around in 0.8.5-10 is it seems to only address case were user places fingers down at same location and so adds 1 to second finger values always to account for this (and is missing an upper bounds check). I'm assuming that its just as easy to place two fingers within 1 offset of each other and so your right back to old bug before... but thats the hard data I'm lacking. There are many scenarios in my head that would cause issues without a full fix but right now they are just in my head. The core of my kernel patch is this logic. The new function resets the input structures historical data to values based on current finger so that we can still take advantage of its logic to not send duplicate values at the correct times. - wacom_report_abs(wcombo, ABS_X, x); - wacom_report_abs(wcombo, ABS_Y, y); - wacom_report_abs(wcombo, ABS_PRESSURE, pressure); + wacom_report_abs_hist(wcombo, ABS_X, x, wacom->abs_x[idx]); + wacom->abs_x[idx] = x; + wacom_report_abs_hist(wcombo, ABS_Y, y, wacom->abs_y[idx]); + wacom->abs_y[idx] = y; + wacom_report_abs_hist(wcombo, ABS_PRESSURE, pressure, wacom->abs_pressure[idx]); + wacom->abs_pressure[idx] = pressure; If the main concern is my new function that modifies kernel structures then we could do something like the following with the downside we loss accuracy. But I'm pretty sure the following has bugs because the previous send is not always from the other finger (think of 1 finger standing still and second finger moving in a circle.). The upside of my original patch is its a fix-it-and-forget-it since we 100% report accurate data to applications. + x = (wacom->abs_x[1 - idx] == x) ? x + 1 : x; + wacom_report_abs_hist(wcombo, ABS_X, x, wacom->abs_x[idx]); + wacom->abs_x[idx] = x; + y = (wacom->abs_y[1 - idx] == y) ? y + 1 : y; + wacom_report_abs_hist(wcombo, ABS_Y, y, wacom->abs_y[idx]); + wacom->abs_y[idx] = y; + pressure = (wacom->abs_pressure[1 - idx] == pressue) ? pressure + 1 : pressure; + wacom_report_abs_hist(wcombo, ABS_PRESSURE, pressure, wacom->abs_pressure[idx]); + wacom->abs_pressure[idx] = pressure; Its missing some upper bounds checking to keep it readable. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
