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. ------------------------------------------------------------------------------ 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
