Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
After upgrading xorg-server from 1.4.2 to 1.5.0 and switching from x11-drivers/synaptics to x11-drivers/xf86-input-synaptics, tap-to-click no longer works. Normal movement and vertical scrolling still work just fine. I looked through the synaptics man page, but I didn't see any option to enable/disable *just* the tap-to-click functionality.
My current config is: Section "InputDevice" Driver "synaptics" Identifier "TouchPad" Option "SendCoreEvents" Option "Protocol" "auto-dev" Option "SHMConfig" "on" Option "PalmDetect" "on" EndSection I added the PalmDetect option after the tap-to-click already wasn't working.
Tap-to-click seems to be working inconsistently for me. If I sit at my laptop and tap over and over again in slightly different ways it works once in a while; not at all with the pressure/time I'm used to using though. Section "InputDevice" Identifier "Touchpad" Driver "synaptics" Option "Device" "/dev/input/by-path/platform-i8042-serio-4-event-mouse" Option "CorePointer" Option "SHMConfig" "true" Option "MinSpeed" "0.1" Option "MaxSpeed" "0.5" Option "AccelFactor" "0.0025" EndSection Adding the "FastTaps" option seems to help a bit.
Seems like this is disabled by default. Adding Option "TapButton1" "1" in the section solved it for me.
That worked for me, too. However, that option isn't in the man page.
(In reply to comment #4) > That worked for me, too. However, that option isn't in the man page. It seems to be, at least for 0.15.1: Option "TapButton1" "integer" Which mouse button is reported on a non-corner one-finger tap. Set to 0 to disable. It also looks like the default setting for MaxTapMove has been changed to 25 from the previous 220 (in 0.14.6). I only recovered the previous "feel" of the touchpad after changing it back to the old value. Personally, I find such changes in the default behavior of the driver quite annoying and would find it really helpful if the ebuild displayed a hint how to get the previous behavior using elog.
I used to have a nicely working InputDevice section for my synaptics touchpad in xorg.conf. With >=xorg-server-1.5.0 and >=xf86-input-synaptics-0.15.0 that section is completely ignored. I guess that synaptics' configuration should be migrated to a hal fdi file too...
I am experiencing the same problem. Although I have copied the upstream fdi file from =x11-drivers/xf86-input-synaptics-0.15.2-r1 to the /etc/hal/fdi/policy folder (as it was not installed, see bug 237620), the settings do not seem to be merged. Here is the output of # lshal | grep -iC5 synaptics udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX3_port_logicaldev_input' info.capabilities = {'input', 'input.touchpad'} (string list) info.category = 'input' (string) info.parent = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX3_port' (string) info.product = 'SynPS/2 Synaptics TouchPad' (string) info.subsystem = 'input' (string) info.udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX3_port_logicaldev_input' (string) input.device = '/dev/input/event4' (string) input.originating_device = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX3_port' (string) input.product = 'SynPS/2 Synaptics TouchPad' (string) input.x11_driver = 'synaptics' (string) linux.device_file = '/dev/input/event4' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'input' (string) linux.sysfs_path = '/sys/class/input/input4/event4' (string)
I just upgraded to xorg-server-1.5 (with hal-USE-Flag). So synaptics didn't compile anymore. Thus I switched to x11-input-synaptics. Due to ignoring the xorg-section I copied the rules from /usr/share/hal/fdi/policy/10osvendor/11-x11-synaptics.fdi to /etc/hal/fdi/policy and changed all the values to my personals ones of the xorg.conf. Scrolling is working. Moving is working. But Tapping doesn't. I changed the value of TapButton1 to 1 and insert the ClickTime with values between 100 and 1000. No chance to get it working. Workaround: Install synaptics-0.14.6-r3 or r2 and apply the synaptics-fix-xf86_ansic.h.patch Behaviour is now correct.
Same problem here, after force-upgrading to xf86-input-synaptics (the synaptics driver no longer builds with xorg-7.1), the following things behaved differently: - slower movement - no tap-to-click function However, the behaviour is only broken in xf86-input-synaptics-0.99.1. Version xf86-input-synaptics-0.15.2-r2 works for me perfectly, in fact after removing all options from xorg.conf, and leaving only "driver" and "device" options, the touchpad works perfectly with default settings. If i understand gentoo xorg versioning scheme correctly, the x.99.whatever builds are generally development snapshots, and from my experimenting, they have a tradition in breaking just about everything if you're silly enough to install them. In the 0.99.1 NEWS file, it shows that it's a snapshot of version somewhere around 0.15.0, which is the version that some people have been reporting as non-functioning. The other driver is actually newer, fixed, and this is merely a problem of the .99. development build not being package.masked, and only keyword masked.
Strange. 0.99.1 is working fine for me, while 0.15.x versions were broken. Still, I had to manually migrate my settings from xorg.conf to /etc/hal/fdi/policy/11-x11-synaptics.fdi
Created an attachment (id=174457) [details] synclient output diff Here is the diff between the synclient output from 0.15.2-r2 (Xorg config) and 0.99.2 (FDI config). I found out that after upgrading to 0.99.2 the scroll areas stopped working and used this diff to restore the previous behaviour. Perhaps it's going to be useful to other people upgrading from 0.15* to 0.99*.
(In reply to comment #11) Hi, could you please pass me your FDI file? I'm having no hori/vert scrolls and no taping working since 0.99.X Rolando.
Created an attachment (id=176253) [details] FDI config file requested in comment #11.
(In reply to comment #13) Thanks man!!! Works like a charm again. Anybody know if this is going to be included as part of hal and/or synaptics packages?
With version 0.99.x, tap-to-click doesn't work on my laptop. I've installed 11-x11-synaptics.fdi as described here, but got zero effect. Is there a way to see - why synaptics driver doesn't see that .fdi file?
(In reply to comment #15) > Is there a way to see - why synaptics driver doesn't see that .fdi file? You can check the Xorg log in /var/log for any error messages, and you can run `synclient -l` to see the current settings of the synaptics driver (this requires SHMConfig "on" in xorg.conf or in the .fdi file).
(In reply to comment #15) > 11-x11-synaptics.fdi as described here, but got zero effect. I had to install it as /etc/hal/fdi/policy/11-x11-synaptics.fdi instead of as /usr/share/hal/fdi/policy/10osvendor/11-x11-synaptics.fdi or /usr/portage/x11-drivers/synaptics/files/11-x11-synaptics.fdi for it to work
How about ppl who don't use HAL? Those FDI files are not much use. Tap-to-click and scrolling doesn't work for me either using 0.99.3-r1.
sorry, you can forget about this one /usr/portage/x11-drivers/synaptics/files/11-x11-synaptics.fdi It's just the local copy of the file for the package. I guess you could also try copying that one to /etc/hal/fdi/policy/11-x11-synaptics.fdi instead of to /usr/share/hal/fdi/policy/10osvendor/11-x11-synaptics.fdi. Sorry, for bothering again but is this gonna be taken into account in future releases?
(In reply to comment #18) > How about ppl who don't use HAL? Those FDI files are not much use. Tap-to-click > and scrolling doesn't work for me either using 0.99.3-r1. I guess you can always translate the FDI sample config file which I attached back to xorg.conf. The names of the options and their values are exactly the same, it's only the format that's different.
(In reply to comment #17) > (In reply to comment #15) > > 11-x11-synaptics.fdi as described here, but got zero effect. > > I had to install it as /etc/hal/fdi/policy/11-x11-synaptics.fdi instead of as > /usr/share/hal/fdi/policy/10osvendor/11-x11-synaptics.fdi or > /usr/portage/x11-drivers/synaptics/files/11-x11-synaptics.fdi for it to work It works in the /usr/share directory if you restart hald. That said, it might be better to put it in /etc so it doesn't get wiped out every time xf86-input-synaptics is updated. Thanks for the config, it's working well.
(In reply to comment #20) > I guess you can always translate the FDI sample config file which I attached > back to xorg.conf. Great, works perfectly! Thank you!
Did anyone try to contact upstream through FreeDesktop's bugzilla or mailing lists? Also, did anyone try comparing with other distros' fdi files? Thanks
(In reply to comment #23) > Did anyone try to contact upstream through FreeDesktop's bugzilla or mailing > lists? > > Also, did anyone try comparing with other distros' fdi files? > > Thanks > I have seen that ubuntu is applying some patches for enabling scrolling and tap by default (preferred behavior from my point of view): http://patches.ubuntu.com/x/xfree86-driver-synaptics/extracted/104_always_enable_tapping.patch http://patches.ubuntu.com/x/xfree86-driver-synaptics/extracted/106_always_enable_vert_edge_scroll.patch Also, it applies and interesting patch for reducing cursor speed (I am suffering it just now, cursor is too fast and hard to control): http://patches.ubuntu.com/x/xfree86-driver-synaptics/extracted/107_reduce_cursor_speed.patch
Created an attachment (id=183420) [details] fedora-10-synaptics.fdi Fedora and mandriva are using this fdi file, but it doesn't work either, there are also some mandriva bugs related to tap issues: https://qa.mandriva.com/show_bug.cgi?id=47149 https://qa.mandriva.com/show_bug.cgi?id=46250
I have sent the bug reports to upstream for fixing tapping, scrolling and speed problems. The patches are from ubuntu and I have tested them on gentoo on a local overlay and fixes all these issues: https://bugs.freedesktop.org/show_bug.cgi?id=20369 https://bugs.freedesktop.org/show_bug.cgi?id=20370 https://bugs.freedesktop.org/show_bug.cgi?id=20371 About remaining ubuntu patches: http://patches.ubuntu.com/x/xfree86-driver-synaptics/extracted/01-synaptics-dont-grab-if-not-on-current-VT.patch -> this is also used in debian and tries to solve https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/68370 but, as I don't suffer that problem and synaptics works ok also in new display, I think that applying it is no needed http://patches.ubuntu.com/x/xfree86-driver-synaptics/extracted/103_enable_cornertapping.patch -> I don't know what fixes this, changelog says that also fixes https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/320632 , but tapping works fine for me not applying it, then, I dubt it's needed and I haven't tested it http://patches.ubuntu.com/x/xfree86-driver-synaptics/extracted/105_correct_multifinger_click.patch -> IT should fix https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/320585/comments/2 but, as double tapping works fine for me without this, I haven't tested it and I dubt it's needed http://patches.ubuntu.com/x/xfree86-driver-synaptics/extracted/108_syndaemon_xinput_props.patch -> This seems to solve https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/321355 , but, as I have never used syndaemon and this seems to make major changes, I haven't applied it. Anyway, if you think it's ok for sending to upstream, I can of course send it if you don't have enough time Best regards :-)
Created an attachment (id=183443) [details] Working FDI file for ALPS I had to add two lines that were not in my xorg.conf file to get my ALPS working properly after upgrading to this driver. They are the last two lines in the config - one to make tapping work, the other to make the upper right tap to be the middle mouse button.
*** Bug 260584 has been marked as a duplicate of this bug. ***
For the record, my problems with my AlpsPS/2 ALPS GlidePoint (Inspiron 600m) are completely solved by the .fdi file from Will B. (comment #27)
(In reply to comment #29) > For the record, my problems with my AlpsPS/2 ALPS GlidePoint (Inspiron 600m) > are completely solved by the .fdi file from Will B. (comment #27) > In my case, it causes my touchpad to simply stop moving :-(
I am using this in my case: <?xml version="1.0" encoding="ISO-8859-1"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.touchpad"> <merge key="input.x11_driver" type="string">synaptics</merge> <merge key="input.x11_options.SHMConfig" type="string">true</merge> <merge key="input.x11_options.TapButton1" type="string">1</merge> <merge key="input.x11_options.VertEdgeScroll" type="string">1</merge> <merge key="input.x11_options.AccelerationScheme" type="string">none</merge> </match> </device> </deviceinfo> I think that most users can drop "input.x11_options.SHMConfig" (I added it for checking synclient -l output for other problem) "input.x11_options.TapButton1" allows me to reenable tap to click "input.x11_options.VertEdgeScroll" allows me to do vertical scrolling "input.x11_options.AccelerationScheme" is needed in my case for disabling xorg acceleration, if I don't disable it, I get mouse moving too fast
*** Bug 263830 has been marked as a duplicate of this bug. ***
the response in Comment #27 works-for-me * tap-to-click works * vertical scrolling works thank you much!
Nothing in this thread has worked for me. I have tried using various .fdi's and I get nothing. lshal lists my options specified in .fdi, but they are just having no effect. x11-drivers/xf86-input-synaptics-1.0.0 sys-apps/hal-0.5.11-r8 x11-base/xorg-server-1.5.3-r6
First of all, I don't know what you mean by tap to click no longer works... The text is ambiguous, because a tap should not click... I have a feeling that you might be saying that tapping no longer clicks... if that's the case, how can I switch to this distro?, We need to have tapping off by default because it's a security vulnerability because it's too easy to click on bad stuff/delete important data. I don't even know why there is tapping, but alas somebody thought it's cool, so long as they have to change configuarion to enable it.
(In reply to comment #35) > First of all, I don't know what you mean by tap to click no longer works... > The text is ambiguous, because a tap should not click... I have a feeling that > you might be saying that tapping no longer clicks... if that's the case, how > can I switch to this distro?, Huh? Tap-to-click is the name of the feature which saves you moving your fingers to the mouse buttons, and is extremely helpful. I don't understand how this is ambiguous? I don't understand what you are trying to make a distinction between. You're a non-gentoo user? You don't want to change distro just because of some broken mouse configuration. > I don't even know why there is tapping, but alas somebody thought it's cool, so long as they have to change configuarion to enable it. Because it is faster, and less effort when used correctly. It is an optional part of the synaptics driver and is usually configurable. The configuration of it is broken so that it is not possible in some setups to turn it on. Hence it is a bug.
(In reply to comment #35) > I don't even know why there is tapping, but alas somebody thought it's cool, so > long as they have to change configuarion to enable it. Tap-to-click, as in tap the touchpad once to click once, tap the touchpad 3 times to doubleclick, etc. etc. And that is pretty much the default with all synaptics touch pads, across all operating systems. As is the "mouse-wheel" on the sides of touchpad. And this bug is (was) a regression compared to the previous versions of the synaptics driver, because those things suddenly stopped working, after working since the very start.
While you guys are it, can you check my bug 263830 ( http://bugs.gentoo.org/show_bug.cgi?id=263830 ) which has been marked duplicate for this bug. It contains the synaptics driver with ubuntu (jaunty) patches, and hopefully should work for your touchpad. (I honestly don't have the time to look deep into what changes cause it and make a specific patch for this problem.)
(In reply to comment #35) > First of all, I don't know what you mean by tap to click no longer works... > The text is ambiguous, because a tap should not click... I have a feeling that > you might be saying that tapping no longer clicks... if that's the case, how > can I switch to this distro?, This is not distro specific but a regression in the ability to configure driver to do it. > We need to have tapping off by default because it's a security vulnerability > because it's too easy to click on bad stuff/delete important data. By that definition I shouldn't let you near a computer because you could accidentally put in a boot disk that formats the hardrive. This anyone who does anything in information security would agree is a problem but there is not much that can be done, maybe we should just ban all input? > I don't even know why there is tapping, but alas somebody thought it's cool, so > long as they have to change configuarion to enable it. It is the fact that the configuration change doesn't enable it that is the problem.
my specific problem is three-fold This bug appears to note that tap to click is off by default, which I can't possibly see as a bug, (it is a change in behaviour) and that there is no easy way to change it. Yes, We need an easy way to change it 1. Tap to click should be off by default, Linux/ X/ can take the lead here by setting it to something sane. 2. I can't turn off tap to click, even with poking with fdi files 3. There isn't a gui (that's available without extra work to change the behavior.) qsynaptics works but only if other settings are manually edited. >>>>>>> >By that definition I shouldn't let you near a computer because you could accidentally put in a boot disk that formats the hardrive. This anyone who does anything in information security would agree is a problem but there is not much that can be done, maybe we should just ban all input? Signal to Noise Ratio. The problem is that tap-to click is like leaving the boot disk which is set to format all drives with no confirmation in the drive so that another user merely restarting the computer reformats the drive, and then admonishing him. If I created that boot disk and left that boot disk in the production computer I would be at fault. just as I think that the person who made tap to click on by default on trackpads is at fault for making computers difficult to use. Now, If I put the boot disk in the computer and restarted it, and it came from a trusted location, and was labeled system repair, and it did all this bad stuff how is that anywhere near the same as just telling a computer to restart? If it were labeled "Formats disk immediately", that gives me some chance to see what's going on and stop before continuing. ... Ok.. here's a better example, tap to click is like walking around in a room with trip wires, with floppy disks in our hands, and having the floppy disk drives positioned in such a way that when we fall we insert the disk and hit the restart button. In conclusion, we should make the level of input required to do something questionable well above the noise of cats walking across the keyboard, or in the case of tap-to-click merely trying to move the cursor to the other side of the screen. It was noted that tap to click may save time in some cases... I suspect that it doesn't save much time, but hey, I'm all for options.
Well I understand it is a nuisance if you cannot turn off tap-to-click. But you're funny :). This discussion is getting a bit nutty here. And we can all understand your point without all the fancy analogies. IMHO, tap-to-click should be on by default, but there should be an easy gui to disable it temporarily/permanently and also tweak other features. Correct me if I am wrong, but most users do use tap-to-click. And common sense would say that the defaults should cater to the majority (with special features for the elite minority).
> Correct me if > I am wrong, but most users do use tap-to-click. And common sense would say that > the defaults should cater to the majority (with special features for the elite > minority). I would tend to agree that most users do use tap-to-click some of the time, I would say that most people use the buttons some of the time. I think nearly everybody knows how to use the buttons, with only slightly less knowing about tap to click. I think well over 30 percent of the people have significant problems with tap to click (with my older parents and a few kids running about it's 100 percent) -- Think of all the people who just get external mice because of this confounded contraption! I think only 10 percent of people really like tap-to-click enough to know and want it to be default. I pulled all but the 100 percent statistic out of my educated rear.
tap-to-click is still available but not enabled by default. Since I have no intention of changing upstream's defaults (because it's just bikeshedding), the proper resolution of this bug is to properly document the driver's behavior (if at all...) Since I've been planning to overhaul our X documentation, I guess this should be part of the Master Plan (tm). Thanks
Sounds good. Please document things well :). Btw, I happened to try out patches from recent synaptics driver from ubuntu karmic (http://changelogs.ubuntu.com/changelogs/pool/main/x/xserver-xorg-input-synaptics/xserver-xorg-input-synaptics_1.1.2-1ubuntu1/changelog) and they even added corner tapping by default (right top for middle-click and right bottom for right-click - which is new for me, and I like it as my touchpad buttons are a little stiff for me).
this is a situation where upstream's defaults are wrong. it's not bikeshedding; the hardware doesn't work like it was designed to with the current setup, which is why there are so many people CC'd and voting here. arguments that people are surprised and confused by tap-to-click are, frankly, bullshit. it's on by default in every other operating system and distro I've ever used. calling it a security vulnerability is one of the funnier things I've read today.
Who said anything about security? Like the ctrl-alt-backspace behavior change in xorg-server 1.6, upstream has decided to change some of the defaults. There was intense trolling/flaming about that change and other small changes. I do not want to go through that again. Like everything else that sucks in the packages we ship, it'll get properly documented. Thanks
Wouldn't it be possible to add some kind of "vanilla" use flag to the ebuild, which will use default (upstream) fdi file, and without it will use the SANE working fdi file? Maybe with a warning during installation that you're not using defaults? Or at least a copy of the sane fdi file in files/ directory, with an obvious explanation info message in the ebuild, because 99.99999% users will want to replace the upstream default anyway? I think it's crazy if you have to google for a hour and replace system files to get a driver working _properly_. Saving the users some time, at least by not having to look for the fixed fdi file are definitely bonus points.
good idea :).
For those that have problems, my preffered (and easiest) way is through xorg.conf. Generate a current xorg.conf with X -configure, and then in InputDevice section of the mouse you MUST change the Driver field to "synaptics" (or add a new section just for synaptics doesn't matter most time), else the override will be done to the standard mouse driver (useless). That's why xorg.conf is not working for most people. Then you can add the: Option "TabButton1" "1" in the same section and you are done.
I still haven't been able to get tap-to-click to work. I'm using Will B.'s 11-x11-synaptics.fdi file, and I can confirm it is having an effect with: $ hal-device | grep x11_optio input.x11_options.EdgeMotionMaxSpeed = '200' (string) input.x11_options.CircScrollDelta = '0.1' (string) input.x11_options.CircScrollTrigger = '3' (string) input.x11_options.VertEdgeScroll = 'true' (string) input.x11_options.TapButton1 = '1' (string) input.x11_options.RTCornerButton = '2' (string) input.x11_options.SHMConfig = 'true' (string) input.x11_options.Emulate3Buttons = 'true' (string) input.x11_options.LeftEdge = '130' (string) input.x11_options.RightEdge = '840' (string) input.x11_options.TopEdge = '130' (string) input.x11_options.BottomEdge = '640' (string) input.x11_options.FingerLow = '7' (string) input.x11_options.FingerHigh = '8' (string) input.x11_options.MaxTapTime = '180' (string) input.x11_options.MinTapTime = '110' (string) input.x11_options.ClickTime = '0' (string) input.x11_options.VertScrollDelta = '20' (string) input.x11_options.HorizScrollDelta = '20' (string) input.x11_options.MinSpeed = '0.40' (string) input.x11_options.MaxSpeed = '0.65' (string) input.x11_options.AccelFactor = '0.030' (string) input.x11_options.EdgeMotionMinSpeed = '200' (string) input.x11_options.EmulateMidButtonTime = '75' (string) input.x11_options.UpDownScrolling = '1' (string) input.x11_options.CircularScrolling = '1' (string) I'm using x11-drivers/xf86-input-synaptics-1.1.3, hal-0.5.13-r2, xorg-server-1.6.3-901-r2. Any ideas or other things I can test? Are any of the configuration options shown above wrong?
