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.
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".
David, could you please test 2.6.12-rc1, update us on the situation? Thanks.
>>David, could you please test 2.6.12-rc1, update us on the situation?<< Sure. Tuesday. I'll remove psmouse.proto=exps
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.
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.
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.
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 :(
Can you please retest 2.6.12-rc5?
>>------- 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
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.
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
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
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
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.
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.
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
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.
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 2.6.11.12 still requires psmouse.proto=exps.
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.
I forgot to mention that the crash seems to happen exclusively in what should be the virtual vertical scrollbar area of the touchpad.
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 dtor_core@ameritech.net Thanks! Dmitry
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.
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.
Created attachment 5320 [details] Working version of drivers/input/mouse/alps.c
The new alps.c file works for me under 2.6.12.2 on a Sony Vaio TR2/B and correctly enables the double-click to drag behaviour. Thanks Johan.
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?
Note that "psmouse.proto=ps2" is not an accepted option, the right ones would be "psmouse.proto=imps" or "psmouse.proto=bare".
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.
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.
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
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.
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.
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.
Any update on this problem please. Has it been resolved? Thanks.
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.