On Wed, Mar 10, 2010 at 03:26:26AM -0500, Thomas Jaeger wrote: > Thanks, just confirming that the regression doesn't occur anymore on the > current isdv4 branch. Sorry it took me so long to respond.
Hi Tom, Thanks much for testing! Can you just do me another favour, can you test the current devel branch as well? I rebased and pushed another two patches today and they're likely to go into master before the isdv4 branch is ready. Thanks, Peter PS: please include the SHA of the last tested commits as well so I have some sort of reference - it's the curse of the testing rebasing development branches :) > > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
