On Wed, Mar 10, 2010 at 12:26 AM, Thomas Jaeger <thjae...@gmail.com> wrote: > Thanks, just confirming that the regression doesn't occur anymore on the > current isdv4 branch. Sorry it took me so long to respond. > > Tom > > On 03/09/2010 12:43 AM, Peter Hutterer wrote: >> On Mon, Mar 08, 2010 at 12:16:00PM -0600, Chris Bagwell wrote: >>> Have we verified yet if these ISDV4 devices return 2 sizes of packets? >>> The logic in isdv4Parse() reads to me like it must or else your only >>> going to be able to parse pen data or touch data but not both. >>> >>> This development branch changes things so that packet size is only >>> computed in isdv4GetRanges(). Because of order of checks, its going >>> to prefer length of touch packets. This means your only going to >>> execute touch (finger) logic in isdv4Parse(); even in the case of pen >>> packets. >>> >>> Assuming pen packets are length 9 and touch length 5 for Thomas's >>> device, I think that has side affect of throwing away roughly every >>> other pen packet... and thus the resolution issue. But if this is the >>> case, I'm surprised that touch packets are close enough to pen packets >>> to get any movement. >> >> I think I may have it now, thanks much for the pointers. The patch is >> attached but it also needs a revert of the "Remove superfluous packet-length >> assignment" patch on the isdv4 branch. >> >> I'm a bit confused though, in the original code, all data was read into a >> buffer, then the first byte of this buffer was checked and the >> packet length decided on. Then the code would read as many packets as viable >> from this buffer, until the remainder was < pktlen. I'm a bit confused on >> how this code handled packets on different lengths though since it'd always >> check the first byte in the buffer, never of the actual packet. >> >> With the devel tree, I think the issue is with one line - that we only >> checked the first byte of the buffer as well but not of the data passed in. >> Given that each time we get data this is supposed to be a whole packet we >> can assume that the first byte contains the info we need. does this make >> sense? >> >> I've pushed the tree to my freedesktop repo for testing, branch devel and >> isdv4 is rebased on top of it.
Tested the latest from the freedesktop devel. Stylus+sidebutton+eraser is working great! Interesting progress with Touch though. The issue that Tom and I were seeing before with stylus in the second post of this thread seems to be happening a little bit with touch. Attached is another xournal session, where after drawing a circle in the middle of the screen while varying the pressue from hardly touching the screen to a slight press, I was able to finally capture the cursor jump from the current touch location to [0,0]. I didn't get a response from the previous thread, but I was told to run: xinput set-prop "Serial Wacom Tablet touch" "Wacom Debug Levels" 10 10 and it returns: property Wacom Debug Levels doesn't exist, you need to specify its type and format Does anyone know the type and format for this is? -- Bryan Hundven bryanhund...@gmail.com
2010-03-10-touch-issue-02-02.pdf
Description: Adobe PDF document
------------------------------------------------------------------------------ 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
