quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html