On Wed, Feb 22, 2012 at 7:04 PM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: > Hi Daniel, > >> > So if num_fingers == 2 and only one of a and b returns >> > finger_touched() == true, we fall back to zero fingers? >> >> Actually, yes. In this case, we will have 2 x's and 2 y's, but not >> know which belong to a good finger and which belong to a too light >> finger.... sigh... synaptics... sigh... > > I see the problem. However, ignoring it will just move the problem > forward to another bug report, will it not? Hysteresis is a slam dunk > here. In addition, since the low-pressure state is bound to be > transitional (soon to be followed by a real num_fingers==1 package), > simply skipping such packages might be a better option. In practice, we don't actually see the profile sensor pad sending one low-z finger, and one high-z finger. In the case where one finger is solidly on the pad, and another finger is hovering, lifting, or alighting, the pad sends 2 high-z fingers, with one of them having a completely wrong x or y coordinate. The two reported z-values are nearly, but not exactly, identical. I can't think of good fix for this, other than adding finger tracking and filtering out via 'moved-too-far-too-fast', where possible, and I'd prefer that this be handled in userspace. The 1-low-z && 1-high-z case that we are discussing here isn't actually ever triggered; either both fingers are high-z, or neither are. The real usefulness of this patch is filtering out the 1-low-z-finger and 2-low-z fingers cases. As for the hypothetical 1-finger-hi, 1-finger-low case, which I asked Chung-yih to add because it seemed like a good idea in theory... Yes, I think you have a good point. Thanks to evdev's stateful nature, simply skipping the (1-strong,1-weak) packet might actually work better than forcing num_fingers == 0. For cases where a second finger is temporarily reporting low-z because it is arriving or leaving, evdev would just lock the (1 or 2 initial) fingers in their current position until the transition is over, and then start reporting the new number of fingers at their new positions. For cases where there is one high-z finger, and a hovering thumb or palm triggers 2-finger reporting temporarily (without ever going above the threshold), the original finger will get frozen in its current position until the hovering finger is no longer detected, and then snap to its new position. This might cause strange sudden jumps, but that seems unavoidable. I'm not sure hysteresis is a "slam dunk"... in fact, I don't see how it would help much. But, it is hard to argue against adding the functionality, since the hysteresis window can be made arbitrarily small. Perhaps if you are inclined, you can elaborate on why you think it is important. Thanks for you excellent feedback! -Daniel > >> > Why not introduce hysteresis for all fingers here? There is an example >> > implementation in bcm5974.c in the same directory. >> >> Good idea, can it be in a different, follow-up patch? > > Why should it be? > > Thanks, > Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
