Bug 4281

Summary: ALPS Touchpad Tap-to-Click Broken
Product: Drivers Reporter: David Cary Hart (davidhart)
Component: Input DevicesAssignee: Dmitry Torokhov (dmitry.torokhov)
Severity: normal CC: kernel, luke, pat, protasnb, vojtech
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.11 Tree: Mainline
Regression: ---
Attachments: Fix tap mode enabling
Working version of drivers/input/mouse/alps.c

Description David Cary Hart 2005-03-03 07:26:53 UTC
Distribution: Fedora Core 3/Kernel via Korg
Hardware Environment: i686
Software Environment:
Problem Description: While touchpad button and cursor movement are fine,
tap-to-click no longer funtions.

Steps to reproduce: Update from 2.6.10 to 2.6.11.
Comment 1 Hinrik 2005-03-20 06:49:15 UTC
The cursor movement is also more sturdier, it's harder to move it now than it
was in 2.6.10. What I mean is that it's almost impossible to move the cursor
shorter distances, very "unsmooth".
Comment 2 Andrew Morton 2005-03-21 14:22:59 UTC
David, could you please test 2.6.12-rc1, update us on the situation?

Comment 3 David Cary Hart 2005-03-21 14:33:18 UTC
>>David, could you please test 2.6.12-rc1, update us on the situation?<<

Sure. Tuesday. I'll remove psmouse.proto=exps
Comment 4 David Cary Hart 2005-03-21 16:50:59 UTC
OK. That works just fine. FYI the latest Nvidia drivers won't build so I
reverted to the nv driver.

Tap-to-click and cursor movement are as expected.
Comment 5 Hinrik 2005-03-27 20:33:07 UTC
Yes, it's better now, but you still can't use the touchpad to drag windows for
example. In 2.6.10 you could tap twice(not releasing the finger after the second
tap) and drag.

This doesn't work anymore, you have to hold the left-click button with one
finger and then drag on the touchpad with the other, instead of doing it with
just one finger on the touchpad.
Comment 6 Stuart Shelton 2005-04-13 12:13:21 UTC
I've briefly tested 2.6.12-rc2 ... and it's almost there:

Even without using the psmouse.proto=exps argument, the tracking speed is fixed
and you can select areas of text on the VT at any speed, and it doesn't forget
the you're holding the button down.

But there are a couple of things that are better, but not quite right:

The first of these may actually be a video driver issue, rather than input: I
noticed that if I typed to the console fast - being sure not to touch the
touchpad at all - the mouse cursor would sometimes flash briefly.  For example,
typing "dmesg " would cause the cursor to flash once in the centre of the screen
alsmost every time I hit the spacebar.  Not a problem as such, but distracting
once you notice it...
This is not something I've seen prior to 2.6.12.

Secondly, it is still occasionally detecting clicks during movement: If I move
the cursor around the screen, then it occasionally selects the character beneath
it in mid-movement.  I've never had this happen on kernels prior to 2.6.11, so I
assume it's something in the kernel that needs tuning a little further, rather
than me being heavy-handed.

In all, much better - but still in need of a few last tweaks.

NB: I didn't test with X, so this is purely the behavior from a Radeon-driven FB VT.
Comment 7 Stuart Shelton 2005-05-10 08:40:46 UTC
Okay, I've now tested 2.6.12-rc4 too, and get exactly the same behaviour:

Tracking speed is fixed, but when moving the cursor around the screen, it
occasionally highlights the single character underneath it at the time.  This
still happens.

Tapping is totally inoperative, as far as I can tell.

I haven't done enought typing on the rc4 kernel yet to try to reproduce the
typing bug - I'll try that when I next reboot.

In all, though, there doesn't seem to have been any progress since -rc2 :(
Comment 8 Andrew Morton 2005-05-25 15:14:44 UTC
Can you please retest 2.6.12-rc5?
Comment 9 David Cary Hart 2005-05-26 09:39:09 UTC
>>------- Additional Comment #8 From Andrew Morton  2005-05-25 15:14 -------

Can you please retest 2.6.12-rc5?<<

All works perfectly, as far as I can tell and nvidia is fine.

alps.c: Enabling hardware tapping
input: PS/2 Mouse on isa0060/serio1
input: AlpsPS/2 ALPS GlidePoint on isa0060/serio1

Comment 10 Pat Suwalski 2005-06-02 12:28:04 UTC
With 2.6.12-rc5 things finally work for me, however...

I find that in X, with the synaptics driver, tapping is still "slow". With the
pre-2.6.11 functionality, a tap was instantaneous. Now, there is a noticeable
delay with every single-tap.

I'm not sure if it's the kernel driver or the synaptics driver in X, but I can't
seem to get around it.
Comment 11 Joost 2005-06-07 03:39:54 UTC
Hi all,      
I upgraded from 2.6.11 to 2.6.12-rc5 and my tapping vanished. I didn't patch      
anything for alps, only swsusp2. In my dmesg I get these lines at boot:     
alps.c: Enabling hardware tapping     
input: PS/2 Mouse on isa0060/serio0    
input: AlpsPS/2 ALPS GlidePoint on isa0060/serio4    
Is there anything I'd need to get the new tapping behaviour working or is this 
perhaps part of this bug? 
Bye, Joost  
Comment 12 Johan Brannlund 2005-06-13 00:54:04 UTC
Funnily enough, for me the situation is the opposite to what Pat Suwalski got:
2.6.12-rc6 does not get me working tap-to-click, but 2.6.11 does, if I patch it
to remove the disabling of hardware tapping. Dropping the (patched)
drivers/input directory from 2.6.11 into 2.6.12-rc6 also makes tap-to-click work.
This is on an Acer Aspire 1300. dmesg says:

ALPS Touchpad (Glidepoint) detected
input: AlpsPS/2 ALPS TouchPad on isa0060/serio4
Comment 13 Dmitry Torokhov 2005-06-13 01:24:47 UTC
Created attachment 5156 [details]
Fix tap mode enabling


Could you please try the attached patch. It looks like the condition was
reversed and we only try enabling tapping if it is already enabled.


Comment 14 Pat Suwalski 2005-06-13 19:28:10 UTC

I would like to clarify what the appropriate way to test this stuff is.

My report is based on the synaptics driver for X, but that driver seems very,
very flaky, to the point of hard-locking the system. It has so many options and
I just can't get any of this to work.

Do you recommend gpm or something? The kernel side could work perfectly, for all
I know.

I'm worried because I cannot get the old behaviour back and the new behaviour is
highly unstable over here, based on the ways I tested it.
Comment 15 Johan Brannlund 2005-06-13 20:21:48 UTC
Dmitry's patch in comment 13 does enable tap-to-click. On the other hand, with
that patch applied using the right side of the touchpad to scroll doesn't work.
:-( I'm not sure if that used to work in 2.6.12-rc6 or if the patch broke scrolling.

Comment 16 Dmitry Torokhov 2005-06-13 23:55:13 UTC
Hi Pat, 
I have never had a trouble with synaptics driver and I really doubt it can lock 
the system since it does not access hardware at all. It just translates data 
from /dev/input/eventX (not hardware, already sanitized by the kernel) into X 
I would try updating to version 0.14.2 of synaptics driver if you have not done 
so and play with it's config options. I guess you mostly interested in 
MaxTapTime parameter. 
Comment 17 Johan Brannlund 2005-06-14 18:32:20 UTC
After an e-mail exchange with Dmitry, my touchpad now sort-of works with
2.6.12-rc6 (with Dmitry's patch applied). David, you said everything works for
you - are you using the Synaptics X driver? If so, could you please post the
output of "synclient -l" (or the relevant part of your xorg.conf)? 

Tap-to-click is still a bit unreliable for me, but it may just be an issue with
my settings.
Comment 18 David Cary Hart 2005-06-14 19:00:24 UTC
I want to be responsive but I just updated the laptop in question to FC4 with a
clean install. I probably can't get around to this until the weekend.

I should mention that the otherwise ponderous FC4 kernel seems to patch this
issue whereas still requires psmouse.proto=exps.
Comment 19 Pat Suwalski 2005-06-14 21:53:45 UTC

A long update. I'm now running 2.6.12-rc6, and I've tried with and without the
patch. I am using synaptics-0.14.2, on top of X.org 6.8.2.

The patch does enable dragging.

However, like Johan, I do have issues with initiating a double-click as well as
(related) drag events. It doesn't always respond to it. Also, single clicking
seems delayed, in that a tap happens, then a perceptible time, then the event

Here is my (almost stock) configuration:

Section "InputDevice"
  Driver    "synaptics"
  Identifier    "TouchPad"
  Option    "Device"        "/dev/input/mice"
  Option    "Protocol"      "auto-dev"
  Option    "LeftEdge"      "120"
  Option    "RightEdge"     "830"
  Option    "TopEdge"       "120"
  Option    "BottomEdge"        "650"
  Option    "FingerLow"     "14"
  Option    "FingerHigh"        "15"
  Option    "MaxTapTime"        "120"
#  Option    "MaxDoubleTapTime"        "250"
  Option    "MaxTapMove"        "110"
#  Option       "FastTaps" "1"
  #Option    "EmulateMidButtonTime"  "75"
  Option    "VertScrollDelta"   "20"
  Option    "HorizScrollDelta"  "20"
  Option    "MinSpeed"      "0.3"
  Option    "MaxSpeed"      "1.0"
  Option    "AccelFactor"       "0.015"
  Option    "EdgeMotionMinSpeed"    "200"
  Option    "EdgeMotionMaxSpeed"    "200"
  Option    "UpDownScrolling"   "1"
  Option    "CircularScrolling" "1"
  Option    "CircScrollDelta"   "0.1"
  Option    "CircScrollTrigger" "2"
  Option    "RBCornerButton" "0"

Additionally, I looked into the hard lock issue with ssh tailing the X log:

(II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE)
Synaptics DeviceInit called
SynapticsCtrl called.
(II) Mouse1: ps2EnableDataReporting: succeeded
Synaptics DeviceOn called
(--) TouchPad touchpad found

   *** If unresolved symbols were reported above, they might not
   *** be the reason for the server aborting.

Fatal server error:
Caught signal 11.  Server aborting

Please consult the The X.Org Foundation support
         at http://wiki.X.Org
 for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

Finally, tailing /var/log/messages gives this:

Jun 15 00:19:48 inspiron _start called without lock held
Jun 15 00:19:48 inspiron [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called
without lock held
Jun 15 00:19:48 inspiron [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called
without lock held
Jun 15 00:19:48 inspiron [drm:radeon_cp_start] *ERROR* radeon_cp_start called
without lock held
Jun 15 00:19:48 inspiron [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called
without lock held
Jun 15 00:19:48 inspiron [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called
without lock held
Jun 15 00:19:48 inspiron [drm:radeon_cp_start] *ERROR* radeon_cp_start called
without lock held
Jun 15 00:19:48 inspiron [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called
without lock held

(repeated hundreds of times before ssh is closed)

I think that drm is stuck in a loop because the X server is dead. Perhaps it is
drm that takes down the system, though I cannot verify this.

Lastly, I have this compiled into the kernel (no module). Passing
psmouse.proto=exps does not seem to restore the old behaviour over here.
Comment 20 Pat Suwalski 2005-06-14 21:54:54 UTC
I forgot to mention that the crash seems to happen exclusively in what should be
the virtual vertical scrollbar area of the touchpad.
Comment 21 Dmitry Torokhov 2005-06-14 23:24:08 UTC
I have no idea about crash, I'd think DRM is a suspect. For the record I was    
using synaptics 0.13.5 for a pretty long time and yesterday upgraded to 0.14.2    
and never had ant problems or lockups. I used to use nvidia binary driver but    
some time ago switched to "nv" open source driver. Just FYI, not saying that it    
excludes synaptics from being suspect, just personal experience.    
As far as tap not being instantenous - try reducing MaxDoubleTapTime. If I  
understand it correctly this is the time driver has to wait before deciding 
that the tap it saw was just a single tap and not a part of double tap. 
psmouse.proto=exps - could you please boot with "i8042.debug 
psmouse.proto=exps" and send your dmesg to dtor_core@ameritech.net 
Comment 22 Johan Brannlund 2005-07-03 20:43:11 UTC
I've looked at this a little more and with help from Peter Osterlund I've
managed to locate the problem a bit more precisely. At least for me, the problem
lies in alps_process_packet in drivers/input/mouse/alps.c . If I replace this
function with the one from 2.6.11, I get reliable tap-and-drag. If I have some
spare time, I'll try gradually replacing the parts of that function with the
equivalent pieces from 2.6.12 until something breaks.

Comment 23 Johan Brannlund 2005-07-13 00:37:53 UTC
I've looked into this some more and it appears that alps_process_packet() in
drivers/input/mouse/alps.c is the culprit. If I replace that function with a
version that's basically the 2.6.11 version + minor fixes, then everything works
reliably again.

I've tried to piece by piece morph this function into its 2.6.12 version to see
when it breaks but I haven't yet been able to exactly pinpoint the problem. I'll
attach the version of alps.c that works for me.

Comment 24 Johan Brannlund 2005-07-13 00:39:54 UTC
Created attachment 5320 [details]
Working version of drivers/input/mouse/alps.c
Comment 25 Luke Reeves 2005-07-13 17:17:52 UTC
The new alps.c file works for me under on a Sony Vaio TR2/B and
correctly enables the double-click to drag behaviour.  Thanks Johan.
Comment 26 Stuart Shelton 2005-09-06 05:43:03 UTC
I've now upgraded to 2.6.13 (after finding the ALPS driver broken in 2.6.11 and
2.6.12) and I'm still having problems on my VAIO Z1:

* I've tried the patches included on this bug, and none have fixed the touchpad
behavior for me :(

* In a text-mode console, the touchpad randomly taps during movement and is
incapable of selecting large areas of text (I run a 175x65 text-console, and
after selecting over about 1/3 of this strange selection behavior occurs - the
selection highlight will either stop, or I'll get a gap(!) in the highlighted
area.  Nothing after the selection stops/the gap is copied to the paste buffer)
* In a text-mode console, moving the cursor around the screen leaves
single-character artifacts where a character is left in reverse-video (as if the
cursor was still positioned over it) after the cursor has moved on.  The
character beneath the cursor isn't copied into the paste buffer, but the mouse
must be clicked elsewhere to clear the highlight.
* In X, using any of the *PS/2 drivers, neither dragging nor tapping work, and
the mouse clicks randomly during movement.

This is when the kernel is started with "psmouse.proto=ps2".

I know that the synaptics driver for X is available - but this only solves the
problems in X and is very difficult to configure correctly (and apparently, from
rading the above, flaky).

Could we not just revert the problematic ALPS driver back to its state as of
kernel 2.6.10 - when it did exactly the right thing, and was completely
reliable?  Please??

P.S. Is it worth changing the "Kernel Version" field to reflect that this is a
problem on Kernels 2.6.11, 2.6.12, and now 2.6.13?
Comment 27 Vojtech Pavlik 2005-09-06 06:45:38 UTC
Note that "psmouse.proto=ps2" is not an accepted option, the right ones would
be "psmouse.proto=imps" or "psmouse.proto=bare".
Comment 28 Stuart Shelton 2005-09-06 07:43:46 UTC
Yep, sorry - I mis-typed.  I meant "psmouse.proto=exps".

To enhance my feeling that the synaptics driver isn't the correct solution to
this problem, I've just been starting and stopping X(org) to try different
synaptics settings, and it managed to get itself so that, even with the known
good settings, in X I could click but not move the mouse.  Dropping back to a
console, GPM has gone nuts too, with the cursor flying all over the screen at
the slightest touch.

GPM is configured to use /dev/input/mice, whereas the synaptics driver uses
/dev/input/event2.  I guess this means that the synaptics driver had set the
hardware to an imcompatible mode and not correctly reset it?

I should probably have rmmoded the mouse module, but I rebooted instead - which
fixed the problem without changing the xorg configuration.
Comment 29 Vojtech Pavlik 2005-09-06 07:57:08 UTC
The hardware is driven by the kernel driver and doesn't change modes
after loading the driver, even if you try to access it through different

To check what mode the touchpad is in, see /proc/bus/input/devices.
There should be no "ALPS" device if you used psmouse.proto=exps.

Also, if you use that, the kernel sees a regular mouse and leaves
all tap processing to the hardware, whereas when you don't specify it,
the default is to switch the touchpad into absolute mode and do all
the processing (or most of it) in software.
Comment 30 Dmitry Torokhov 2005-09-06 07:59:40 UTC
If you have psmouse compiled as a module then "psmouse.proto=exps" on the 
kernel command line will have no effect. You need to put "options psmouse 
proto=exps" into your /etc/modprobe.conf
Comment 31 Pat Suwalski 2005-09-06 08:48:03 UTC
Stuart has a point. I'm using 2.6.13 with and without special arguments, with
and without the synaptics driver. I cannot, for anything, get tap-drag working.
Using the synaptics driver I actually get frequent hard-freezes. I'm willing to
bet that I have personally spent more time trying to get this to work than it
did to write the code in the first place. I'd give my left nut to have it
working like it used to.
Comment 32 Hinrik 2005-09-08 21:10:33 UTC
Vojtech Pavlik: Try what Dmitry said. I'm using 2.6.13 and dragging works as
long as I use psmouse.proto=exps.

I have a Dell Inspiron 8600c.
Comment 33 Daniel Drake 2005-09-17 09:53:58 UTC
After some confusion on the downstream bug report (http://bugs.gentoo.org/84657)
Stuart has got the proto=exps parameter working and this solves the problems he

I don't fully understand the situation, but the fact it doesn't completely work
out of the box seems like a minor bug. If this is the case and someone gets
around to writing a patch and needs help testing it, please say so and I'll ask
Stuart if he can do that.
Comment 34 Natalie Protasevich 2007-11-17 22:22:23 UTC
Any update on this problem please. Has it been resolved?
Comment 35 Pat Suwalski 2007-11-18 16:54:17 UTC
I haven't had much issue with the touchpad for quite a while now, but I've been using the synaptics driver ever since this bug was created.