> > 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. Urgh. > 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. It sounds like the z value in the second packet carries zero information. If that were true, the fact that the patch is effective suggests the semi-mt slot reporting could follow BTN_TOUCH, more or less. In doing so, you would also obtain hysteresis automatically. > 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. I suspect it depends a bit on the values of low-z and hi-z, respectively? Otherwise, there really is no information in that extra packet. > 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. A lot of things seem unavoidable with this hardware. :-) > 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. The most striking effect is the ability to better retain a drag. Although the statement was made in light of possible (1-strong,1-weak) packets, it should help in the 2-weak case too. 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
