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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
---
  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).

Regards,

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




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux