Re: [PATCH 7/7] elantech: average the two coordinates when 2 fingers

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

On Sat, Jul 31, 2010 at 11:28:20AM +0200, Henrik Rydberg wrote:
> On 07/30/2010 11:41 PM, Éric Piel wrote:
> 
> [...]
> 
> >> It is true that there are no specific section on how to handle the ABS_X/Y
> 
> >> events, and different drivers have slightly different strategies. However,
> >> common to them all is that a single finger is consistently used to report the
> >> events.
> > Maybe it would be useful to add a paragraph to the mt-protocol document
> > about the relation with the single-touch events.
> 
> 
> Indeed.
> 
> > Well as an anecdote, on my old laptop with a single-touch synaptics
> > hardware, when I press 2 fingers, the average point is reported. That's
> > all in hardware, though so it probably doesn't count as a typical driver
> > behaviour ;-)
> 
> 
> Those devices have no other information to report.
> 
> >>> More specifically, on this hardware, when there are two fingers, we get
> 
> >>> only the lower coordinates and the higher coordinates, but we don't know
> >>> exactly where are the fingers. As there is no tracking, the lower
> >>> coordinate might be the second finger applied, so even if we report just
> >>> the lower coordinates, there is 75% chance that the cursor will jump.
> >>
> >>
> >> Perhaps it is better to not report ABS_X/Y at all in the case of two fingers on
> >> this trackpad. With any reasonable userspace driver, the ABS_X/Y will be masked
> >> out anyways.
> > What do you mean? ABS_X/Y is still very useful, for example for gesture,
> > or to manage horizontal/vertical scrolling. In the xorg synaptics
> > driver, it's not used to move the cursor position, but it's definitely
> > not masked out!
> 
> 
> Maybe the idea sounds radical, but there is a rationale.
> 
> The semantics of ABS_X/Y is a singular, well-defined point. In the trackpad
> case, the movement of that point is used to guide a pointer on screen, but there
> are other scenarios.
> 
> In the presence of multiple touch points, both ABS_X/Y and the pointer are
> ill-defined. This simple fact has far-reaching implications; in Xorg land, there
> is a whole new input protocol cooking to deal with it. For all practical
> purposes, the traditional ABS_X/Y point has no meaning in the multitouch case.
> 
> Instead of extending the semantics of ABS_X/Y, one could simply omit the event
> during a multi-finger touch. In practice, this would most likely confuse some
> applications. Sending the last known one-finger touch point should be less
> confusing. Not quite equivalent, but close enough.
> 
> >>> That's actually the reason I prefer the average: it gives a 100%
> >>> expectable behavior (because the average is always correct). In
> >>> practice, when using the xorg synaptics driver, with the default
> >>> 2-fingers-scrolling mode, the cursor never jumps because as soon as the
> >>> second finger is applied, X and Y are not used to move the cursor.
> >>
> >>
> >> It is predictable, but it is still bad behavior. ;-)
> > :
> > I'm completely against not reporting the position with 2 fingers,
> > because definitely, users would lose some features. With 3 and 4
> > fingers, we report the lower coordinates (the only ones provided by the
> > hardware). So it'd be extremely weird not to report any for 2 fingers!
> 
> 
> This sounds like a misunderstanding. To rephrase: the suggestion is to always
> send the last known one-finger touch point, and to update that point only when
> there is a single finger on the pad.
> 

This would break two-finger scrolling mode of synaptics X driver.

> 
> > As a user, I enjoy better when the average is reported, because
> > whichever finger I move, I get a feedback, there is never a finger
> > "hidden" behind the other one. Nevertheless, if consistency matters,
> > let's just leave it as is.
> 
> 
> This behavior can be created in userland using the MT touch points, if so preferred.
> 

-- 
Dmitry
--
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