On Mon, Jan 9, 2012 at 5:20 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote:
> On Mon, Jan 9, 2012 at 3:02 PM, Ping Cheng <pingli...@gmail.com> wrote:
> > On Mon, Jan 9, 2012 at 7:22 AM, Chris Bagwell <ch...@cnpbagwell.com>
> wrote:
> >>
> >>
> >> I'd like to understand this better if ya don't mind.
> >>
> >> First up, is this usecase for absolute or relative mode?
> >
> >
> > Very good question ;-). To be honest, I didn't think about that when I
> > worked on it. It was for touchscreen devices. So, I assumed absolute
> mode.
> > But, from the code, it is clear that I have not taken care of that...
> >
> >>
> >> I'll phrase it like that instead of touchscreen/touchpad since some
> people
> >> put
> >> touchpad in absolute mode. Also, are gestures enabled or disabled?
> >
> >
> > I would suggest that wcmMT only applies to absolute mode unless you see
> if
> > differently. Under this assumption, gestures will have no meaning.
> >
>
> I still don't quite see the issue so hard to say. I assume if its
> useful to absolute then it could be useful to relative.
>
> >>
> >> For relative mode, Alexey just submitted a nice bug fix that may fix
> >> what your really worried about. Previously, during
> >> gestures-with-no-movement we were not storing updated X/Y movement so
> >> when you released gesture you'd get a big jump. I believe this was
> >> seen mostly during transition from 2 fingers to 1 finger (the case
> >> your talking about).
> >
> >
> > The issue is not with gestures.
>
> There was one part that is not exactly gesture related. Its correctly
> setting the oldX/Y values at the right times. If you don't get this
> right for MT then you'll see jumps.
>
> > It is the "raw" ST value we get from the
> > kernel that is jumpy.
>
> When you say ST here, what do you mean? Do you mean ABS_X/Y by ST?
> xf86-input-wacom ignores those when device supports MT. Do you mean
> "raw" values of MT_SLOT==0?
>
> I think you've been working on a touchscreen where Slot 0 is not as
> reliable first touch any more so probably thats what you mean. I do
> not have have much experience with these type and how they would
> behave with xf86-input-wacom.
>
> For this, we probably need small updates to our channel selection
> logic to pick Slot with oldest ID and put it in channel 0 instead of
> always Slot 0.
> >
> >>
> >> Maybe you should try today's git and see if the issue is reproducible
> any
> >> more.
> >
> >
> > Will try, but not for this issue I think.
> >
> >>
> >> Now on the ST vs. MT part. xf86-input-wacom doesn't know ST vs. MT.
> >> Its always MT to it. Sometimes its a MT with a count of 1 but still
> >> MT. So if we are seeing unwanted jumps during touch transitions, I'd
> >> like to understand that better because I think there are real
> >> xf86-input-wacom bugs to fix beyond giving an optional disable.
> >
> >
> > As mentioned above, the jump was "raw", we can not use the ST events
> > reported from the kernel as is when there are more than one finger on the
> > tablet.
> >
> >>
> >> I'm actually a little surprised that ignoring MT events and looking at
> >> only ST events helps instead of hurts. At least in
> >> xf86-input-synatpics, there is special logic to detect transition of
> >> fingers and to account for an expected cursor jump in ST values.
> >
> >
> > How did that work?
>
> They keep it quite simple. When current_num_touch !=
> previous_num_touch then they empty their filter history and require
> filling the history back up (something like 5 packets) before movement
> is allowed. All brands of touchpads seem to have some amount of
> unstable X/Y right at finger transitions.
>
> We used to have something in xf86-input-wacom that waited 4 samples
> before allowing movement when coming into proximity but I can't find
> that logic any more.
>
> We can add history reset in easy enough during touch count transitions
> and it wouldn't be to hard to go back to requiring wcmRawSample's
> worth of packets before movement. We also need to be updating oldX/Y
> when resetting filter window.
>
> Without this and in absolute mode, I could envision in Gimp that
> lifting 1 finger away during 2 finger case could cause a line to be
> drawn towards the remaining finger as the filter window clears out the
> old touches. This could be the jump?
>
> >
> >>
> >> Probably, for wacom it depends on finger release order. If you
> >> release 1st finger before 2nd finger then you should see a nice cursor
> >> jump since finger tracking is forced to move to only remaining finger.
> >
> >
> > You are right. I think that is the root cause of the jump, which I do not
> > have a way to correct, and ST app users do not like.
>
> I'm thinking something like above could help out a lot. I have some
> ideas how to do it but will be the weekend before I can play with it
> to much.
>
Guess what? I pulled today's xf86-input-wacom from git. The new driver only
reacts to one finger on my 0xE5 unit. So, it works as I would like it to
be, at least for now.
I do not think I need to add this new option any more. Thank you all for
your suggestions and feedback. Case closed.
Ping
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
