Hi All, Chris Banal recently reported an issue on Bamboo tablets. If you drew with stylus quickly towards white lines of tablet (stylus maximum area) then the cursor would stop somewhere short of the edge of the screen. If you drew slowly then you could usually get to the edge.
I verified that the kernel driver was sending X/Y values all the way to the edge and then with Chris' help we isolated the issue down to the filtering done in wcmFilter.c. The rest of email is exact details and I'm hoping someone has some good ideas on how or if we should resolve this. Any changes probably need to be done by someone that has more then a single tablet (not me :) ). We are doing a simple median average filter over 4 samples in xf86-input-synaptics to smooth out sampling errors. I did some quick tests on resolution of quick strokes (for example, moving over 1 inch of tablet within 1 second). It came out to around 150-200 units per packet. Based on that, the simple median average we do can introduce an error/offset of around 400-600 units. Bamboo's resolution is 2540 units per inch so we are talking an error of between 1/6 and 1/4 an inch... and I think some cases can be even higher. If you try drawing about 1/4 an inch on tablet then that amount of movement is about how far away from edge of screen fast strokes will stop. Its a pretty noticeable amount (maybe a 1/2 inch from edge on my monitor). Now that you know basic source of issue, I'm sure we could invent some other filtering issues were drawings look different based on how fast you draw them. Maybe your brain can compensate when free hand but tracing would be an issue. Do people have ideas on better filtering routines to prevent this? Especially those statistical math wiz's out there. Here's a few I had: * Reduce window to 2 samples or perhaps dynamically reduce it based on time elapsed since last packet (shorter average window for close together samples in time). * Switch to decaying weighted average of samples to give priority to most recent location. * Move filtering into kernel side. A lot of input devices send duplicate packets as long as contact exists. If Wacom follows this model then you'll eventually fill 4 packet window with same values and to user it will look like continued movement until 4 duplicate samples defeat averaging. Still the edge problem exists: you can go out of proximity before 4 duplicate values are processed. But it may fix some non-edge cases. Chris ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
