Description of problem: I performed an upgrade from F10 to Rawhide the other day on my Lenovo 3000 N100 laptop and the touchpad stop having tap as click as well as the very useful right side scroll zone. Version-Release number of selected component (if applicable): xorg-x11-drv-synaptics-1.0.0-4.fc11.x86_64 How reproducible: 100% Steps to Reproduce: 1. start up X 2. play with touchpad Actual results: as above Expected results: no regression from F10 Additional info: x86_64, da_DK.UTF-8
Created attachment 332696 [details] Xorg.0.log
Please see if the quirk mentioned at http://www.alphatek.info/2009/01/29/gsynaptics-touchpad-on-fedora-10-hal/ works for you.
(In reply to comment #2) > Please see if the quirk mentioned at > http://www.alphatek.info/2009/01/29/gsynaptics-touchpad-on-fedora-10-hal/ works > for you. That focuses on making the configuration program GSynaptics run, I have no interest in that. In F10 this was configured correctly automatically, in Rawhide that is not the case.
Upstream has change defaults with the 1.0 release. Tap is disabled unless you have a device that does not have a physical button (like the apple ones). If you want tap-to-click, you need to enable it explicitly. Copy /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi into /etc/hal/fdi/policy and edit it appropriately (the file has the instructions how to).
Can we please change the default back, I know we generally follow upstream but requiring users to read man pages and edit xml configuration files by hand to reverse this regression is more than a bit balmy. I don't know if this is related to these changes, but my touchpad also seems much less reactive, and it occasionally moves the cursor is a more undesirable fashion which feels jerky and often leads to it being placed wrong. In F10 it was very smooth and the side scroll always worked beautifully, now even when activated it often doesn't seem to react to the scroll motion.
(In reply to comment #5) > Can we please change the default back, I know we generally follow upstream but > requiring users to read man pages and edit xml configuration files by hand to > reverse this regression is more than a bit balmy. No, for every person that loves tap there's one that hates it. Those who prefer tap tend to be the more experienced users and are more likely to be able to configure it themselves. Mind you, ideally this should have a configuration tool anyway, the xml configuration is the solution until we have one. > I don't know if this is related to these changes, but my touchpad also seems > much less reactive, and it occasionally moves the cursor is a more undesirable > fashion which feels jerky and often leads to it being placed wrong. In F10 it > was very smooth and the side scroll always worked beautifully, now even when > activated it often doesn't seem to react to the scroll motion. Could be, the acceleration code has changed significantly, both in the server and in the synaptics driver. Amongst other things, acceleration factors in the driver are selected based on the device's axis ranges now. For most touchpads, these defaults should still be the same as they used to be (without configuration). If you previously had custom configuration (and you removed it from the xorg.conf) it may feel different now. You'd need to play around with the configuration options (xorg.conf still works if you have one) and check. The xinput tool works for that as well, synaptics publishes a number of properties that can be modified at runtime.
(In reply to comment #6) > No, for every person that loves tap there's one that hates it. > Those who prefer tap tend to be the more experienced users and are more likely > to be able to configure it themselves. > > Mind you, ideally this should have a configuration tool anyway, the xml > configuration is the solution until we have one. The ideal would be no regressions or at least not introducing them without a way to get the functionality back that doesn't involve man pages, xml file editing and rebooting. I also think your generalization is rather unfounded, I find that everyone who buys a laptop gets used to this. The people who want it gone are the experienced users for whom it sometimes interferes. > Could be, the acceleration code has changed significantly, both in the server > and in the synaptics driver. Amongst other things, acceleration factors in the > driver are selected based on the device's axis ranges now. For most touchpads, > these defaults should still be the same as they used to be (without > configuration). If you previously had custom configuration (and you removed it > from the xorg.conf) it may feel different now. > You'd need to play around with the configuration options (xorg.conf still works > if you have one) and check. The xinput tool works for that as well, synaptics > publishes a number of properties that can be modified at runtime. As stated, the defaults worked beautifully for me, I had no special configuration of any kind.
I've added the tapping behaviour to what will become the release notes: https://fedoraproject.org/wiki/Features/SynapticsUpdate#Release_Notes As for the motion behaviour: do you still have the F10 installation around? if you do a synclient -l on F10 and F11, are there any differences in the settings that could affect this?
(In reply to comment #8) > I've added the tapping behaviour to what will become the release notes: > https://fedoraproject.org/wiki/Features/SynapticsUpdate#Release_Notes > > > As for the motion behaviour: do you still have the F10 installation around? if > you do a synclient -l on F10 and F11, are there any differences in the settings > that could affect this? Unfortunately no, I sacrificed my one and only machine to Rawhide testing. Would booting a live USB F10 work for getting this information?
yeah, sure. The hardware should stay the same after all :)
synclient -l for F11 is empty I am though seeing lots of these in dmesg which looks related, not to mention scary. I will follow up with the F10 output psmouse.c: Failed to reset mouse on isa0060/serio1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: issuing reconnect request
(In reply to comment #11) > synclient -l for F11 is empty 1.0.99.2 had a bug on 64 bit machines, this is fixed with 1.0.99.3, please upgrade and try again.
Output for F11 1.0.99.3: [david@dawkins SPECS]$ synclient -l Float properties not available. Float properties not available. Parameter settings: LeftEdge = 1632 RightEdge = 0 TopEdge = 5312 BottomEdge = 0 FingerLow = 24 FingerHigh = 0 FingerPress = 29 MaxTapTime = 180 MaxTapMove = 221 MaxDoubleTapTime = 0 SingleTapTimeout = 180 ClickTime = 180 FastTaps = 0 EmulateMidButtonTime = 75 EmulateTwoFingerMinZ = 280 EmulateTwoFingerMinW = missing VertScrollDelta = 100 HorizScrollDelta = 0 VertEdgeScroll = 0 HorizEdgeScroll = 0 CornerCoasting = 0 VertTwoFingerScroll = 1 HorizTwoFingerScroll = 0 MinSpeed = missing MaxSpeed = missing AccelFactor = missing TrackstickSpeed = missing EdgeMotionMinZ = 29 EdgeMotionMaxZ = 0 EdgeMotionMinSpeed = 1 EdgeMotionMaxSpeed = 0 EdgeMotionUseAlways = 0 UpDownScrolling = 1 LeftRightScrolling = 1 UpDownScrollRepeat = 1 LeftRightScrollRepeat = 1 ScrollButtonRepeat = 100 TouchpadOff = 0 GuestMouseOff = 0 LockedDrags = 0 LockedDragTimeout = 5000 RTCornerButton = 0 RBCornerButton = 0 LTCornerButton = 0 LBCornerButton = 0 TapButton1 = 0 TapButton2 = 0 TapButton3 = 0 ClickFinger1 = 1 ClickFinger2 = 1 ClickFinger3 = 1 CircularScrolling = 0 CircScrollDelta = missing CircScrollTrigger = 0 CircularPad = 0 PalmDetect = 0 PalmMinWidth = 10 PalmMinZ = 0 CoastingSpeed = missing PressureMotionMinZ = 29 PressureMotionMaxZ = 0 PressureMotionMinFactor = missing PressureMotionMaxFactor = missing GrabEventDevice = 1
For F10 (x86_64 via the livecd) synclient tells me: [liveuser@localhost ~]$ synclient -l Can't access shared memory area. SHMConfig disabled?
doh. most of the interesting ones are missing. please update to an xorg-x11-server-1.6.0-2 or higher so the float properties are there. For the F-10 system you need to add Option SHMConfig "on" to the xorg.conf (in the synaptics section) and restart X. synclient still needs the shm area in F10.
I have the same problem - I had taps disabled anyway, but the non functional scroll area really hurts. I have an "AlpsPS/2 ALPS GlidePoint". Is there any known workarround to make this work again until its finally fixed?
by the way I was testing on rawhide.
Clemens: does synclient VertEdgeScroll=1 work for you? (You should have two-finger scrolling enabled by default on your touchpad, can you please check that too)
No, both "synclient VertEdgeScroll=1" nor two-finger scrolling by default don't work unfourtunatly :-/
please attach the output of synclient -l, the Xorg.log and the output of evtest /path/to/device then. You can find a copy of evtest on http://people.freedesktop.org/~whot/evtest.c It could be that the RightEdge setting is wrong. I've seen some touchpads that report a right edge setting that was above what the device could physically provide. This means the scaling, etc. is out of order.
Created attachment 335288 [details] synclient -l output
Created attachment 335289 [details] evtest output
Created attachment 335290 [details] Xorg log of the Alps GlidePoint
ok, so the device doesn't report multi-touch and VertEdgeScroll should always be on by default. Can you please verify this? The edge settings looks alright, but it may be too narrow. Please adjust RightEdge to something lower, try 900 or 850 maybe. If this doesn't work either, we need to get the information from the hw. To do so, you need to enable Option SHMConfig in the xorg.conf/the fdi files and then run synclient -m 20 while moving the fingers to all edges on the touchpad. this prints out the data reported from the touchpad itself.
Adjusting RightEdge to 880 did the trick, thanks for the hint :)
The new default setup is a pretty significant change that is going to affect a LOT of users. I think it's important to give it a lot of publicity. I downloaded and installed F11 Beta (DVD media) and didn't notice anything in the release notes regarding this. http://fedoraproject.org/wiki/Fedora_11_Beta_release_notes My first impression was that this was a regression, and when I was about to submit a bug report I came across this bug. The info at https://fedoraproject.org/wiki/Features/SynapticsUpdate#Release_Notes is decent but it NEEDS to be in the actual F11 Release Notes. FWIW, I'm running IceWM and added the following lines to ~/.icewm/startup: synclient VertEdgeScroll=1 synclient TapButton1=1
I'm facing this problem as well (Thinkpad R61, not an Alps touchpad from what I can tell). It was working fine up until one of the recent rawhide daily updates - something in the last 2 or 3 days. Clicking was disabled (as expected from the comments above) but vertical scrolling on the side of the pad worked as expected. Two-fingered scrolling does not work or is not enabled. Using: synclient VertEdgeScroll=1 makes the scroll area work again as expected.
(In reply to comment #27) > Clicking was disabled [...] but vertical scrolling on the side of the pad > worked as expected. Two-fingered scrolling does not work or is not enabled. > > Using: > > synclient VertEdgeScroll=1 > > makes the scroll area work again as expected. I'm confused - vertical scrolling worked or didn't work before you did that? was it enabled? (synclient -l | grep VertEdgeScroll) was two-finger scrolling enabled? If not, does the Xorg.log state that the device has two-finger capabilities (search for "left right middle double triple", the last two claim support for two/three finger tapping, see http://who-t.blogspot.com/2009/04/synaptics-11-and-what-your-touchpad-can.html)
Clemens: please have a look at Bug 494766, Comment #9. Can you please add the maximum RightEdge value that works for you there too. Thanks
(In reply to comment #28) > (In reply to comment #27) > > Clicking was disabled [...] but vertical scrolling on the side of the pad > > worked as expected. Two-fingered scrolling does not work or is not enabled. > > > > Using: > > > > synclient VertEdgeScroll=1 > > > > makes the scroll area work again as expected. > > I'm confused - vertical scrolling worked or didn't work before you did that? > was it enabled? (synclient -l | grep VertEdgeScroll) When I first installed the F11beta, vertical scrolling worked as expected. Some time since then, an update disabled this. Using: synclient VertEdgeScroll=1 makes vertical scrolling on the edge of the touchpad work again with the latest rawhide (Apr 13 updates). This was not needed when I first installed the F11 beta. > was two-finger scrolling enabled? If not, does the Xorg.log state that the > device has two-finger capabilities (search for "left right middle double > triple", the last two claim support for two/three finger tapping, see > http://who-t.blogspot.com/2009/04/synaptics-11-and-what-your-touchpad-can.html) Two finger scrolling is not and was not enabled. As far as I know my touchpad does not support it - the Xorg.0.log on lists "left right middle". No "double" or "triple" listed.
As a follow up to comment 30, the Gnome mouse configuration application allows me to enable edge scrolling on the touchpad. Was this configuration support for touchpads added post-F11 beta?
(In reply to comment #31) > As a follow up to comment 30, the Gnome mouse configuration application allows > me to enable edge scrolling on the touchpad. Was this configuration support > for touchpads added post-F11 beta? yes, just last week. I wonder if that's what disabled scrolling for you, the value 0 for scroll method means "disabled" and I think this would be the default value if you didn't set it before. Is it enabled properly in a plain X session?
(In reply to comment #32) > (In reply to comment #31) > yes, just last week. I wonder if that's what disabled scrolling for you, the > value 0 for scroll method means "disabled" and I think this would be the > default value if you didn't set it before. > > Is it enabled properly in a plain X session? Scrolling does seem to be properly enabled pre-Gnome. In GDM, using the scroll section of the touchpad acts like scrolling is supported here. So it looks to me like the updated configuration app is the cause.
(In reply to comment #33) > Scrolling does seem to be properly enabled pre-Gnome. In GDM, using the scroll > section of the touchpad acts like scrolling is supported here. So it looks to > me like the updated configuration app is the cause. This is addressed in http://koji.fedoraproject.org/koji/buildinfo?buildID=102094, the edge scrolling is now enabled by default in gnome-settings-daemon. I think we can close this bug now?
edge scrolling works now and the strange acceleration problem has also resolved itself. Thank you.
Appears to be working for me now, too.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Closing as per comments #35 and #36