* [PATCH 4.0 REGRESSION FIX 0/1] alps: Fix left touchpad button getting stuck @ 2015-04-08 15:38 Hans de Goede 2015-04-08 15:38 ` [PATCH 4.0 REGRESSION FIX] alps: Fix left touchpad button getting stuck when using it with trackpoint Hans de Goede 0 siblings, 1 reply; 5+ messages in thread From: Hans de Goede @ 2015-04-08 15:38 UTC (permalink / raw) To: Dmitry Torokhov, Linus Torvalds Cc: Hans de Bruin, Pali Rohár, linux-input, linux-kernel Hi Linus, Dmitry, Sorry for the last minute regression fix, but the existence of this regression was not entirely clear until Hans de Bruin send a very clear reproducer this morning. I'm not sure if this is 4.0 material, it does fix a real regression, the fix is pretty simple and safe (*), and when triggered the behavior (stuck mouse button) is nasty, which all counts in favor of fixing this. OTOH this only affects somewhat older hardware and only a certain usage pattern (using the trackpoint with the touchpad buttons). Anyways the call if this is 4.0 material is up to you (Linus and Dmitry), I'm just trying to make sure you're aware of this issue and the patch. The details of the actual bug + fix can be found in the commit msg of the patch. Regards, Hans *) The fix restores 3.19 behavior for alps v2 dualpoint touchpad/stick combos ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 4.0 REGRESSION FIX] alps: Fix left touchpad button getting stuck when using it with trackpoint 2015-04-08 15:38 [PATCH 4.0 REGRESSION FIX 0/1] alps: Fix left touchpad button getting stuck Hans de Goede @ 2015-04-08 15:38 ` Hans de Goede 2015-04-08 20:26 ` Pali Rohár 0 siblings, 1 reply; 5+ messages in thread From: Hans de Goede @ 2015-04-08 15:38 UTC (permalink / raw) To: Dmitry Torokhov, Linus Torvalds Cc: Hans de Bruin, Pali Rohár, linux-input, linux-kernel, Hans de Goede When the left touchpad button gets pressed, and then the trackpoint is moved, and then the button is released, the following happens: 1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1 2) pointingstick packet is received, the hw will report a BTN_LEFT 1 in this packet because when the trackstick is active it communicates the combined touchpad + pointingstick buttons in the trackstick packet, since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter to alps_report_buttons the combining is not detected and the pointingstick evdev node will also report BTN_LEFT 1 3) on release of the button a pointingstick packet with BTN_LEFT 0 is received, and the pointingstick evdev node will report BTN_LEFT 0 Note how because of the passing as NULL for dev2 the touchpad evdev node will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button. This is a regression in 4.0 introduced by commit 04aae283ba6a8 ("Input: ALPS - do not mix trackstick and external PS/2 mouse data") This commit fixes this by passing in the touchpad evdev as dev2 parameter when calling alps_report_buttons for the pointingstick on alps v2 devices, so that alps_report_buttons correctly detect that we're already reporting the button as pressed via the touchpad evdev node, and will also send the release event there. Reported-by: Hans de Bruin <jmdebruin@xmsnet.nl> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/input/mouse/alps.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c index 80b6eca..6962c26 100644 --- a/drivers/input/mouse/alps.c +++ b/drivers/input/mouse/alps.c @@ -1159,13 +1159,14 @@ static void alps_report_bare_ps2_packet(struct psmouse *psmouse, bool report_buttons) { struct alps_data *priv = psmouse->private; - struct input_dev *dev; + struct input_dev *dev, *dev2 = NULL; /* Figure out which device to use to report the bare packet */ if (priv->proto_version == ALPS_PROTO_V2 && (priv->flags & ALPS_DUALPOINT)) { /* On V2 devices the DualPoint Stick reports bare packets */ dev = priv->dev2; + dev2 = psmouse->dev; } else if (unlikely(IS_ERR_OR_NULL(priv->dev3))) { /* Register dev3 mouse if we received PS/2 packet first time */ if (!IS_ERR(priv->dev3)) @@ -1177,7 +1178,7 @@ static void alps_report_bare_ps2_packet(struct psmouse *psmouse, } if (report_buttons) - alps_report_buttons(dev, NULL, + alps_report_buttons(dev, dev2, packet[0] & 1, packet[0] & 2, packet[0] & 4); input_report_rel(dev, REL_X, -- 2.3.4 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 4.0 REGRESSION FIX] alps: Fix left touchpad button getting stuck when using it with trackpoint 2015-04-08 15:38 ` [PATCH 4.0 REGRESSION FIX] alps: Fix left touchpad button getting stuck when using it with trackpoint Hans de Goede @ 2015-04-08 20:26 ` Pali Rohár 2015-04-12 23:00 ` Dmitry Torokhov 0 siblings, 1 reply; 5+ messages in thread From: Pali Rohár @ 2015-04-08 20:26 UTC (permalink / raw) To: Hans de Goede Cc: Dmitry Torokhov, Linus Torvalds, Hans de Bruin, linux-input, linux-kernel [-- Attachment #1: Type: Text/Plain, Size: 3309 bytes --] On Wednesday 08 April 2015 17:38:52 Hans de Goede wrote: > When the left touchpad button gets pressed, and then the > trackpoint is moved, and then the button is released, the > following happens: > > 1) touchpad packet is received, touchpad evdev node reports > BTN_LEFT 1 2) pointingstick packet is received, the hw will > report a BTN_LEFT 1 in this packet because when the > trackstick is active it communicates the combined touchpad + > pointingstick buttons in the trackstick packet, since > alps_report_bare_ps2_packet passes NULL (*) for the dev2 > parameter to alps_report_buttons the combining is not > detected and the pointingstick evdev node will also report > BTN_LEFT 1 > 3) on release of the button a pointingstick packet with > BTN_LEFT 0 is received, and the pointingstick evdev node will > report BTN_LEFT 0 > > Note how because of the passing as NULL for dev2 the touchpad > evdev node will never send BTN_LEFT 0 in this scenario > leading to a stuck mouse button. > > This is a regression in 4.0 introduced by commit 04aae283ba6a8 > ("Input: ALPS - do not mix trackstick and external PS/2 mouse > data") > > This commit fixes this by passing in the touchpad evdev as > dev2 parameter when calling alps_report_buttons for the > pointingstick on alps v2 devices, so that alps_report_buttons > correctly detect that we're already reporting the button as > pressed via the touchpad evdev node, and will also send the > release event there. > > Reported-by: Hans de Bruin <jmdebruin@xmsnet.nl> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> Patch looks good to me, so Acked-by: Pali Rohár <pali.rohar@gmail.com> As this is regression in 4.0 (which was not in 3.19), I'm also for fixing it. But decision is of course on maintainers... I think this is nice example how touchpad+trackstick protocol at HW level should not looks like. It is complete mess what HW engineers invented and how their devices pass input data to operating system. > --- > drivers/input/mouse/alps.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/mouse/alps.c > b/drivers/input/mouse/alps.c index 80b6eca..6962c26 100644 > --- a/drivers/input/mouse/alps.c > +++ b/drivers/input/mouse/alps.c > @@ -1159,13 +1159,14 @@ static void > alps_report_bare_ps2_packet(struct psmouse *psmouse, bool > report_buttons) > { > struct alps_data *priv = psmouse->private; > - struct input_dev *dev; > + struct input_dev *dev, *dev2 = NULL; > > /* Figure out which device to use to report the bare packet > */ if (priv->proto_version == ALPS_PROTO_V2 && > (priv->flags & ALPS_DUALPOINT)) { > /* On V2 devices the DualPoint Stick reports bare packets > */ dev = priv->dev2; > + dev2 = psmouse->dev; > } else if (unlikely(IS_ERR_OR_NULL(priv->dev3))) { > /* Register dev3 mouse if we received PS/2 packet first > time */ if (!IS_ERR(priv->dev3)) > @@ -1177,7 +1178,7 @@ static void > alps_report_bare_ps2_packet(struct psmouse *psmouse, } > > if (report_buttons) > - alps_report_buttons(dev, NULL, > + alps_report_buttons(dev, dev2, > packet[0] & 1, packet[0] & 2, packet[0] & 4); > > input_report_rel(dev, REL_X, -- Pali Rohár pali.rohar@gmail.com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 4.0 REGRESSION FIX] alps: Fix left touchpad button getting stuck when using it with trackpoint 2015-04-08 20:26 ` Pali Rohár @ 2015-04-12 23:00 ` Dmitry Torokhov 0 siblings, 0 replies; 5+ messages in thread From: Dmitry Torokhov @ 2015-04-12 23:00 UTC (permalink / raw) To: Pali Rohár Cc: Hans de Goede, Linus Torvalds, Hans de Bruin, linux-input, linux-kernel On Wed, Apr 08, 2015 at 10:26:36PM +0200, Pali Rohár wrote: > On Wednesday 08 April 2015 17:38:52 Hans de Goede wrote: > > When the left touchpad button gets pressed, and then the > > trackpoint is moved, and then the button is released, the > > following happens: > > > > 1) touchpad packet is received, touchpad evdev node reports > > BTN_LEFT 1 2) pointingstick packet is received, the hw will > > report a BTN_LEFT 1 in this packet because when the > > trackstick is active it communicates the combined touchpad + > > pointingstick buttons in the trackstick packet, since > > alps_report_bare_ps2_packet passes NULL (*) for the dev2 > > parameter to alps_report_buttons the combining is not > > detected and the pointingstick evdev node will also report > > BTN_LEFT 1 > > 3) on release of the button a pointingstick packet with > > BTN_LEFT 0 is received, and the pointingstick evdev node will > > report BTN_LEFT 0 > > > > Note how because of the passing as NULL for dev2 the touchpad > > evdev node will never send BTN_LEFT 0 in this scenario > > leading to a stuck mouse button. > > > > This is a regression in 4.0 introduced by commit 04aae283ba6a8 > > ("Input: ALPS - do not mix trackstick and external PS/2 mouse > > data") > > > > This commit fixes this by passing in the touchpad evdev as > > dev2 parameter when calling alps_report_buttons for the > > pointingstick on alps v2 devices, so that alps_report_buttons > > correctly detect that we're already reporting the button as > > pressed via the touchpad evdev node, and will also send the > > release event there. > > > > Reported-by: Hans de Bruin <jmdebruin@xmsnet.nl> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > Patch looks good to me, so > > Acked-by: Pali Rohár <pali.rohar@gmail.com> > > As this is regression in 4.0 (which was not in 3.19), I'm also > for fixing it. But decision is of course on maintainers... Doh! Missed the 4.0 so had to tag it for stable. -- Dmitry ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 4.0 REGRESSION FIX] alps: Fix left touchpad button getting stuck when using it with trackpoint @ 2015-04-12 23:00 ` Dmitry Torokhov 0 siblings, 0 replies; 5+ messages in thread From: Dmitry Torokhov @ 2015-04-12 23:00 UTC (permalink / raw) To: Pali Rohár Cc: Hans de Goede, Linus Torvalds, Hans de Bruin, linux-input, linux-kernel On Wed, Apr 08, 2015 at 10:26:36PM +0200, Pali Rohár wrote: > On Wednesday 08 April 2015 17:38:52 Hans de Goede wrote: > > When the left touchpad button gets pressed, and then the > > trackpoint is moved, and then the button is released, the > > following happens: > > > > 1) touchpad packet is received, touchpad evdev node reports > > BTN_LEFT 1 2) pointingstick packet is received, the hw will > > report a BTN_LEFT 1 in this packet because when the > > trackstick is active it communicates the combined touchpad + > > pointingstick buttons in the trackstick packet, since > > alps_report_bare_ps2_packet passes NULL (*) for the dev2 > > parameter to alps_report_buttons the combining is not > > detected and the pointingstick evdev node will also report > > BTN_LEFT 1 > > 3) on release of the button a pointingstick packet with > > BTN_LEFT 0 is received, and the pointingstick evdev node will > > report BTN_LEFT 0 > > > > Note how because of the passing as NULL for dev2 the touchpad > > evdev node will never send BTN_LEFT 0 in this scenario > > leading to a stuck mouse button. > > > > This is a regression in 4.0 introduced by commit 04aae283ba6a8 > > ("Input: ALPS - do not mix trackstick and external PS/2 mouse > > data") > > > > This commit fixes this by passing in the touchpad evdev as > > dev2 parameter when calling alps_report_buttons for the > > pointingstick on alps v2 devices, so that alps_report_buttons > > correctly detect that we're already reporting the button as > > pressed via the touchpad evdev node, and will also send the > > release event there. > > > > Reported-by: Hans de Bruin <jmdebruin@xmsnet.nl> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > Patch looks good to me, so > > Acked-by: Pali Rohár <pali.rohar@gmail.com> > > As this is regression in 4.0 (which was not in 3.19), I'm also > for fixing it. But decision is of course on maintainers... Doh! Missed the 4.0 so had to tag it for stable. -- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-04-12 23:00 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-08 15:38 [PATCH 4.0 REGRESSION FIX 0/1] alps: Fix left touchpad button getting stuck Hans de Goede 2015-04-08 15:38 ` [PATCH 4.0 REGRESSION FIX] alps: Fix left touchpad button getting stuck when using it with trackpoint Hans de Goede 2015-04-08 20:26 ` Pali Rohár 2015-04-12 23:00 ` Dmitry Torokhov 2015-04-12 23:00 ` Dmitry Torokhov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.