lkml.org 
[lkml]   [2015]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 4.0 REGRESSION FIX] alps: Fix left touchpad button getting stuck when using it with trackpoint
    Date
    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
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2015-04-08 23:01    [W:3.707 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site