Created attachment 358128 [details] Basic patch adding gconf keys for tap customization Description of problem: gnome-settings-daemon resets touchpad TapButton bindings to a hardcoded "RLM mapping" on X session start, suspend/resume, and switching to/from a text console. This makes it impossible to persistently rebind touchpad taps when using gnome. Summary: Fedora 11 added a new tab to gnome-mouse properties that lets users control some touchpad properties. These properties are saved in gconf under /desktop/gnome/peripherals/touchpad. gnome-settings-daemon reconfigures the touchpad based on these settings. Settings that aren't handled by this new system can be customized by several legacy methods: 1) Custom xorg.conf 2) HAL .fdi-file 3) gsynaptics 4) synclient The only "tap" setting stored in gconf is "Enable mouse clicks with touchpad" (/desktop/gnome/peripherals/touchpad/tap_to_click), which turns tap recognition on and off; if tap_to_click is on, gnome-settings-daemon configures the tap bindings to a hardcoded "RLM mapping": 1 finger tap = left click, 2 finger tap = right click, and 3 finger tap = middle click. The RLM mapping stomps on any user customizations made by the legacy methods listed above. The RLM mapping behavior was added by a distribution patch, in the set_tap_to_click function about halfway down: http://cvs.fedora.redhat.com/viewvc/F-11/gnome-settings-daemon/gnome-settings-daemon-2.26.0-support-touchpads.patch?view=markup Because gnome-settings-daemon reconfigures the touchpad several times during a typical laptop x session (involving suspend/resume) it's impossible to persistently customize taps.. the best that's possible is manually running something like this after each reconfiguration: synclient TapButton2=2 synclient TapButton3=3 Version-Release number of selected component (if applicable): 2.26+ How reproducible: Reconfigure touchpad taps in xorg.conf (placing a 'Option "TapButton2" "2"' line in the synaptics InputDevice section) or a HAL .fdi file (placing the attached fdi file in /etc/hal/fdi/policy). Sign in to GNOME. Note that a two-finger tap generates a right click. If an .fdi file was used, run `lshal` and note that "input.x11_options.TapButton2 = '2'" is still listed. ..or.. Sign in to GNOME. Run the following commands: synclient TapButton2=2 synclient TapButton3=3 Note that two-finger tap gives middle click and three-finger tap gives right click. Switch to a text console and back, or suspend/resume. Note that two-finger tap now gives right click and three-finger tap now gives middle click. Actual results: A useful gui onfiguration tool makes it impossible to persistently change touchpad tap bindings. Expected results: Either the gnome-mouse-properties / gconf / gnome-settings-daemon system should provide a way of customizing touchpad taps, or it should not override the various legacy ways of customizing them. Previous Fedora releases used different defaults; a two-fingered tap gave a middle click and a three-fingered-tap gave a right click. A good number of users would likely want to switch back to the old bindings, default or not. Additional info: This may seem like a relatively small usability issue, but given the importance of middle clicking in X it comes up a lot. My muscle memory's set up to double finger tap to middle click, so having a popup menu appear rather than paste after every time I closed my laptop's lid was very annoying.. annoying enough that I went through the trouble of tracking down the cause and writing up this report. I've attached a basic gnome-control-center patch that adds new gconf keys under /desktop/gnome/peripherals/touchpad: tap_button_1, tap_button_2, and tap_button_3, if present, set the defaults for 1, 2, and 3 finger clicks. If a tap_button key isn't present, the current RLM mapping is used. They're expected to be integer keys between 1 and 3, and there's no UI for setting them, so this patch puts responsibility on the user.. but at least it make it possible to customize tap bindings in a way that doesn't get wiped out. Please add some version of this patch's functionality to gnome-settings-daemon before the next release. Having hidden gconf keys that let tap bindings be reset certainly won't do any harm, and they'll be in place for whenever this functionality gets added to gnome-mouse-properties.
Created attachment 358129 [details] HAL fdi file for repro instructions
Rebuilt gnome-settings-daemon-2.26.1-10 with the original patch; builds and tests OK. Bastien: can this patch be added to the next release of gnome-settings-daemon? It's small, I've tested it out over the last month, and it reverses a functional regression that gnome-settings-daemon-2.26.0-support-touchpads.patch introduced (that is, wiping out user customized tap bindings.) The problem wouldn't have come up if .support-touchpads didn't change the driver's default tap bindings... but that patch does other things too, so it can't just be backed out. This way seems simpler to me. I'll attach my changes to gnome-settings-daemon.spec in case that's helpful. I'm sure you've got plenty on your plate, but rebuilding gnome-settings-daemon is fairly time consuming for me, so I'd really appreciate it if this could be fixed sooner rather than later. If there's anything else I can do to help it along, feel free to contact me.
Created attachment 362610 [details] Patch to gnome-settings-daemon.spec enabling the custom touchpad taps patch
In an upstream bug, I proposed a slightly more conservative approach... Just swap current TapButtons for left handed setup and leave them as they are otherwise. I don't really think there is the need to clutter up this thing with yet another way to set tapping stuff, there is already xorg.conf and synclient. I don't think having it in a hidden gconf setting helps in any way if it's not going to be exposed in the gui. It would be enough to honor those settings. https://bugzilla.gnome.org/show_bug.cgi?id=589944
Yes, that would be enough, but it's not straightforward getting gnome-settings-daemon to respect xorg or synclient settings. The problem is the redhat patch that sets a default RLM mapping stomps on those settings! Gconf prefs were straightforward to put in, and are ready to be hooked up to a gui interface once someone puts that together.. and it's a way for people that care enough to look this stuff up in buzilla to customize it now; otherwise there's no way to make the settings stick. Even easier would be removing the RLM mapping from redhat's patches! That'd leave the synaptics default intact, wherever it's set. That said, the developers who could put any patches in have been too busy to chime in on any approach, so the discussion's moot.
gnome-settings-daemon 2.28 has this problem upstream, so this bug's only relevant to the redhat gnome-settings-daemon 2.26 package.
Confirmed this bug is still present in Fedora 12. gnome-settings-daemon tramples all over settings set at system and xorg level. Furthermore, even if I run while in Gnome (for example, in a gnome session startup script): synclient TapButton2=1 synclient TapButton2=2 synclient TapButton3=3 on resume from sleep gnome-settings-daemon re-applies its broken settings, swapping buttons two and three. I am still looking for a workaround. Anyone know how to run a script on wake from sleep?
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This problem originally came from upstream, and the fix didn't get into gnome 2.30. This is the upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=598820 I'm happy to adapt the upstream patches to work against F13's packages, but only if someone with commit access is willing to review and commit those patches... the last batch I worked up never went anywhere, and the work's too time consuming to be worthwhile it's not be used. This is a functional regression that dates back to F11, though, so it's high time it's fixed! Any committer who's willing and able to send the fix through to F13 packages: please comment here, and I'll update the patches attached to this bug.
I agree that the patches should be added. I make changes with gpointing-device-settings and they immediately work and I can see the changes being written into my ~/.gconf. However they do not persist over X restarts. kernel: 2.6.33.6-147.fc13.x86_64 #1 SMP