Description of problem: I've got synaptics touchpad (Asus F3Sc), but it seems to not working with rawhide's xorg (with default config). Temporary solution is to add to xorg.conf: in ServerLayout section InputDevice "Synaptics" and new section: Section "InputDevice" Identifier "Synaptics" Driver "synaptics" Option "Device" "/dev/input/mice" Option "Protocol" "auto-dev" Option "Emulate3Buttons" "yes" Option "SHMConfig" "on" Option "SendCoreEvents" "true" EndSection But it doesn't resolve all problems - vertical and horizontal scrolling works, moving pointer also, but tapping doesn't work at all. With xorg-x11-server-Xorg-1.4 (from F8) Everything was working ok with this config Version-Release number of selected component (if applicable): [adi@localhost ~]$ rpm -q synaptics xorg-x11-server-Xorg synaptics-0.14.6-6.fc9.i386 xorg-x11-server-Xorg-1.4.99.901-13.20080314.fc9.i386 [adi@localhost ~]$ uname -r 2.6.25-0.167.rc7.git2.fc9.i686 How reproducible: Always Steps to Reproduce: 1. Boot system and try using touchpad Actual results: Touchpad is not working. Expected results: V & H scrolling, tapping and moving pointer should work. Additional info: See attachements
Created attachment 299463 [details] xorg.0.log
Created attachment 299464 [details] kdm.log There are also some warnings and errors in kdm.log
Created attachment 299465 [details] dmesg output
Created attachment 299466 [details] /proc/bus/input/devices
Created attachment 299467 [details] Xorg.0.log ARGH... i've screwed this when trying to install nvidia which have created xorg.conf... Anyway after removing xorg.conf tapping is still not working, rest is OK. Old Xorg.0.log and kdm.log are not actual, here's new ones.
Created attachment 299468 [details] kdm.log
I can confirm on my Dell D610 the cursor was moving dog slow with the default auto-created xorg.conf. After adding the above text and installing ksynaptics it was snappy again. But tapping does still not work. I also would like to see the SHMconfig to be defaulted to On (probably because of security reasons off) or atleast an option to enable it easily for average joe (read: my colleagues :D)
I can confirm it on Asus EEE-PC. Tapping is not working
HP nx7400: - scrolling works out of the box - tapping does not work
Same issue on a Dell Latitude D610. Adding the InputDevice section for the synaptics driver also does not fix the inability to tap for a left mouse click.
Same here, on an IC Power notebook. Tapping does not work.
I can confirm reproduction with my notebook, but I have to qualify it -- it actually works but only until the frist suspend/resume cycle. Does anybody of people who confirmed reproduction of this bug did reproduce it from a fresh boot of the computer or only after suspend/resuming the computer?
It does not work even with a cold boot. Interestingly, I just discovered that tapping works during the graphical boot (I can tap to show/hide details), but once gdm starts up, I can't tap to select the user, or on the Suspend/Restart/Shut Down buttons.
Today i've updated my system and i've got at last my tapping back again ! I didn't test it after suspend/resume, but after booting system it definitely works now for me.
(In reply to comment #14) > Today i've updated my system and i've got at last my tapping back again ! I > didn't test it after suspend/resume, but after booting system it definitely > works now for me. Note, that I can reproduce this only after suspend/resume. On the fresh boot of the computer tapping works. Does anybody else observe this as well?
*** Bug 437609 has been marked as a duplicate of this bug. ***
(In reply to comment #15) [ snip ] > Note, that I can reproduce this only after suspend/resume. On the fresh boot > of the computer tapping works. > > Does anybody else observe this as well? As noted at Bug 437609: Yes, I observe the same thing. I added `Option "TapButton1" "1"', etc., to xorg.conf and tapping is now enabled, but only until suspend/resume. Synclient -l reports "TapButton1 = 1" both before and after suspend/resume.
I have an interesting observation on my system which also had the same problem with tap not working on a newly installed F9 system (as released) I tried the suggestions above editing xorg.conf all to no avail. I was using KDE4, and wanted to test "switchdesk gnome" - when I had logged in to gnome touchpad tap started working. Even more interesting was that when I used "switchdesk kde" then touchpad tap started working in KDE as well when I had logged back in to the KDE session! I did not restart X when this happened. I will add my xorg.conf shortly.
Created attachment 305335 [details] Xorg.0.log at the time touchpad started working In addition to this there were no useful lines in /var/log/messages
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 446313 has been marked as a duplicate of this bug. ***
Created attachment 305361 [details] xorg.conf
Created attachment 305362 [details] Xorg.0.log
Hi, The above attachments are from my brand new installed fedora9 machine. I installed it from the Fedora9 Live cd. The tap feature didn't worked in the Live session , after installation worked in the rhgb. But then got disabled in the gdm and later in gnome. Now what should I do? Thanks
My touchpad does not respond to the touch, contrary to what occoria in Fedora 8 in which it worked perfectly. My laptop is an HP pavilion zt3000.
Seen here: ALPS GlidePoint touchpad on HP Pavilion zx5030EA. Scroll areas and main pad work, but tapping doesn't.
My touchpad doesn't work too (tap-click), however scrolling works... Someone should finally fix it. Fujitsu Siemens Amilo Pro V3515... in fedora 8 it worked fine. The Fedora 9 release is terrible.
Unfortunately this is not a bug. It looks like Adam decided to disable tapping in the synaptics touchpad driver. I would agree with most of the comments here that this change should be reverted back. Just because a few people don't like tapping doesn't mean that it should be turned off for everyone. A better suggestion would be to implement an easy way (maybe via gsynaptics) to turn tapping off for the handful of people who don't like it. If it is for accessibility reasons then this is the wrong way of doing it. The accessibility framework should turn this off when activated. I rebuilt the synaptics pkg and removed Adam's tapping patch if anyone is interested it's here: http://www.ocf.berkeley.edu/~bobk/packages/ After upgrading the pkg restart the synaptics daemon or reboot your machine.
Thanks Bob for packages. For me problem has been solved earlier by adding to xorg.conf Section "ServerLayout" Identifier "single head configuration" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" InputDevice "Synaptics" EndSection Section "InputDevice" Identifier "Synaptics" Driver "synaptics" Option "Device" "/dev/input/mice" Option "Protocol" "auto-dev" Option "Emulate3Buttons" "yes" Option "SHMConfig" "on" Option "SendCoreEvents" "true" Option "RTCornerButton" "2" Option "RTCornerButton" "3" Option "TapButton1" "1" Option "TapButton2" "2" Option "TapButton3" "3" EndSection With this tapping works fine, but unfortunately if those bits will stay disabled, problem will occur again in F10, as there won't be xorg.conf anymore. Then definitely (at least for me) those packages (built for f10) will be very useful :)
(In reply to comment #12) > I can confirm reproduction with my notebook, but I have to qualify it -- it > actually works but only until the frist suspend/resume cycle. Does anybody of > people who confirmed reproduction of this bug did reproduce it from a fresh boot > of the computer or only after suspend/resuming the computer? I'll +1 the only after suspend/resume on my RCubed laptop (OEMed from ASUS). The touchpad works fine, but after suspend/resume, tapping no longer works. Let me know if you need more information from me. I'm pretty sure that if I kill/restart the Xserver, the touchpad works again. I had to add the following to make it work at all in F9: > Option "RTCornerButton" "2" > Option "RBCornerButton" "3" > Option "TapButton1" "1" > Option "TapButton2" "2" > Option "TapButton3" "3"
Thanks for the package Bob. Worked Great.
+1 for reverting that patch, please...
(In reply to comment #15) > > Today i've updated my system and i've got at last my tapping back again ! I > > didn't test it after suspend/resume, but after booting system it definitely > > works now for me. > > Note, that I can reproduce this only after suspend/resume. On the fresh boot of > the computer tapping works. > > Does anybody else observe this as well? Adding xorg.conf options works, but on suspend/resume tapping stops working. ALSO, if you switch VT the touch tapping stops working. I have to restart X to get the tapping to work again.
There are two problems with shmconfig. The first is it's insecure. The shm segment is created world-writable. I'm happier not having arbitrary processes writing into the X server's address space, particularly not processes owned by other than the session owner. We could fix this by integrating with ConsoleKit to shmctl() it to be only accessible by the session user, except... The second problem is that shmconfig is just plain incompatible with fast user switching. The shm segment is created with a fixed segment id. There's no way for two users to use it at once. We could fix the synaptics driver to create a shm segment keyed off the display number, but that would also require fixing gsynaptics and friends to look for the new shm segment id. So, solve both of those things, and shmconfig becomes an option.
Adam, are you saying it will not be fixed?
Just another +1 on reverting the disable tap patch.
(In reply to comment #35) > There are two problems with shmconfig. Take a look at comment 34 -- this is not about shmconfig, but that there doesn't seem to be a way how to make touch -> mouse-click working.
... after suspend/resume, that is.
+1 for revoking the patch. (Acer Aspire 3000 laptop)
+1 for revoking the patch. (Dell Inspiron 640m).
I have the same problem (tapping not working on the touchpad) on my Acer Aspire 4720 laptop. Got around it by adding additional options in the xorg.conf file, as described in comment #30.
(In reply to comment #42) > I have the same problem (tapping not working on the touchpad) on my Acer Aspire > 4720 laptop. Got around it by adding additional options in the xorg.conf file, > as described in comment #30. Comment #31 fixes the typo in comment #30. Does the workaround still work after suspend?
Confirm addition of touchpad section to xorg.conf works on Dell Latitude C400; system fails to resume after suspend; after resuming from hibernate, tap-to-click has been lost.
Changing Summary
(In reply to comment #43) > Comment #31 fixes the typo in comment #30. Does the workaround still work after > suspend? No... it does not work after a suspend.
+1 for enabling tapping. To be true I just couldn't believe, somebody disabled it intentionally. After all, tapping is a normal behaviour of touchpad. Disabling it is just like disabling 'mouse click' because some users don't like it.
Wow, +1 for enabling tapping.
The laptop keyboards are quite cramped and difficult, to say the least. And now, every time you want to click, just bending your finger a bit does not work, you have to move the whole palm downwards to click the button, and hence to adjust the fingers once again on the default row of the keyboard. All this due to this patch. And this seems surprising that still, when this bug which is not a bug but a patch has rendered the machine almost unusable for some of us, the criteria show: Priority: Low, Severity: Medium When it can get a high priority and gets considered as adequately severe? After the bug starts coming out of the machine and gobbling people? And the question is, as it has already been said in the discussion, why should I go into readjusting the configuration and rebuilding things, when I do not want anything special. Touchpads are meant to be tapped and they always were. It must be the other way round: if some people want their touchpad to remain untouched while clicking they must go into the trouble.
Quoting from changelog for the relevant commit: * Sun Mar 09 2008 Adam Jackson <ajax> 0.14.6-4 - synaptics-0.14.6-tap-to-click.patch: Disable tap to click by default in the name of accessibility. If we apply that same kind of logic to keyboard drivers, it would be like disabling the Enter key by default (forcing use of Ctrl-M and such) because a minority of users tend to accidentally hit the Enter key with their little fingers while typing. The absurdity in that example is more obvious, but not fundamentally different from what was done to the Synaptics driver. Enter keys were made to be pressed out-of-box, and likewise Synaptics touchpads were made to be tapped out-of-box. A corner case is a poor justification for diverging so significantly from upstream's intended behavior, especially when it can be addressed without patching upstream's code and without -- as evidenced here and on the forums -- placing a greater burden upon users who fit into the majority use case. And because xorg.conf entries enabling the default tapping behavior are now (for whatever reason) only sufficient until the user invokes suspend/hibernate, I would argue that this patch introduced *two* regressions. Please revert this change.
+1 for reverting that patch. It is the expected behaviour of a touchpad. Those people who dislike tapping, can surely disable it with the proper xorg.conf options.
Installing packages from comment #29 does not fix the problem completely. Although tapping now works after suspend/resume or switching virtual desktops, some parameters are not restored, like the speed of pointer and the width of scrolling area at the right side of touchpad. The "synclient -l" command reports correct values for RightEdge, MinSpeed, MaxSpeed and other parameters, but they don't have effect anymore. Changing them from "synclient" command change values reported by "synclient -l", but have no effect on touchpad's behaviour. The following lines appear in "/var/log/Xorg.0.log" file after returning from suspend or switching back to virtual console running X server: (--) AlpsPS/2 ALPS GlidePoint auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3" (--) AlpsPS/2 ALPS GlidePoint touchpad found (II) <default pointer>: ps2EnableDataReporting: succeeded (--) Synaptics auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3" (WW) Synaptics can't grab event device, errno=16 (--) Synaptics touchpad found The error happens on line 49 of "eventcomm.c" file: synaptics X driver is unable to grab event device using EVIOCGRAB ioctl call. Unfortunately, I have no time now to diagnose why this is happening. Any ideas?
Does the log messages above mean that touchpad on "/dev/input/event3" is detected twice? The first one is autodetected as Alps, the second one taken from "xorg.conf" configuration and detected as synaptics forcefully? Do those two driver instances conflict in some way?
(In reply to comment #52) > Installing packages from comment #29 does not fix the problem completely. > > Although tapping now works after suspend/resume or switching virtual desktops, > some parameters are not restored, like the speed of pointer and the width of > scrolling area at the right side of touchpad. These settings which aren't restored -- are they all customizations from your xorg.conf? > (WW) Synaptics can't grab event device, errno=16 > (--) Synaptics touchpad found > > The error happens on line 49 of "eventcomm.c" file: synaptics X driver is > unable to grab event device using EVIOCGRAB ioctl call. Unfortunately, I have > no time now to diagnose why this is happening. Any ideas? I get the same error. Are you on x86_64 by chance? I'm wondering if the Synaptic driver is getting linked against the wrong libs somewhere.
(In reply to comment #54) > (In reply to comment #52) > > Installing packages from comment #29 does not fix the problem completely. > > > > Although tapping now works after suspend/resume or switching virtual > > desktops, > > some parameters are not restored, like the speed of pointer and the width > > of scrolling area at the right side of touchpad. > > These settings which aren't restored -- are they all customizations from your > xorg.conf? Yes. However, "synclient -l" shows correct values, so I presume, another driver receives events. > > (WW) Synaptics can't grab event device, errno=16 > > (--) Synaptics touchpad found > > > > The error happens on line 49 of "eventcomm.c" file: synaptics X driver is > > unable to grab event device using EVIOCGRAB ioctl call. Unfortunately, I have > > no time now to diagnose why this is happening. Any ideas? > > > I get the same error. Are you on x86_64 by chance? Yes. > I'm wondering if the Synaptic driver is getting linked against the wrong > libs somewhere. No, I don't think so: 1. I was building synaptics driver myself from SRPM. 2. The "ldd" utility shows that "synaptics_drv.so" is linked with correct libraries. 3. The synaptics driver succeeds to grab event device using EVIOCGRAB ioctl first time during initialisation. It fails to grab it later, after resume or virtual console switching.
Actually, I have an impression that two or three driver instances compete for the same touchpad input event device: (1) the synaptics driver instance configured in "xorg.conf": expected parameters, SHM enabled, controllable by "synclient"; (2) somehow autoconfigured synaptics driver instance: identifier taken from "/proc/bus/input/devices", default parameters, SHM disabled, "synclient" talks to the instance (1), to tapping if tapping disabling patch applied; (3) in some cases evdev driver takes over: faster pointer movements, no tapping, to scrolling. Only one driver instance takes over the event device, all others get EBUSY from EVIOCGRAB system call. The order of driver invocation is different on X server initialisation and on resume, so instance (1) wins only the first time, then another ones do. Can anybody with deeper knowledge of Xorg driver internals test my hypothesis?
I can't test this right now but I just noticed that the example xorg.conf on the Synaptics driver page has this line in the 'ServerLayout' section: InputDevice "TouchPad" "AlwaysCore" instead of what I've been using: InputDevice "TouchPad" "CorePointer" This changes the way events are handled so it might be worth a try. (According to the manpage for xorg.conf a value of 'SendCoreEvents' should behave the same as 'AlwaysCore' there.) Another thing to try (but doesn't work for me) is adding 'i8042.reset' or 'i8042.nomux' to the kernel parameters in grub.conf. See: http://gentoo-wiki.com/HARDWARE_Lenovo_3000_N100#Stuck_num-lock_and_disabled_touchpad_when_waking_from_sleep
(In reply to comment #57) > I can't test this right now but I just noticed that the example xorg.conf on the > Synaptics driver page has this line in the 'ServerLayout' section: > > InputDevice "TouchPad" "AlwaysCore" This is already present in my xorg.conf. I still experience a loss of tapping after a suspend/resume.
(In reply to #bug 437702 comment #1) > OK, looks like this one was intentional: > > * Mon Mar 10 2008 Adam Jackson <ajax> 0.14.6-4 > - synaptics-0.14.6-tap-to-click.patch: Disable tap to click by default in > the name of accessibility. > > I'm not sure this is really a good idea, since this is unexpected behaviour, > both by upstream documentation as well as shipped documentation (e.g. the patch > would have had to patch the man pages for example as well). > > Instead it could be something that the gdm login screen could be turning on/off > along with all the other accessibility items. Also if you really want the > default to change then do it in teh created xorg.conf, not hardwired in the > sources where no one will be seraching for this change in behaviour. If F9 ships > out that way you will get lots of duplicates to this bug report. OK, so we have 5 reports out of a total of 56 reports of all synaptics bug reports ever filed. Not the bug raining day, but still a very unpleasant experience with F9 and tapping. Fixing it is easy, here is the patch --- synaptics.spec~ 2008-03-28 20:28:10.000000000 +0100 +++ synaptics.spec 2008-04-10 19:45:27.000000000 +0200 @@ -4,3 +4,3 @@ Version: 0.14.6 -Release: 7%{?dist} +Release: 8%{?dist} Summary: Synaptics Touchpad Driver @@ -14,3 +14,2 @@ Patch1: synaptics-0.14.6-newx.patch -Patch2: synaptics-0.14.6-tap-to-click.patch Patch3: synaptics-0.14.6-poll-delay.patch @@ -55,3 +54,2 @@ %endif -%patch2 -p1 -b .tap %patch3 -p1 -b .polldelay @@ -89,2 +87,5 @@ %changelog +* Thu Apr 10 2008 Axel Thimm <Axel.Thimm> - 0.14.6-8 +- Reenable tap to click. + * Fri Mar 28 2008 Rex Dieter <rdieter> 0.14.6-7 And for the ones too lazy to rebuild I've placed the fixed synaptics package in ATrpms' testing area or you can get it directly from http://atrpms.net/dist/f9/synaptics/ Bought my sanity back.
I have ASUS M6R with similar problems (both with stock F9 synaptics package, and with the one from ATRPMS - comment #59). The configuration of my touchpad is apparently lost both after the suspend/resume _and also_ after switching to the text console and back. I dont use tap-to-click, but I use UpDownScrolling=0 (i.e. the "scroll down" button sends the "button 2" X event). Running synclient -l shows no difference between the just-started X server and the X server after suspend/resume or switch from another VC). Even running "synclient UpDownScrolling=1; synclient UpDownScrolling=0" does not help. In Fedora 8, UpDownScrolling=0 worked without problem (both after suspend/resume, and after switch to another virtual console and back). I have tried to rebuild and install synaptics-0.14.6-2.fc8.src.rpm from F8 updates, but the problem remains. So I think the problem is in the X server itself (maybe libpciaccess?), not in the synaptics driver.
(In reply to comment #9) > HP nx7400: > - scrolling works out of the box > - tapping does not work Slight difference of perspective... Scrolling works *always*, even if supposedly turned off using synclient. (I HATE horizontal scrolling!) Tapping sometimes works after X-server start-up, but never survives suspend/resume. A
Please revoke the tap-to-click disabling patch as this is a significant divergence from expected touchpad behavior and quite annoying after a suspend/resume cycle. Thanks.
Can this buggy patch be removed? Have to kill my X everytime after a suspend cycle to get my touchpad to work again.
(In reply to comment #59) > And for the ones too lazy to rebuild I've placed the fixed synaptics package in > ATrpms' testing area or you can get it directly from > > http://atrpms.net/dist/f9/synaptics/ > > Bought my sanity back. Thanks a lot Alex!!! Dude you rock for helping us all out from this insanity!! And yes, too lazy to rebuild anything ;-) ... your RPMs work great!
I've found the cause of the problem. I have an evidence that the problem described here is caused by two conflicting instances of synaptics driver contending for the same input device. I've slightlty modified the driver source adding more debugging output, so log messages make it obvious. However, studying "Xorg.0.log" carefully even without additional debugging output can reveal this problem. The first instance is the one configured in "xorg.conf". It is initialised the first, it works correctly according to options configured in "xorg.conf". If it has "SHMConfig" option set to on, it can be controlled by "synclient" utility. The second instance is autoconfigured. It's name is taken from "/proc/bus/input/devices", it has default configuration. As default configuration does not have "SHMConfig" option, it can't be controlled with "synclient" utility. At the moment of initialisation, "/dev/input/event3" (or whatever device used by touchpad) is already grabbed by the first instance (EVIOCGRAB ioctl), so the second instance gets no input from the touchpad device and therefore has no effect. However, after virtual console switching (or suspend/resume) the second (autoconfigured) instance is turned on first (DeviceOn function). It grabs input device with EVIOCGRAB ioctl, getting all touchpad input. The first (user- device is already grabbed. As the result, the second (autoconfigured) instance controls all touchpad input. The first (user-configured) instance is still alive, it can be controlled by "synclient" utility, but it gets no input from touchpad device, and hence has no effect. If there is no "InputDevice" section for touchpad device in "xorg.conf", only one (autoconfigured) instance is started, with default parameters. I didn't find the way to configure this instance. Naming touchpad device in "InputDevice" section with exactly the same name as autoconfigured instance doesn't help: two instances with the same names are started. Removing "/usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi" file doesn't prevent autoconfigured instance from being started. It even makes situation worse, because after removing this file (and rebooting or restarting HAL), the autoconfigured instance is controlled by much less capable evdev driver. Enabling tapping in default configuration does not solve the problem, it just eases the pain: there's tapping available after virtual console switching or suspend/resume, but the driver settings are still default, and there's no way to change them with "synclient" utility (it changes parameters of the first instance, which has no effect). Please find why the second synaptics driver instance is started, and either make it not start if there's already synaptics driver instance configured in "xorg.conf", or make this autoconfigured instance configurable.
(In reply to comment #59) > And for the ones too lazy to rebuild I've placed the fixed synaptics package in > ATrpms' testing area or you can get it directly from > > http://atrpms.net/dist/f9/synaptics/ > > Bought my sanity back. Both the machines about which I reported the problem, Acer Aspire 3000 and Dell Inspiron 640M, are now working fine. In fact, in both the cases the touchpads are now working better than ever before. (Maybe I am getting a bit emotional after these 'untapped' days!). Just installed the http://dl.atrpms.net/all/synaptics-0.14.6-8.fc9.i386.rpm provided by Axel Thimm, and it was great. Just added this section to the 'xorg.conf': << Section "InputDevice" Driver "Synaptics" Identifier "TouchPad" Option "SHMConfig" "on" EndSection >> Everything else was done by Thimm's rpm, 'synclient -l' shows it. A season of summer and mangos here in Calcutta, emailing a few for Thimm.
And on both the machines Acer and Dell, it is working after suspend/resume.
The disabled tapping after suspend had been annoying me a lot. And after I upgraded several of my family's machines to F9 this weekend I got very strong complaints on the lack of tapping. In addition to the real bug in comment #65 we really need to find some better way of solving the accessibility problem that doesn't clobber tapping by default, which most people find essential on laptops.
It's really sad that this usability problem has not been fixed. Many users that have accustomed to the old behaviour have their productivity compromised by this simple bug.
It's not just usability problem. It's a clear bug. Disabling the tapping by default wouldn't be a big problem, but not being able to enable it is. Fix this ASAP.
As a workaround Section "ServerFlags" Option "AutoAddDevices" "no" EndSection helped for me with the "two driver instances problem" described in comment #65.
(In reply to comment #71) With the above workaround my custom Synaptics settings are preserved after suspend/resume cycles. However, if all of your X-mediated devices are not specified in xorg.conf this workaround will probably disrupt the functioning of the unspecified devices upon resume.
*** Bug 447310 has been marked as a duplicate of this bug. ***
*** Bug 452367 has been marked as a duplicate of this bug. ***
++ to whoever fixes this w/o 3rd party rpm && w/o xorg.conf modification
This is starting to get stupid. 3 months since the original bug report, several duplicate bugs, and no 'official' solution! What exactly is the holdup? The patch that broke this can be rolled back, and a solution for the people who DON'T want tap-to-click can be found, since they're in a minority.
Re: comment #76 - the problem is not in that patch. As said above (comment #65), the same problem is with each user-defined option which is different from the default - the settings are lost on suspend/resume or console switch (for me, I don't care about tap-to-click, but I would like to have UpDownScrolling=0). Having a different default for tap-to-click (or up-down-scrolling) is a dirty hack, for which third-party packages can be used. What this bug really needs is a system way how to disable the second input driver being initialized at all, so that user defined settings work. That said, I would also welcome the faster solution of this problem.
This is a high priority bug for me. I'm going to hold off upgrading my laptops to F9 until there is an official fix.
Created attachment 310841 [details] xorg.conf On a newly installed F9 on Dell Precision laptop (M4300) I had no tap to click on the touchpad, and very slow mouse acceleration. This xorg.conf gave good mouse response once X was restarted. This was a clean install, and full yum update before testing. This is a workaround and I would expect the touchpad to work without having to mess with xorg.conf especially as in the future xorg.conf may not be present after F10
I was having something of the same problem. Lenovo T61p. 1. use gsynaptic to disable the touchpad altogether (wiggle only, please) 2. hibernate 3. wake up 4. touchpad magically enabled, can't disable The workaround in comment #71 fixed this.
+1 for #59, #71 I, too, consider this a high priority...
The xfree86 DDX kept its list of input devices in reverse order to the DIX. This lead to the devices being initialised in the wrong order when waking up from suspend. Now, since the driver may grab the device file, if the second device wakes up first, it leaves the first (original) device in the open, and the settings change. I just pushed a patch to xserver that should fix this issue. http://cgit.freedesktop.org/xorg/xserver/commit/?id=11ee0ae9390a608a232ff94abcc0cbcf9ed7b70a
Thanks Peter Hutterer, that patch works great!
For a deeper explanation of the Xorg changes that sparked the competing Synaptics driver issue, Peter Hutterer has just made an excellent blog post: http://who-t.blogspot.com/2008/07/input-configuration-in-nutshell.html
Nice, so it is possible to configure the synaptics with HAL fdi. Works just fine. It is just the documentation and communication about this big change in how things are configured that are sucking so deeply.
Some information about the fdi configuration files is here http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi
Created attachment 312620 [details] FDI configuration for synaptics driver OK, so I think I have workaround working with the original Fedora-supplied drivers and edev. 1) Drop this file into /etc/hal/fdi/policy/10-synaptics.fdi 2) restart haldaemon 3) follow instructions in comment 84 to make your Xorg use edev instead of direct synaptics 4) restart Xorg Does it work?
(note for us -- we have to lie to edev driver claiming that input.x11_options.TapButton1 is string, whereas it should be int)
The solution from comment #87 works for me. Thanks, Matej!
Yes, that fixes tapping issue but i am not able to scroll up and down with my pad right now. I have used workaround proposed in comment 87.
(In reply to comment #90) > Yes, that fixes tapping issue but i am not able to scroll up and down with my > pad right now. I have used workaround proposed in comment 87. you need to add the respective input.x11_options.XYZ to the fdi file. for scrolling, this would be VertEdgeScroll. other options are described in the synaptics man page.
Confirmed on FS Amilo Pro V3505, tapping added in xorg.conf is gone after hibernate/thaw cycle. Restarting Xorg brings it back.
(In reply to comment #92) > Confirmed on FS Amilo Pro V3505, tapping added in xorg.conf is gone after > hibernate/thaw cycle. Restarting Xorg brings it back. An explanation why is in Comment #82, with a solution in #87. If you do not think that this is the case, please supply your log file and xorg.conf.
(In reply to comment #93) > (In reply to comment #92) > > Confirmed on FS Amilo Pro V3505, tapping added in xorg.conf is gone after > > hibernate/thaw cycle. Restarting Xorg brings it back. > > An explanation why is in Comment #82, with a solution in #87. The solution from #87 does work. Tapping survives both VT switching and suspend, thanks a lot.
synaptics-0.14.6-9.fc9 has been submitted as an update for Fedora 9. /updates/synaptics-0.14.6-9.fc9
xorg-x11-drv-synaptics-0.15.0-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-0.15.0-2.fc9
xorg-x11-drv-synaptics-0.15.0-2.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-synaptics'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7264
A tiny bit more information for people trying to get /etc/hal/fdi/policy/10-synaptics.fdi to work, but finding that it has no effect: This file has two sections, which define options for two different types of touchpad hardware: <match key="info.product" contains="Synaptics TouchPad"> ... </match> and: <match key="info.product" contains="AlpsPS/2 ALPS"> ... </match> The example file attached to this bug report only includes the required options in the first of these sections. I had to place the options (copy/paste them) inside the second section for them to apply with the hardware present in my laptop. After doing that, and deleting pretty much everything from xorg.conf (except 'Driver "nvidia"') it all works:-)
xorg-x11-drv-synaptics-0.15.0-3.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-0.15.0-3.fc9
*** Bug 459265 has been marked as a duplicate of this bug. ***
Though probably not completely tested, I have downloaded and installed the xorg-x11-drv-synaptics update and it works wonderfully on my Gateway laptop with Fedora 9. However, like many, I have discovered that while typing on the keyboard sometimes the cursor moves when I don't want it to. To remedy the situation, I purchased a mouse. Now that I have installed the update, how to I disable my touchpad??? Thank you in advance.
xorg-x11-drv-synaptics-0.15.0-3.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-synaptics'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7968
Hi, I tried the command given in comment 102 but it doesn't work. No updates are available for that package. I followed the instructions in commment 87 but IMO it gives rise to more problems than it solves: 1) My 4-way scroller button (below the touchpad in between the two click buttons) no longer works - clicking "down" now works as right click 2) The clicking is VERY sensitive 3) I can't scroll by gliding in the right of the touchpad 4) Clicking with two fingers should be equal to middle click, but that doesn't work. Similarly, clicking with three fingers should be equal to right click I don't know which of these are X.org bugs and which are evdev bugs. Is there any way to resolve the 4 issues I mentioned above? I hope this problem doesn't occur in Fedora 10!
One more thing which doesn't work is - I can't double tap and then move my finger to simulate a drag action. That's one of the big "conveniences" I miss too.
(In reply to comment #103) > 1) My 4-way scroller button (below the touchpad in between the two click > buttons) no longer works - clicking "down" now works as right click This indicates that option UpDownScrolling is off. Switching it on should fix this. Likewise, LeftRightScrolling may need to be switched on. > 2) The clicking is VERY sensitive can you define sensitive? this is a physical button, right? does it emit too many scroll events when you click? If so, you can control this behaviour with the UpDownScrollRepeat and ScrollButtonRepeat options. > 3) I can't scroll by gliding in the right of the touchpad This usually indicates that either vert scrolling is turned off, or that the right edge is misconfigured (too high). To scroll, the coordinates the driver receives from the touchpad must be greater than the RightEdge setting. > 4) Clicking with two fingers should be equal to middle click, but that doesn't > work. Similarly, clicking with three fingers should be equal to right click The following settings enable the behaviour you want ClickFinger2 = 2 ClickFinger3 = 3 All above options can be added to the fdi file in the same manner as the other options. Can you please try it and tell us if it fixes it for you? > One more thing which doesn't work is - I can't double tap and then move my > finger to simulate a drag action. That's one of the big "conveniences" I miss > too. Normal tap works fine though? If not, try increasing MaxTapMove. I'm running 0.15.1-fc10 and double-tap drag works fine, so it might be some local setting.
Hi Peter, I removed the synaptics package using rpm -e --nodeps. I then installed x11-drv-synaptics package 0.15.1 from here -- http://koji.fedoraproject.org/koji/buildinfo?buildID=62375 However, that still doesn't solve any problem. I am attaching my 10-synaptics.fdi for your reference.
Created attachment 316754 [details] My synaptics.fdi Adding all those options still don't solve the problems I mentioned.
(In reply to comment #15) > (In reply to comment #14) > > Today i've updated my system and i've got at last my tapping back again ! I > > didn't test it after suspend/resume, but after booting system it definitely > > works now for me. > > Note, that I can reproduce this only after suspend/resume. On the fresh boot of > the computer tapping works. > > Does anybody else observe this as well? Recently I have installed Fedora 9 on two Dell laptops: XPS M1330 and Latitude D620 - fresh fedora 9 install with all updates and tapping/scrolling does not work.
(In reply to comment #107) > Adding all those options still don't solve the problems I mentioned. Did you restart HAL and X (in that order) after adding the fdi file? Please run "hal-device" and then look through the output if the options you added show up at the touchpad device. I noticed that the fdi only includes the parameters for SynPS/2 touchpads - maybe your model is an ALPS? (In reply to comment #108) > Recently I have installed Fedora 9 on two Dell laptops: XPS M1330 and Latitude > D620 - fresh fedora 9 install with all updates and tapping/scrolling does not > work. 0.15.1 has bad defaults for MaxTapMove - seemingly breaking tapping on touchpads that aren't appletouch/bcm974 models. Try re-setting MaxTapMove to 220, either in your xorg.conf or in the fdi file. Regarding scrolling: I found that some devices report wrong axis ranges. e.g. my touchpad claims range 0-1500, but the effective maximum is 1200. Since the autodetection sets up the edge in the non-reachable range, scrolling breaks. Could this be the issue with your touchpad? Try adjusting RightEdge towards the center.
(In reply to comment #109) [ snip ] > (In reply to comment #108) > > Recently I have installed Fedora 9 on two Dell laptops: XPS M1330 and Latitude > > D620 - fresh fedora 9 install with all updates and tapping/scrolling does not > > work. > > 0.15.1 has bad defaults for MaxTapMove - seemingly breaking tapping on > touchpads that aren't appletouch/bcm974 models. Try re-setting MaxTapMove to > 220, either in your xorg.conf or in the fdi file. Thanks for the tip! Tapping was really random with xorg-x11-drv-synaptics-0.15.1-1.fc10.i386--tap was seen maybe 10% of the time. Setting MaxTapMove to 220 has made it 100% so far--seems like something around there should be the default :)
(In reply to comment #109) > > Did you restart HAL and X (in that order) after adding the fdi file? > Please run "hal-device" and then look through the output if the options you > added show up at the touchpad device. I noticed that the fdi only includes the > parameters for SynPS/2 touchpads - maybe your model is an ALPS? > > Yes, I restarted the computer to be sure. I have modified my fdi file to include parameters for ALPS touchpads, but hal-device shows that my touchpad is Synaptics. Either I am doing something very wrong, or something is broken in my system. Can you please attach your synaptics.fdi file so that I could compare? I am attaching my synaptics.fdi and hal-device output. The latter does not show the additional options which I have mentioned. In xorg.conf ServerLayout section, I have Option "AutoAddDevices" "off" so there should be no conflict with HAL/evdev. Please tell me where am I going wrong.
Created attachment 316847 [details] Modified synaptics.fdi This one still doesn't work.
Created attachment 316848 [details] Output of hal-device. Relevant portion starts from line 125.
xorg-x11-server-1.5.0-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #112) > Created an attachment (id=316847) [details] > Modified synaptics.fdi > > This one still doesn't work. <match key="info.product" contains="Synaptics Touchpad"> TouchPad, not Touchpad. That should fix it.
I can't believe I made such a foolish mistake. However, still the problems are not solved! I restarted my computer, so there is no chance of HAL not updating. All the fdi options are now shown in hal-device output, but it seems that the effect hasn't taken place. The 4 way scroller button still doesn't work, neither does double-click-and-drag. Can you please attach your synaptics.fdi file for my reference? I think I am making a mistake in the syntax somewhere.
Rohan: This seems to be a separate issue from the problem described in this bugreport then. Please open a new bug against xorg-x11-drv-synaptics and attach your xorg.log, synaptics.fdi and the comment 103. Also, please list the version of synaptics you are currently running. You can assign the bug to me. btw. I use the stock fdi file, but I don't have a scroller button either.
Rohan: I copied/pasted all the <merge>...</merge> lines inside this section too: <match key="info.product" contains="AlpsPS/2 ALPS"> Since my touchpad seems to not be named "Synaptics TouchPad".
(In reply to comment #117) > Rohan: > This seems to be a separate issue from the problem described in this bugreport > then. > > Please open a new bug against xorg-x11-drv-synaptics and attach your xorg.log, > synaptics.fdi and the comment 103. Also, please list the version of synaptics > you are currently running. You can assign the bug to me. Hi, Here is the new bug I have created - https://bugzilla.redhat.com/show_bug.cgi?id=462771 Thanks for patiently helping me so for.
xorg-x11-drv-synaptics-0.15.0-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
please https://fedoraproject.org/wiki/Input_device_configuration