|Summary:||ALPS Touchpad Tap-to-Click Broken|
|Product:||Drivers||Reporter:||David Cary Hart (davidhart)|
|Component:||Input Devices||Assignee:||Dmitry Torokhov (dmitry.torokhov)|
|Severity:||normal||CC:||kernel, luke, pat, protasnb, vojtech|
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? Thanks.
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 Thanks
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 Johan, 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. Thanks! Dmitry
Comment 14 Pat Suwalski 2005-06-13 19:28:10 UTC
Dmitry, 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 speak. 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. Dmitry
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 220.127.116.11 still requires psmouse.proto=exps.
Comment 19 Pat Suwalski 2005-06-14 21:53:45 UTC
Dmitry: 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 occurs. 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" EndSection 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
Pat, 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 firstname.lastname@example.org Thanks! Dmitry
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 18.104.22.168 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 interfaces. 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 reported. 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? Thanks.
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.