GNOME Bugzilla – Bug 600128
Disabling tap-to-click does not prevent all tap clicks
Last modified: 2010-01-09 10:49:37 UTC
I recently installed Ubuntu Karmic 9.10 (with Gnome 2.28.1) on my Toshiba Portege, and started seeing this. I have tap-to-click disabled, but a double-tap in the bottom-right corner of the touchpad still emulates a right-click and brings up a context menu. This is annoying because I do a lot of scrolling along the right edge of the touchpad, and as I am quickly scrolling the menu keeps popping up. I have no idea if this is a bug in the low-level touchpad code, or if there is an extra config option that should be exposed in the UI, or something else. I can provide lsmod or lspci or any other output if it would help.
This is really driving me crazy. It would be great if someone could at least confirm it, and/or make sure it is assigned to the correct product/component.
change component since gpointing-device-settings does not have tap-to-click option.
I'm not aware of any special settings for bottom-right touchad corners... Peter, does this sound familiar?
Kevin means the second value of "Synaptics Tap Action" property. The following patch will fix this issue, but I have another patch that also fix bug 589944. I will attach it soon. diff --git a/plugins/mouse/gsd-mouse-manager.c b/plugins/mouse/gsd-mouse-manager.c index ea2f5ff..8f0dc1c 100644 --- a/plugins/mouse/gsd-mouse-manager.c +++ b/plugins/mouse/gsd-mouse-manager.c @@ -576,6 +576,7 @@ set_tap_to_click (gboolean state, gboolean left_handed) data[4] = (state) ? ((left_handed) ? 3 : 1) : 0; data[5] = (state) ? ((left_handed) ? 1 : 3) : 0; data[6] = (state) ? 2 : 0; + data[2] = (state) ? 3 : 0; XChangeDeviceProperty (GDK_DISPLAY (), device, prop, XA_INTEGER, 8, PropModeReplace, data, nitems); }
I attached the patch in bug 589944.
synaptics has special actions to be performed if any of the corners are being tapped. why this is set on your box I don't know, the defaults are off and g-s-d doesn't have code to set it. Do you have an xorg.conf that sets the RBCornerButton?
First, to clarify, a single tap in the bottom-right corner behaves like a right-click. Originally I thought it was a double-tap, but it is not. Second, I have no "InputDevice" sections in my xorg.conf at all. I assume some X and/or gnome magic is autodetecting it all. I checked my BIOS and it does not have any settings to control this level of detail. This is a Portege R500-S5008X, by the way. Third, when I run synclient -l I see: RTCornerButton = 0 RBCornerButton = 3 LTCornerButton = 0 LBCornerButton = 0 I can manually run "synclient RBCornerButton=0", and it works for that session. Adding an "InputDevice" section to xorg.conf with this setting had no effect. Fourth, the patch above looks promising. I wonder how long it will be before it finds its way into Ubuntu. Meanwhile, I created /etc/profile.d/synaptics.sh containing the synclient commands to configure my touchpad, and will find out with my next reboot whether that is a sufficient workaround for now.
(In reply to comment #7) > Third, when I run synclient -l I see: > RTCornerButton = 0 > RBCornerButton = 3 this is the problem - this should be 0 as well. we need to find out why and when this is set to 3 (right click) instead of 0. Please try changing various settings in the gnome mouse applet to see if any of them affect this setting. It might be some stray data that gets set inadvertently.
(In reply to comment #8) > (In reply to comment #7) > > Third, when I run synclient -l I see: > > RTCornerButton = 0 > > RBCornerButton = 3 > > this is the problem - this should be 0 as well. we need to find out why and > when this is set to 3 (right click) instead of 0. Please try changing various > settings in the gnome mouse applet to see if any of them affect this setting. > It might be some stray data that gets set inadvertently. I found Ubuntu does it. Please see 103_enable_cornertapping.patch in http://launchpadlibrarian.net/28608561/xserver-xorg-input-synaptics_1.1.2-1_1.1.2-1ubuntu1.diff.gz
not a gnome bug then, this is a distribution-specific setting. Merging the hunk shown in comment 4 would destroy a setting not actually controlled by g-s-d, I can't recommend that for the obvious reasons. Please take this up with your distribution's package maintainer.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > Third, when I run synclient -l I see: > > > RTCornerButton = 0 > > > RBCornerButton = 3 > > > > this is the problem - this should be 0 as well. we need to find out why and > > when this is set to 3 (right click) instead of 0. Please try changing various > > settings in the gnome mouse applet to see if any of them affect this setting. I manually set them to zero using synclient. Then, enabling tap-to-click leaves these two values at zero. Disabling it obviously does as well. Nothing I clicked on the Touchpad tab seems to affect them at all. > > It might be some stray data that gets set inadvertently. > > I found Ubuntu does it. > Please see 103_enable_cornertapping.patch in > http://launchpadlibrarian.net/28608561/xserver-xorg-input-synaptics_1.1.2-1_1.1.2-1ubuntu1.diff.gz --- From patch 103 --- +- pars->tap_action[RT_TAP] = xf86SetIntOption(opts, "RTCornerButton", 0); +- pars->tap_action[RB_TAP] = xf86SetIntOption(opts, "RBCornerButton", 0); ++ pars->tap_action[RT_TAP] = xf86SetIntOption(opts, "RTCornerButton", 2); ++ pars->tap_action[RB_TAP] = xf86SetIntOption(opts, "RBCornerButton", 3); --- Patch 103 sets both RT and RB corner buttons, yet RT was zero as I reported above. So I am a bit skeptical that this patch is the only cause of the problem I reported. But I will report it upstream just in case. Fortunately, the synclient/profile.d workaround I mentioned has solved my immediate problem, so at least I am no longer in pain.