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.

My assumptions align with the bisect below because thats the one where
you stopped updating length between 9/5 values at each packet read.

Chris

p.s. I like the direction your heading.  It would be nice to somehow
pull isdv4ParseQuery() and isdv4ParseTouchQuery() over to isdv4Parse()
because they are much easier to read.  I think thats somehow your
intent because you removed isdv4ValidateSerial() from isdv4Parse() but
you didn't replace it with any new parsing or validation logic.


On Mon, Mar 8, 2010 at 2:19 AM, Peter Hutterer <peter.hutte...@who-t.net> wrote:
> On Mon, Mar 08, 2010 at 02:40:17AM -0500, Thomas Jaeger wrote:
>> I see a regression introduced in dc513e8e1e6813e6d8d0f101a56fbf1b2f388dbc:
>> Strokes are noticeably less smooth, they look more like sequences of
>> line segments.  My guess is that this is either due to increased jitter
>> or to a reduced sampling frequency -- no idea why the patch would
>> trigger this, though.  Let me know if I should investigate further.
>
> hmm. weird. I can see how 7b89318ed235cbbad0312e56efa9443bf96b47c9 might
> have this effect if there's a bug in the code but the other one? not sure
> about this. can you put some xf86Msg in to see which code path gets
> triggered - both before and after the move - and if those paths are the
> same?
>
> Cheers,
>  Peter
>
>> On 03/07/2010 11:30 PM, Peter Hutterer wrote:
>> > Lads and lasses,
>> >
>> > I've just pushed the isdv4 branch onto
>> > git://people.freedesktop.org/~whot/xf86-input-wacom.git. This is the
>> > beginning of a rework/cleanup of the ISDV4-related code with the possible
>> > end solution of moving it into the kernel (there's more work needed for 
>> > this
>> > though and I need to understand the protocol much better first).
>> >
>> > The branch is based on my devel branch from last week and most of the
>> > changes should be harmless (it's only 10 patches so far). if you have an
>> > ISDV4 device, please give this a test run and let me know if it breaks (or
>> > doesn't) and if it does maybe also which commit breaks it. I don't have a
>> > device so anything that gcc doesn't catch will go unnoticed by me.
>> >
>> > The plan with this branch is to move the whole ISDV4 parsing code into
>> > little helper functions to make the other isdv4-related code a bit more
>> > streamlined and easier to understand for someone new to the code.
>> >
>> > Thanks in advance for testing and feedback!
>> >
>> > Cheers,
>> >   Peter
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>

------------------------------------------------------------------------------
Download Intel&#174; 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

Reply via email to