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@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). Ah, I see. Thanks. -- Dmitry -- 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
