Re: [PATCH] CHROMIUM: Input: synaptics - filter out the events with low z values

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Wed, Feb 22, 2012 at 04:24:25PM +0100, Henrik Rydberg wrote:
> > > 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.

The bigger question is why is this needed in kernel. The original
hysteresis with BTN_TOUCH was done for sole benefit of mousedev so that
we could allow somewhat better transition from standard PS/2 mode into
native Synaptics mode with absolute coordinates at time when barely
anyone had Synaptics X driver installed. This was, what, 10 years ago?

Thanks.

-- 
Dmitry