Re: [PATCH] alps: Fix finger jumps on lifting 2 fingers on v7 touchpad

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

On Wed, May 20, 2015 at 07:39:48PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 20-05-15 18:40, Dmitry Torokhov wrote:
> >On Wed, May 20, 2015 at 11:16:53AM +0200, Hans de Goede wrote:
> >>On v7 touchpads sometimes when 2 fingers are moved down on the touchpad
> >>until they "fall of" the touchpad, the second touch will report 0 for y
> >>(max y really since the y axis is inverted) and max x as coordinates,
> >>rather then reporting 0, 0 as is expected for a non touching finger.
> >>
> >>This commit detects this and treats these touches as non touching.
> >>
> >>See the evemu-recording here:
> >>https://bugzilla.redhat.com/attachment.cgi?id=1025058
> >>
> >>BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1221200
> >>Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>---
> >>  drivers/input/mouse/alps.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >>diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> >>index 745921f..9bc4343 100644
> >>--- a/drivers/input/mouse/alps.c
> >>+++ b/drivers/input/mouse/alps.c
> >>@@ -949,6 +949,11 @@ static void alps_get_finger_coordinate_v7(struct input_mt_pos *mt,
> >>  	case V7_PACKET_ID_TWO:
> >>  		mt[1].x &= ~0x000F;
> >>  		mt[1].y |= 0x000F;
> >>+		/* Detect false-postive touches where x & y report max value */
> >>+		if (mt[1].y == 0x7ff && mt[1].x == 0xff0) {
> >>+			mt[1].x = 0;
> >>+			/* y gets set to 0 at the end of this function */
> >
> >I think this is too fragile; I believe we can spare an assignment and
> >maybe compiler will optimize it out.
> >
> >I can fix it up locally unless there are objections to having this extra
> >assignment.
> 
> I object to having the extra assignment, the comment is there, because the setting
> to 0 at the end of the function is done in the form of:
> 
>         mt[0].y = 0x7FF - mt[0].y;
>         mt[1].y = 0x7FF - mt[1].y;
> 
> So if you add a "mt[1].y = 0" assignment in stead of the comment then you're
> actually making mt[1].y = 0x7ff instead of 0, that is why there is a comment
> there instead of an assignment. Feel free to modify the comment to make this
> more clear ...
> 
> And yes normally the firmware sends 0x7ff for y and 0 for x when there is no touch,
> except sometimes it glitches and it sends 0x7ff for y and 0xff0 for x when there is
> no touch, which is what this commit catches (this has been tested by the reporter).

Ah, I see.

Thanks.

-- 
Dmitry