Touchpad: Action for middle and right click is reversed since jaunty

Same bug here.

According to the changelog, 105_correct_multifinger_click.patch was supposed to have been dropped in version 1.1.2-1ubuntu2; however the patch is still present.

The patch is still there (in debian/patches) but it's not used as it's commented out in the debian/patches/series files.

Maybe it's because you're touching the corners of your touchpad?

No, the behaviour I am seeing is definitely 2-finger tap = right click and 3-finger tap = middle click.

I've had a look at the package, and it looks like it is probably being caused by 104_always_enable_tapping.patch:

- /* Enable tap if we don't have a phys left button */
- tapButton1 = priv->has_left ? 0 : 1;
- tapButton2 = priv->has_left ? 0 : 3;
- tapButton3 = priv->has_left ? 0 : 2;
+ /* Enable tap */
+ tapButton1 = 1;
+ tapButton2 = 2;
+ tapButton3 = 3;

Just a "me too" as I'd wish not to change habits. ;)

It would still be nice to see this bug solved before the rc.
Can anyone who knows how compile without 104_always_enable_tapping.patch and see whether that solves this bug?

This bug only affect karmic, multi-fingers clicking works as expected on jaunty (at least for me).

+1 by the way, the RC is not too far away. All the more that it seems to be easily fixable…

By the way, there is a topic on the forums about it: http://ubuntuforums.org/showthread.php?t=1251372

I am also experiencing this issue on the eee pc 900. On 8.04-9.04, two-finger click triggered a middle click. In the 9.10 beta it triggers a right click. 3 fingers trigger a middle click, but I find this very difficult and uncomfortable to do, which means I cannot comfortably open duplicate tabs in firefox or select/paste text using middle click. Middle click should be triggered by a two finger tap, since right click has a physical button on all pc touchpads I've seen, while a multifinger tap is the only way to middle click. The easiest and most intuitive configuration is:
 <left physical button> or <single finger tap> = left click
<two finger tap> or <simultaneous left and right physical buttons> = middle click
<right physicial button> or <three finger tap> = right click

This does seem like a simple fix.

In /src/synaptics.c static void set_default_parameters(LocalDevicePtr local)
the following should be changed:

- /* Enable tap if we don't have a phys left button */
- tapButton1 = priv->has_left ? 0 : 1;
- tapButton2 = priv->has_left ? 0 : 3;
- tapButton3 = priv->has_left ? 0 : 2;
+ /* Enable tap if we don't have a phys left button */
+ tapButton1 = priv->has_left ? 0 : 1;
+ tapButton2 = priv->has_left ? 0 : 2;
+ tapButton3 = priv->has_left ? 0 : 3;

Sorry, after talking with the xorg developers I realized that the above change is not really correct. Instead, there should be a change in the gnome-settings-daemon. gnome-settings-daemon-2.28.0
in file /plugins/mouse/gsd-mouse-manager.c set_tap_to_click (gboolean state)

- /* Set RLM mapping for 1/2/3 fingers*/
- data[4] = (state) ? 1 : 0;
- data[5] = (state) ? 3 : 0;
- data[6] = (state) ? 2 : 0;
+ /* Set RLM mapping for 1/2/3 fingers*/
+ data[4] = (state) ? 1 : 0;
+ data[5] = (state) ? 2 : 0;
+ data[6] = (state) ? 3 : 0;

This will swap the values to what they were in previous releases

I can confirm that the change in dmj726's post #12 has solved the problem here.
Eeepc on Karmic with Elantech touchpad.

Temporary fix:

on each boot run:

xinput set-int-prop "ETPS/2 Elantech Touchpad" "Synaptics Tap Action" 8 0 3 0 0 1 2 3

This is for my eeepc 901. For synaptics touchpads it should be something like:

xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Synaptics Tap Action" 8 0 3 0 0 1 2 3

Works for me anyway. Not that sure about the second suggestion.

I associate scrolling with the middle mouse button (as on a normal mouse they are one thing) so two finger scrolling -> two finger click.

Just upgraded to 9.10 and discovered this bug. Since the source code fix posted a couple of weeks ago looks pretty simple, might we see it pushed out in an update soonish?

Reading the forums & blogs, it looks like the move from hal to udev made this behavior non-configurable (in addition to being wrong). That's a shame.

Is there any way that I can be contacted via this source when this correction has been made?

Thankx!
________________________________________
From: <email address hidden> [<email address hidden>] On Behalf Of hp_user [<email address hidden>]
Sent: Saturday, October 31, 2009 6:54 PM
To: Daniel Tatum (924187871)
Subject: [Bug 432814] Re: Action for middle and right click is reversed since jaunty

Just upgraded to 9.10 and discovered this bug. Since the source code fix
posted a couple of weeks ago looks pretty simple, might we see it pushed
out in an update soonish?

Reading the forums & blogs, it looks like the move from hal to udev made
this behavior non-configurable (in addition to being wrong). That's a
shame.

--
Action for middle and right click is reversed since jaunty
https://bugs.launchpad.net/bugs/432814
You received this bug notification because you are a direct subscriber
of the bug.

Status in “xserver-xorg-input-synaptics” package in Ubuntu: Confirmed

Bug description:
Binary package hint: xserver-xorg-input-synaptics

LSB version = karmic
Package version = 1.1.2-1ubuntu5

Expected behaviour:
Tap the touchpad with 2 fingers simultaneously to generate middle-click event. Tap with 3 fingers for right-click event.

Observed behaviour:
A 2-finger tap generates a right-click event and a 3-finger tap generates a middle-click event.

Looking at the changelog for 1.1.2-1ubuntu1 I see this:
"105_correct_multifinger_click.patch: Swap the right/middle clicks generated by multi-finger tapping."
This patch is then reverted in 1.1.2-1ubuntu2:
"105_correct_multifinger_click.patch: Drop patch as it breaks the expected behavior for multitouch clicking (LP: #320585)."

However, I still experience the behaviour introduced in -1ubuntu1. Hopefully I can help get the expected behaviour back in time for karmic's release.

ProblemType: Bug
Architecture: i386
CheckboxSubmission: d90fdc639d79341a7dfe13ba74210bc8
CheckboxSystem: 018dd987ae1f42580fa9d31146e40261
Date: Sat Sep 19 00:29:42 2009
DistroRelease: Ubuntu 9.10
MachineType: Packard Bell BV EasyNote MB85
NonfreeKernelModules: nvidia
Package: xserver-xorg-input-synaptics 1.1.2-1ubuntu5
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic root=UUID=25b243bb-087e-436e-81ca-bee20d03157b ro quiet splash
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.34-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.6.0~git20090817.7c422387-0ubuntu5
 libdrm2 2.4.13-1ubuntu1
 xserver-xorg-video-intel 2:2.8.1-1ubuntu1
 xserver-xorg-video-ati 1:6.12.99+git20090825.fc74e119-0ubuntu1
SourcePackage: xserver-xorg-input-synaptics
Uname: Linux 2.6.31-10-generic i686
dmi.bios.date: 04/07/2008
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: PB2A4A04
dmi.board.name: PB2A
dmi.board.vendor: Packard Bell BV
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: Packard Bell BV
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrPB2A4A04:bd04/07/2008:svnPackardBellBV:pnEasyNoteMB85:pvrPC03Q00101:rvnPackardBellBV:rnPB2A:rvrNotApplicable:cvnPackardBellBV:ct1:cvrN/A:
dmi.product.nam...

If you need a workaround until the fix (?), this one has been pointed out on the forums:

  synclient TapButton2=2; synclient TapButton3=3;

However, those commands have to be run at each session's start (you can add them in Preferences → "Startup Applications").

@Daniel Tatum
Use the "suscribe" link at the top right of this page to get all updates about this bug in your mail.

@Photon-- Thank you. Thank you so much, that does solve the problem, but the bug is still there.

@Photon,

Presumably, one can also add this to the /etc/xprofile (which may need creating and making executable) to create a global change in the behavior.

@Photon,

The Startup Applications synclient fix doesn't appear to survive on resume from sleep (at least on a Macbook Pro).

Argh.

Also, it appears that you can put both fixes in one command:

synclient TapButton2=2 TapButton3=3

You're not alone - same problem on Asus eeePC 1000
________________________________________
From: <email address hidden> [<email address hidden>] On Behalf Of hp_user [<email address hidden>]
Sent: Wednesday, November 25, 2009 8:29 PM
To: Daniel Tatum (924187871)
Subject: [Bug 432814] Re: Action for middle and right click is reversed since jaunty

@Photon,

The Startup Applications synclient fix doesn't appear to survive on
resume from sleep (at least on a Macbook Pro).

Argh.

Also, it appears that you can put both fixes in one command:

synclient TapButton2=2 TapButton3=3

--
Action for middle and right click is reversed since jaunty
https://bugs.launchpad.net/bugs/432814
You received this bug notification because you are a direct subscriber
of the bug.

Status in “xserver-xorg-input-synaptics” package in Ubuntu: Confirmed

Bug description:
Binary package hint: xserver-xorg-input-synaptics

LSB version = karmic
Package version = 1.1.2-1ubuntu5

Expected behaviour:
Tap the touchpad with 2 fingers simultaneously to generate middle-click event. Tap with 3 fingers for right-click event.

Observed behaviour:
A 2-finger tap generates a right-click event and a 3-finger tap generates a middle-click event.

Looking at the changelog for 1.1.2-1ubuntu1 I see this:
"105_correct_multifinger_click.patch: Swap the right/middle clicks generated by multi-finger tapping."
This patch is then reverted in 1.1.2-1ubuntu2:
"105_correct_multifinger_click.patch: Drop patch as it breaks the expected behavior for multitouch clicking (LP: #320585)."

However, I still experience the behaviour introduced in -1ubuntu1. Hopefully I can help get the expected behaviour back in time for karmic's release.

ProblemType: Bug
Architecture: i386
CheckboxSubmission: d90fdc639d79341a7dfe13ba74210bc8
CheckboxSystem: 018dd987ae1f42580fa9d31146e40261
Date: Sat Sep 19 00:29:42 2009
DistroRelease: Ubuntu 9.10
MachineType: Packard Bell BV EasyNote MB85
NonfreeKernelModules: nvidia
Package: xserver-xorg-input-synaptics 1.1.2-1ubuntu5
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic root=UUID=25b243bb-087e-436e-81ca-bee20d03157b ro quiet splash
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.34-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.6.0~git20090817.7c422387-0ubuntu5
 libdrm2 2.4.13-1ubuntu1
 xserver-xorg-video-intel 2:2.8.1-1ubuntu1
 xserver-xorg-video-ati 1:6.12.99+git20090825.fc74e119-0ubuntu1
SourcePackage: xserver-xorg-input-synaptics
Uname: Linux 2.6.31-10-generic i686
dmi.bios.date: 04/07/2008
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: PB2A4A04
dmi.board.name: PB2A
dmi.board.vendor: Packard Bell BV
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: Packard Bell BV
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrPB2A4A04:bd04/07/2008:svnPackardBellBV:pnEasyNoteMB85:pvrPC03Q00101:rvnPackardBellBV:rnPB2A:rvrNotApplicable:cvnPackardBellBV:ct1:cvrN/A:
dmi.product.name: EasyNote MB85
dmi.product.version: PC03Q00101
dmi.sys.vendor: Packard Bell BV
fglrx: Not loaded
system:
 distro: Ubuntu
 archi...

I've seen a fix here http://niblanconinegro.es/blog/2009/11/restaurar-el-funcinamiento-del-touchpad-en-ubuntu-para-los-eee-pc/

I wrote a small program that can be used to work-around the gnome-settings-daemon TapButton2/TapButton3 switching problem. It may be useful if you don't want to manually compile gnome-settings-daemon every time it is updated.

If you switch between VTs or insert and remove other pointing devices it will reset TapButton settings back to what you want.

It uses "xinput watch-props" to monitor changes to xinput properties. Whenever a certain property is changed the program resets this property back to the one configured in the properties array. You may want to edit this part of the code before compiling.

To compile:

$ gcc -o xinputd xinputd.c

To install:

$ sudo install -p -m 0755 xinputd /usr/local/bin/

To automatically start the program when logging in add "xinputd" to "System" -> "Preferences" -> "Startup Applications".

I had the impression that TapButton# options could be configured in the appropriate InputDevice section of xorg.conf, but right now I seem to be unable to do so. The Xorg.0.log reports no errors but synclient -l lists TapButton2=3 and TapButton3=2.

OK, I looked a little further, here’s my understanding.

* The touchpad is first configured with xorg.conf, hal policies and the code in xserver-xorg-input-synaptics.
* When GNOME starts, the gnome-settings-daemon kicks in. It has a mouse plugin that resets TapButton# settings every once in a while, and on each change of the tap_to_click gconf setting. It does that by changing the "Synaptics Tap Action" property, replacing the 5th, 6th and 7th values with (0,0,0) or (1,3,2) to disable or enable tap-to-click, respectively.
* The "Synaptics Tap Action" property is documented in synaptics(4): “order: RT, RB, LT, LB, F1, F2, F3.” So, 1-finger tap is set to button 1 (left), 2-finger tap to button 3 (right), and 3-finger tap to button 2 (middle).
* The xserver-xorg-input-synaptics patch 104_always_enable_tapping.patch is irrelevant because it would only affect the initial setup, which is overridden by gnome-settings-daemon mouse plugin.
* The xserver-xorg-input-synaptics patch 105_correct_multifinger_click.patch is irrelevant because it is commented out, and because it dealt with gestures like “put 2 or 3 fingers on the touchpad and click the physical left button” rather than “tap with 2 or 3 buttons”.
* The Jaunty version of gnome-settings-daemon does not include the tap-to-click code, which explains why the bug appeared in Karmic.

I have created a patch for gnome-settings-daemon that adds three gconf settings and passes their values into "Synaptics Tap Action" property, and submitted it to the GNOME Bugzilla at https://bugzilla.gnome.org/show_bug.cgi?id=598820#c10 .

Still the same bug on an up to date Lucid.

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

- This is a hardware specific bug , not a papercut
For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

uhm, number of people it affects: Everyone with a synaptics touchpad. Easy to fix. A small usability issue. It sounds exactly like a papercut to me. I don't understand the hardware distinction.

I apologise if I'm missing something.

On 01/31/2010 05:23 PM, Henry Gomersall wrote:
> uhm, number of people it affects: Everyone with a synaptics touchpad.
> Easy to fix. A small usability issue. It sounds exactly like a papercut
> to me. I don't understand the hardware distinction.
>
> I apologise if I'm missing something.
>

probably the fact that it only affects people with multitouch-capable
touchpads made it "hardware specific", but it's a lot of people
nevertheless (a lot of netbooks and all macbooks have multitouch touchpads)

Actually, all the laptops I have seen in the last five years are affected, so this bug definitely affects A LOT of people.

OK, here’s a status update.

The patch I sent upstream has passed peer review, but GNOME is currently in feature freeze in preparation for 2.30 release. I have filed for a freeze break, but only received one “not totally against” reply so far, so I’m not confident a break will be granted.

So I’d like to ask if this patch can be accepted into Lucid as a debdiff. If so, how would I go about submitting it, apart from providing the patch itself?

Updated patch.

Test packages for Lucid are available in my ppa at https://launchpad.net/~yurivkhan/+archive/ppa .

The change seems non trivial, could somebody summarize the issue and how it impacts users?

The issue is that, it's difficult to use. Many (most) laptops does have only 2 buttons for left and right mouse button. It seems natural to use something simpler as 2 finger tap to simulate that missing button. Tapping with 3 fingers is almost impossible as mouse pointer often skips and misses (but that can be just me cause of my lazy fingers).

Added Karmic test packages to PPA.

Yuri Khan's PPA works for me, though I have to set the gconf keys to get the desired behavior. Perhaps the defaults for those keys could be changed to give the Jaunty behaviour back?

This happens in Debian testing "Squeeze" also.

This is only a Debian/Ubuntu patch that causes so much trouble?

Alex Dicks wrote on 2010-03-16:
> Perhaps the defaults for those keys could be changed to give the Jaunty behaviour back?

And then users who started using Ubuntu during the Karmic era will file a bug that Lucid changed the defaults and broke their habits, just as we are blaming Karmic here.

Alvaro Kuolas wrote:
> This is only a Debian/Ubuntu patch that causes so much trouble?

No, what causes the trouble is upstream development in GNOME.

===
In fact, I am not fully content with my patch, for two reasons.

First and foremost, the Synaptics tap-to-button mapping is only updated whenever gconf settings change for button assignments, the master tap-to-click on/off switch, or the left/right-handed switch. The right thing to do would be to watch for every DeviceMappingNotify on every input device, so that if the user remaps buttons via e.g. xinput, taps continue working without the user having to go disable/re-enable them. I have not yet managed to get that working, and that is going to be a large change that is better off in the next development phase.

Second, Ubuntu includes corner taps in the definition of tap-to-click, as opposed to GNOME who don’t. This means that in Ubuntu the corner-to-button mapping needs similar treatment — for device button mapping and for customization. I will do an update as time allows.

> Alex Dicks wrote on 2010-03-16:
> > Perhaps the defaults for those keys could be changed to give the
> > Jaunty behaviour back?
>
> And then users who started using Ubuntu during the Karmic era will
> file a bug that Lucid changed the defaults and broke their habits,
> just as we are blaming Karmic here.

It's bizarre to keep behaviour that was only introduced by accident!

I've used Ubuntu on my Eee since Hardy, and the trackpad behaviour had
been the same until Karmic, since when I've had to find workarounds.

I've been establishing my habits for almost two years, yet you're
saying that they're less important than someone who's only been using
Ubuntu for a few months?

I have added another patch that adds gconf settings for corner taps. Available in my PPA for Lucid only.

As for changing defaults, I don’t really have a strong opinion. When there is configuration options, who needs defaults? :)

Yet another case where it is considered more important to pander to new users rather than those who have been with Ubuntu since the beginning... Thanks for the PPA Yuri Khan, I'll be giving it a look to see if it fixes this papercut.

No dice. The current package from Ubuntu is newer than the one in the PPA, will try to see if the gconf keys can be set any way...

Keys don't even exist. This is incredibly frustrating and it feels like Firefox is broken for me because of how much this disrupts my work flow. This needs to be fixed! I'm going to try inserting an older copy of libmouse.so from Karmic to see if that will fix things, otherwise I'm going to have to revert back to Karmic and I don't know what I'll do when Lucid is officially released if this is still broken it disrupts my work flow so much... :(

bornagainpenguin wrote:
> No dice. The current package from Ubuntu is newer than the one in the PPA

I try to keep up and update my packages when a new version is released.

(Is there a way to receive an email notification when a new version of a certain package is released?)

Uploaded an update; builds will be ready in a few minutes.

> I don't know what I'll do when Lucid is officially released if this is still broken

I haven't had any need (other than my own screw-ups) to update the PPA packages for Karmic, since no new versions appear in the official repository. I imagine this will also be the case with Lucid when it goes stable.

> Yet another case where it is considered more important to pander to new users rather than those who have been with Ubuntu since the beginning...

that's not true, it's just that ubuntu gets so many bugs that quite some are tracked actively by nobody in the team or not important enough to get somebody to spend time on those, I'm subscribe to quite some desktop components and read the comments there but the title and bug description don't make sense to me, the laptop I have have 2 buttons and no action reversed...

> the laptop I have have 2 buttons and no action
> reversed...
If you tap with one finger on your touchpad, it makes a left click. If
you tap with two fingers, it makes a right click when it's supposed to
make a middle click. If you tap with three fingers, it makes a middle
click when it's supposed to make a right click.

It's very difficult to find a really good title for a bug.
In short: We don't use the buttons around a touch-pad. If we want to perform a click, we tap on the pad. The standard configuration until jaunty was, that tapping with two fingers performs a mouse3 click. Unfortunately this changed in karmic and lucid. Now we have to use three fingers in order to perform a mouse3 click, which can't be done by normal humans.

I use these multi-touch capabilities very often and it would be great if lucid restores the old behavior.

My use cases:
* Scroll through websites by using two finger scrolling.
* Click at items on the screen by using single-finger tapping. (mouse1)
* Open links on websites in new tabs of Firefox by using two-finger tapping. (mouse3)
* Open the context menu of an item by tapping on the right lower corner of the touch-pad with one finger. (mouse2)

I added 'touchpad' to the title, hope it's clearer ;)

ok, thanks for the new comments, that seems to make some extra sense now, I never used n-finger clicks on the pad there ;-) Does anybody what other OS systems are doing for middle click and right click emulation? We should probably use something coherent with what users are used to

What about making that configurable? I think there is enough place in Touchpanel tab under Mouse preferences.

If that can be configured in gconf-editor (as Yuri showed) it should not be that difficult to add that option.

On 04/14/2010 02:48 PM, DarkV wrote:
> What about making that configurable? I think there is enough place in
> Touchpanel tab under Mouse preferences.
>
> If that can be configured in gconf-editor (as Yuri showed) it should not
> be that difficult to add that option.
>

there are enough configuration paths besides Gnome: udev policy,
xorg.conf, even a sesion startup script to run synclient TapButton2=2
TapButton3=3... problem is, gnome-settings-daemon walks all over that
and loads its hardcoded configuration, and then resets whatever you
configured manually using synclient every time an input device is
added/removed.

The most logical step would be to make gnome leave the predefined
configuration alone; if one knows how to change that, it's most likely
someone who knows what they're doing (or has received copy'n paste
advice from someone who knpws what they're doing).

my 0.02€

As far as I'm concerned, we have some behaviour that a lot of users don't like, we have a patch to configure the behaviour the way anybody likes (and the patch is the debian patch, so it can be used with no additional issues), the patch is working and — please point our if I'm mistaken here — doesn't break anything being applied. The most sensible thing to do right now is to include this patch in Ubuntu version of gnome-settings-daemon and let people, not g-s-d default, deside for themselves. Whether the current default configuration is good for default or not is the whole other story, after all, Ubuntu is becoming known for controversial default settings — most users don't care about defaults as long as they can tweak things to they liking.

As of now, the issue in question is untweakable. We have a patch to make it tweakable. Why on the Planet of Earth can't we just have this patch included and discussion closed?!

it's late in the lucid cycle for new feature now but we should consider that for next cycle for sure yes

@Sebastien Bacher

Windows defaults:
- two finger tap, three finger tap: no action (typical version of Synaptics drivers doesn't make use of these, however Synaptics Gestures Suite - if provided by the laptop manufacturer - may add support for three finger tap),
- one finger scrolling on side of the touchpad.

MacOS defaults:
- I believe that it can be configured so that two finger tap acts as right click, but then again Mac mice haven't got a right button anyway,
- two finger scrolling.

Linux defaults *for years* before Karmic:
- two finger tap as middle click, three finger tap as right click,
- one finger scrolling on side of the touchpad,
- I noticed that two finger scrolling is recently on by default, however it is sometimes hard to properly distinguish between two finger tap and two finger scroll, so I chose to disable scrolling.

To sum things up: the "problem" (actually a matter of taste) affects gnome-settings-daemon as the synaptics driver already has the desired behaviour (which is overridden by the former).

This bug was fixed in the package gnome-settings-daemon - 2.30.0-0ubuntu4

---------------
gnome-settings-daemon (2.30.0-0ubuntu4) lucid; urgency=low

  * Be compliant with the settings in the synaptics driver as regards
    performing middle and right taps with multiple fingers (LP: #432814).
 -- Alberto Milone <email address hidden> Wed, 14 Apr 2010 16:22:46 +0200

Fantastic news. Is this automatically going to be included in lucid, or do we need to file a request so it makes it in for the RC? Just checked the release schedule for lucid and final freeze is tomorrow (15 Apr) so we need to move quickly.

Sebastien, I definitely see your point there, but let me observe that the possibility to tweak touchpad behaviour this way is not a new feature, it's a very old feature broken by the new g-s-d since in Karmic and Lucid. And it's definitely not late to fix bugs, especially regression bugs.

Alberto, thanks for the decision and your time and effort in fixing this.

@Everybody: Is it a sound idea to open a new bug (with "wishlist" priority, for sure) to include the patches Yuri has provided, or do we from now on stick with setting up the driver and don't let g-s-d interfere?

I'm sorry for those of you who don't want to change years of muscle memory, but right-click is more common that middle click and should have the easier gesture; 2-tap for right-click, 3-tap for middle-click. If you are a heavy middle-click user, you should certainly change the settings on your computer to assign the easier gesture to meet your needs, but 2-tap should default to right-click.

David, please consider the following: nearly all touchpads have hardware buttons for right-click. Nearly none of them has a hardware button for middle-click. It takes an unhuman skill to perform a 3-finger tap, so with 2-finger tap assigned to right-button, the only usable way to perform a middle click is to plug in a mouse. Middle clicks are of great use in Linux (clipboard insertion to name one of the essential things), so having no way to do them is a bad bad choise.

Anyway, that's not what the bug was about. The bug was about the fact that there was no way to change the default behaviour at all. Now there is a way (or will be, as soon as Alberto's upload builds), and that's the fix. What the default setting should be is another topic altogether.

@David
I have no strong opinion on this as I don't use multi tap actions and I consider this issue a matter of taste.

If we decide to revert the change I guess we should revert this in the synaptics driver too so that the touchpad behaviour doesn't change after you enter the gnome session (i.e. when the gnome-settings-daemon is launched).

@Evgeny
I only changed the default values as, at this point in the release cycle, it's a little late to include Yuri's patch, I guess

@Alberto
So do we need another bugreport to actually reflect the impossibility of settings change (as in Yuri's patch) and deem this bug here fixed with the changes you've provided? The fix you've supplied technically fixes this bug (judging by it's description), but not the linked gnome-bugs bug (and that was fixed by Yuri's patch).

@Evgeny, oops, sorry if I read the bug incorrectly!

If 3-tap truly takes "takes an unhuman skill to perform," then it
shouldn't be assigned any gesture.

Yes, middle-click is a great and venerable feature that I sometimes
use, and that many people commenting on this bug find indispensable.
But more people use right-click than middle-click, and many new
laptops are dropping physical buttons altogether (especially
netbooks). I am not referring only to Macs, but I'd still wager that
the number of users running Ubuntu on Apple laptops, where right-click
is performed with 2-tap, has already exceeded the number of Ubuntu
users who use 2-tap for middle-click.

Which really means we need an option to be available for user.

Since this bug will be marked as fixed after Alberto's upload, and the issue with inability to tweak this setting persists, I've opened a new bugreport #563276 about exactly this matter. I'll be thankful for Yuri and Alberto if they subscribe to it and help make sure Yuri's patch lands at least in Maverick, because otherwise this won't be fixed until Gnome 3 is released, and that can take long time.

I've found strange behaviour after using Yuri's path:
http://www.youtube.com/watch?v=DNvnvAcpbQc

Settings are just ignored. And thats repeatable. If I reboot my settings are back (untill I connect external mouse again).

I've reverted my changes to the gnome-settings-daemon and I did the same with synaptics driver default settings. Now we're more compliant with upstream's default settings (both Gnome and synaptics use 1 3 2 instead of 1 2 3).

I definitely agree that a we need an easy way to make this configurable but it's too late to make such changes in Lucid. Hopefully I'll have enough time to deal with this in Maverick.

@Evgeny
Please file a new bug report about the need of an easy way to change the touchpad values and feel free to assign it to me.

I don't think tree-finger is that difficult: it just requires a bit to get used to. Also I do use two-finger tap quite a lot, so... I'm biased. 1-2-3 for me! From reading around it seems to me that the majority would like that 123.

Also, if it can be of any help, kubuntu lucid _has_ the ability to change setting and it's probably worth a visit.

Bug confirmed in the Netbook Remix 10.04 (Lucid) release. Taps are still 1-2-3 instead of 1-3-2, and I don't see any configuration options in the Mouse preferences panel to change it.

Two-finger scroll works like a scroll wheel, which clicks as mouse3 on most mice. A two-finger tap physically mirrors a chording click on a regular 2-button mouse/trackball/trackpad/trackpoint, which I expect to produce a mouse3 click as it has for more than a decade now. Up until a year ago, Ubuntu standardized on mouse3. All of our two-finger conventions point to mouse3.

1-2-3 makes the user experience inconsistent, too. Two fingers on the pad gives me mouse2, while two fingers on the buttons gives me mouse3?

I didn't think we needed to discuss *whether* 1-3-2 was a valid decision, just how to bring it back. 1-2-3 should be a supported user customization, not a default.

Is still the same in Ubuntu 10.04 Lucid.

Guys, I really don't understand.
72 posts about exchanging 2 -> 3 and 3 -> 2. Is it really so hard? There are a lot of other important things that we can/should do. Why can't we just exchange 2 <-> 3 back and close the issue?

Because of this change in behavior, the usability of my eeepc is severely degraded. On this netbook, it is nearly impossible to click both hardware buttons at once because of how they were designed, so I relied heavily on the two-finger tapping method. Now that is gone. Since the touch-pad is pretty small, the already difficult three-finger maneuver becomes impossible. Thus, having two-finger tapping as middle click is necessary. Now I'm left without a sane middle click option, no more highlight-paste buffer, no more easy opening of tabs in firefox, etc.

This switch in behavior seems unfounded to me. I'm dubious as to whether right click really is more frequently used than middle click for the majority of people; think of all the web browsing and copy-pasting that goes on.

At the very least, there should be an easy way to change this behavior from the Ubuntu options by default instead of relying on hacks to change it. Sometimes Ubuntu is really intuitive and easy to use... and other times it takes hours to figure out how to change touch-pad options.

Thanks for the PPA. It let me fix GNOME's/Ubuntu's bad/idiosyncratic touchpad defaults. I couldn't understand why in the world double-tapping was resulting in a right-click when I started using Ubuntu on my netbook. It's a real pain. Hopefully this will be fixed in 10.10.

I’m afraid not, as whenever I happen to have enough free time to work on this patch, both GNOME and Ubuntu turn out to be in feature freeze, and extended configurability counts as a feature.

However, I will produce PPA builds for Maverick as soon as I get around to installing the alpha and will maintain them; also, as soon as GNOME unfreezes (which should be late September) I will attempt to get this accepted upstream.

@David Siegel
I use the middle-click equally or even more often than the right-click, that's because of Firefox. Besides that, I have a physical button for right-click, so the touchpad gesture is really needed.

@Yuri Khan
Impressive work, you have done.

@Yuri: (lucid proposed) PPA package is older than g-s-d again

@whoever maintains the Ubuntu package: frankly I find this ridiculous, this bug has been here for more than a year, there is a fix which works fine (I have been using it since February, so did others) and we have seen 2 releases already (ok, first time there was a feature freeze, but the second time? with a working patch that probably needed minimal changes?)

Lucid was almost a year ago. Shouldn't this be an open bug against Maverick (stable) or even Natty (impending LTS release)? Or have we blown those deadlines, and now we have to shoot for 11.10?

This is still a daily frustration for me. Getting all three fingers to land at the same time for my second-most-used-click is nigh impossible. In modern releases, not even the old synclient hack works anymore. We're left out in the cold.

I love Ubuntu, which is why it pains me to see a major UI bug that affects UX on a minute-to-minute basis take more than 1.5 years to resolve.

In GNOME, they decided that it is more appropriate to provide a hook that will run a user-customizable script when an input device is added or removed. The xinput or synclient invocations shown above can be added to this hook. So, for all intents and purposes, this bug can be considered “Fix Committed”.

It sounds like the hook script feature provides a framework for a fix, but not an actual fix for this bug. Has 1/2/3 behavior been restored?

I guess I'm looking for a legitimate bugfix or a declaration from the Ubuntu maintainers that 1/3/2 (left/right/middle) is the new Ubuntu multitouch standard. If they pick 1/3/2 as the new standard, we can either start lobbying for change, lobbying the GNOME maintainers for a better mouse settings GUI, or build out a separate mouse behavior customization tool.

How do I mark this bug as "Needs Closure"? =)

About Yuri Khan comment.
Yet I haven't found any documentation about writing such hooks. In fact, those innovations don't allow using any other "legacy" methods for changing tapbuttons behaviour (https://bugzilla.redhat.com/show_bug.cgi?id=518502).
P. S. there is very few people posting about this problem on forums. Am I searching wrong requests or this bug really bothers not so much people? e.g. Haven't found any mention (except 79 comment) that this bug still present in natty.
P.P.S. So, correct me if I'm wrong, current solution to this problem is to use scripts that run synclient (or xinput) at startup and resume/suspend(don't actually know how to implement that one) or use Yuri Khans' builds (and to have headache every time official package is updated).
P. P. P. S. I have tried modify xorg configs and udev rules - both unsuccesfully.

On 04/26/2011 01:07 AM, palanutsa wrote:
> P.P.S. So, correct me if I'm wrong, current solution to this problem is to use scripts that run synclient (or xinput) at startup and resume/suspend(don't actually know how to implement that one) or use Yuri Khans' builds (and to have headache every time official package is updated).

I, for one, pinned g-s-d to Yuri's PPA, which means I won't have
problems when a new release comes along and he didn't have time to update

iacobs@shire:~$ cat /etc/apt/preferences.d/gsd-yuri
Package: gnome-settings-daemon
Pin: release o=LP-PPA-yurivkhan-proposed
Pin-Priority: 1100

> P. P. P. S. I have tried modify xorg configs and udev rules - both unsuccesfully.

this is a (big) part of the problem, g-s-d hardcodes a specific
behaviour and doesn't care about things configured in other places; it
will even reset that behaviour when you add / remove a mouse, for
instance; <rant>while there were hints of this before, lately it became
obvious that Gnome devs think all their users are idiots and and the
only way to use one's computer should be what their _designers_ came up
with - see Gnome 3 power manager settings, minimize button
discussions</rant>

Of course implementing a setting in gnome-mouse->touchpad would be desirable and I don't understand why they don't. KDE has a nice GUI configuration tab.

Anyway, a quick workout in Ubuntu Natty, working in squeeze as well, is to add a tiny script in autostart, working "per user":

synclient TabButton2=2
synclient TabButton2=2

I seem to recall it has been already mention here and elsewhere.

BTW Gnome might have their good reasons, but I _do_ use two finger tapping a lot and find three finger usage a bit awkward. and less precise.

Sorry it should have been:

synclient TabButton2=2
synclient TabButton3=3

Those using natty with Unity(gnome 2), could join my PPA https://launchpad.net/~o.shybystyi/+archive/gnome-settings-daemon-natty.

Oleksandr Shybystyi, that doesn't work for gnome3? That's a shame. I think
I'm just going to give OpenSuse a try, I've had it with all those terribly
easy to solve bugs in Ubuntu that are open for more than a year.

On Wed, May 4, 2011 at 8:02 AM, Oleksandr Shybystyi <
<email address hidden>> wrote:

> Those using natty with Unity(gnome 2), could join my PPA
> https://launchpad.net/~o.shybystyi/+archive/gnome-settings-daemon-natty<https://launchpad.net/%7Eo.shybystyi/+archive/gnome-settings-daemon-natty>
> .
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (646207).
> https://bugs.launchpad.net/bugs/432814
>
> Title:
> Touchpad: Action for middle and right click is reversed since jaunty
>
> Status in Gnome Settings Daemon:
> Invalid
> Status in NULL Project:
> Invalid
> Status in “gnome-settings-daemon” package in Ubuntu:
> Fix Released
> Status in “xserver-xorg-input-synaptics” package in Ubuntu:
> Invalid
> Status in “gnome-settings-daemon” source package in Lucid:
> New
> Status in “xserver-xorg-input-synaptics” source package in Lucid:
> Invalid
>
> Bug description:
> Binary package hint: xserver-xorg-input-synaptics
>
> LSB version = karmic
> Package version = 1.1.2-1ubuntu5
>
> Expected behaviour:
> Tap the touchpad with 2 fingers simultaneously to generate middle-click
> event. Tap with 3 fingers for right-click event.
>
> Observed behaviour:
> A 2-finger tap generates a right-click event and a 3-finger tap generates
> a middle-click event.
>
>
> Looking at the changelog for 1.1.2-1ubuntu1 I see this:
> "105_correct_multifinger_click.patch: Swap the right/middle clicks
> generated by multi-finger tapping."
> This patch is then reverted in 1.1.2-1ubuntu2:
> "105_correct_multifinger_click.patch: Drop patch as it breaks the expected
> behavior for multitouch clicking (LP: #320585)."
>
> However, I still experience the behaviour introduced in -1ubuntu1.
> Hopefully I can help get the expected behaviour back in time for
> karmic's release.
>
> ProblemType: Bug
> Architecture: i386
> CheckboxSubmission: d90fdc639d79341a7dfe13ba74210bc8
> CheckboxSystem: 018dd987ae1f42580fa9d31146e40261
> Date: Sat Sep 19 00:29:42 2009
> DistroRelease: Ubuntu 9.10
> MachineType: Packard Bell BV EasyNote MB85
> NonfreeKernelModules: nvidia
> Package: xserver-xorg-input-synaptics 1.1.2-1ubuntu5
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic
> root=UUID=25b243bb-087e-436e-81ca-bee20d03157b ro quiet splash
> ProcEnviron:
> LANG=en_GB.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-10.34-generic
> RelatedPackageVersions:
> xserver-xorg 1:7.4+3ubuntu5
> libgl1-mesa-glx 7.6.0~git20090817.7c422387-0ubuntu5
> libdrm2 2.4.13-1ubuntu1
> xserver-xorg-video-intel 2:2.8.1-1ubuntu1
> xserver-xorg-video-ati 1:6.12.99+git20090825.fc74e119-0ubuntu1
> SourcePackage: xserver-xorg-input-synaptics
> Uname: Linux 2.6.31-10-generic i686
> dmi.bios.date: 04/07/2008
> dmi.bios.vendor: Phoenix Technologies LTD
> dmi.bios.version: PB2A4A04
> dmi.board.name: PB2A
> dmi.board.vendor: Packard Bell BV
> dmi.board.version: Not Applicable
> dmi.chassi...

2011/05/05 mcDavid wrote:
> Oleksandr Shybystyi, that doesn't work for gnome3? That's a shame. I think
> I'm just going to give OpenSuse a try, I've had it with all those terribly
> easy to solve bugs in Ubuntu that are open for more than a year.
As much as I am familiar Unity doesn't work on gnome 3.
If you need fix for this bug for gnome 3 of for previous versions of Ubuntu, read description of my PPA:
> f you need built of fixed package for Natty with Gnome 3 or previous versions of Ubuntu - visit
> https://launchpad.net/~yurivkhan

There must have been a misunderstanding here. I’m not going to support my patches on GNOME 3. In fact, they are not needed there, as there is the hook framework.

When time allows, I will update my PPA for Natty, but only because Natty was released with GNOME 2. (And I understand them — GNOME 3 is horrible at the moment.)

Status changed to 'Confirmed' because the bug affects multiple users.

Any news on how to handle this on Oneiric? Neither yurivkhan's or o.shybystyi's PPAs have been updated to 11.10 (and naturally, there is still no way to configure this on Gnome itself).

Ok, figured it out, on Oneiric Unity uses the new gnome-settings-daemon, and to configure the touchpad post g-s-d, we should use this:

http://who-t.blogspot.com/2011/03/custom-input-device-configuration-in.html

Today some updates to Lubuntu 12.04 change the behaviour to double tap = right click.
I consider that a bug and would like to see it fixed. I have a right button my me EeePC.

synclient TapButton3=3 TapButton2=2 fixes it temporarily.

With every Fedora and Ubuntu release these problems crop up, I guess it is because some Gnome devs think the Mac way of doing things is always right. It is really annoying.