linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Buck <mb-tmp-yvahk-vachg@gromit.dyndns.org>
To: linux-input@vger.kernel.org
Subject: Stuck buttons on ALPS touchpad
Date: Wed, 3 Mar 2010 23:07:35 +0100	[thread overview]
Message-ID: <20100303220735.GC26412@gromit.at.home> (raw)

Hi,

I've got a little problem with the ALPS touchpad in my Dell Inspiron 8200
(identified as E7 report: 32 02 14). Sometimes when pressing the touchpad
buttons, they get stuck (in the driver only, of course :-) and are released
only after moving the finger on the touchpad. This behaviour started after
upgrading to kernel 2.6.32.8. With the 2.6.26.5 kernel I was using
previously, it didn't occur.

I identified the change causing this to be the following one from Ulrich
Dangel:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d7ed5d883c09c5474f842dcb148515dfaef2a567

> Input: ALPS - handle touchpoints buttons correctly
> 
> When pressing any button belonging to the touchpoint, the generated
> click events don't belong to the touchpoint but to the touchpad.
> This patch fixes this behaviour, the events will be sent via the
> correct device, so scrolling with touchpoint is possible.

On my machine, this seems to sometimes direct the touchpad button release
event to the touchpoint, causing the old touchpad button state to remain
until the next packet from the touchpad arrives. Looking at the packets
received, it's obvious why this happens:

Normal left button down/up sequence:
[  269.805058] ff 11 20 49 32 00
[  269.983019] ff 11 20 48 32 00

Broken left button down/up sequence:
[  273.947184] ff 11 20 49 32 00
[  274.106059] ff 11 20 49 32 00
[  274.262486] ff 00 00 08 00 7f

As you can see, when the button gets stuck, the touchpad sends the button
down event twice and instead of the normal button up event, it sends one
with z==127 which Ulrich's change interprets as belonging to the touchpoint.

Interestingly, kernel 2.6.32.8 already has all the code to fix this, it's
just not enabled for my touchpad. alps_report_buttons() checks the
ALPS_PS2_INTERLEAVED flag and if set, directs button up events to the
same device that got the button down event, regardless of the source derived
from the packet. Does anybody see a reason why this shouldn't be done
unconditionally regardless of the ALPS_PS2_INTERLEAVED flag? Or should there
be another flag that enables the workaround just for selected models?

Any other ideas how to fix this?

Thanks,
Martin

                 reply	other threads:[~2010-03-03 22:14 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100303220735.GC26412@gromit.at.home \
    --to=mb-tmp-yvahk-vachg@gromit.dyndns.org \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).