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