Touchpads should be unaffected by left handed mouse option

[Joseph Garvin]

If in System->Preferences->Mouse I check the left handed box, now when I tap on
my touchpad it considers it to be a right click. It should continue to treat
tapping on the touchpad itself as a left click -- laptop touchapds are usually
centered on the laptop and thus are orientation neutral. In my case I want my
mouse when plugged in to be left handed, but when it's not and I use my touchpad
it should assume a tap is a left click. I can't think of any reason why a user
would want tapping their touchpad to be a right click, it's basically useless.
And most touchpads come with a couple buttons for clicking with beneath them --
these it makes sense to reverse. But tapping the touchpad should always be a
left click.

[Daniel Robitaille (robitaille)]

I can confirm this problem.

[Jonathon Conte (thesicktwist)]

Same problem here on an IBM T41 Thinkpad. There are two sets of buttons and two pointing devices (touch pad and TrackPoint pointing device) on the T41. When I set the mouse orientation in GNOME to left-handed, the buttons should be reversed but tapping on the touch pad should still be interpretted as clicking the primary mouse button. As it is now, tapping on the touch pad is interpretted as clicking on the secondary mouse button when the mouse orientation is set to left-handed.

[Courtney Rosenthal (courtneyr)]

Workaround is to go into /etc/X11/xorg.conf find the "Synaptics Touchpad" (or whatever) section and add lines that say:

    Option "TapButton1" "3"
    Option "TapButton3" "1"

[Matthew Lange (matthewlange)]

Would this also apply to the package that sets the right-handed or left-handed flag? I'm not sure what actually takes care of that; synaptics or a gnome package. If it's a gnome package, it should be flagged under this bug too.

[unikuser (unikuser)]

TabButton thing worked for me.

I had a case where I want my mouse to swith button, but don't want touchpad to swiitch buttons. For this, instead of selecting left hand button in gnome, I have changed xorg.conf to switch normal mouse buttons and keep touchpad buttons unswapped.

Option "ButtonMapping" "3 2 1" ( add this to normal mouse and not touchpad)

[David (david-redhat-bugs)]

Description of problem:

If you change the mouse preferences to left handed, this SHOULD NOT change the
functionality of a tap on a laptop's touchpad, which should still function as
the primary mouse button click.

But on f7, switching to use a left-handed mouse changes the touchpad touch
functionality to be the reverse of what you'd expect. This is annoying and
frustrating to left-handed users.

From dmesg:
input: PS/2 Mouse as /class/input/input1
input: AlpsPS/2 ALPS GlidePoint as /class/input/input2
input: AT Translated Set 2 keyboard as /class/input/input3

Versions:
Kernel 2.6.22.9-91.fc7
nautilus-2.18.3-1.fc7

[Matěj (matj-redhat-bugs)]

Being a left-handed myself, I would ask just one question -- why do you use
left-handed mouse settings with touchpad? It doesn't make any sense to me. Do
you use both mouse and touchpad in the same time?

[David (david-redhat-bugs)]

I normally use an external mouse when my notebook is at home but if I decide to
use the touchpad or take the computer somewhere where I need to use it because I
don't have the mouse, then I shouldn't need to go into the settings to switch it
back to right handed....that becomes very annoying after 100 or so times of
using the notebook at home and then using it elsewhere, having to switch it.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.

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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Peter (peter-redhat-bugs)]

This isn't really a mouse driver bug, it's a conceptual issue with the X
server's event processing.

Problem being that the SetPointerMapping request by default changes the core
pointer device. Up to X11R7.4, any core event, no matter who actually generates
it, comes from the core pointer and thus assumes the core pointer's mapping
(which in your case is left-handed).

This problem is fixed in Xorg git, but needs a vastly different input system. It
also requires configuration tools to set the button mapping per device, and not
just for the core pointer.

[Peter (peter-redhat-bugs)]

Did some more research, fix is possible for F9.

X.Org Bug 11683 [1] changed the mapping behaviour to take the device's button
mapping instead of the core pointer's. However, the core protocol request
SetPointerMapping applies to all devices, so a SetDeviceButtonMapping request is
required.

A button mapping per device is thus possible but requires an appropriate
configuration tool.

Changing component to control-center, this should be part of gnome-mouse-properties.

[1] http://bugs.freedesktop.org/show_bug.cgi?id=11683

[Ray (ray-redhat-bugs)]

So at one point a long time ago gnome-settings-daemon just SetPointerMapping and
when users set their mouse to left handed mode only the first mouse would be
left handed and subsequent mice would be right handed.

(It got even weirder if you had /dev/mice as one device and /dev/input/mouse2
then you'd end up with the left and right mouse button getting pressed
simultaneously no matter which button you pressed)

I fixed that in gnome-settings-daemon by using SetDeviceButtonMapping on every
mouse device to be left handed. I assume the code is still like that, but I
haven't looked at it in a while.

We don't need a configuration tool, we need to detect that the touch pad and not
remap it (assuming that's possible)

[Matěj (matj-redhat-bugs)]

(In reply to comment #6)
> We don't need a configuration tool, we need to detect that the touch pad and
> not remap it (assuming that's possible)

Peter, what do you think?

[Peter (peter-redhat-bugs)]

SetDeviceButtonMapping is definitely the right way to go. In theory, a touchpad
should have the Atom XI_TOUCHPAD set as its type, although at least synaptics
doesn't do it.
so you need some other (human) method to figure out which device is a touchpad.

[Ray (ray-redhat-bugs)]

we should fix synaptics, not punt to the user

[Peter (peter-redhat-bugs)]

*** Bug 442250 has been marked as a duplicate of this bug. ***

[William Grant (wgrant)]

-synaptics now says that it's an XI_TOUCHPAD, so g-s-d just needs to DTRT.

[Peter (peter-redhat-bugs)]

(In reply to comment #9)
> we should fix synaptics, not punt to the user

xorg-x11-drv-synaptics-0.15.2 announces itself as type XI_TOUCHPAD.

[Frank (frank-redhat-bugs)]

Any updates on this?
As my original https://bugzilla.redhat.com/show_bug.cgi?id=442250
is still there in the latest F-10\Rawhide,
and with F8 coming near eol :(

Frank

[Frank (frank-redhat-bugs)]

(In reply to comment #12)
> Any updates on this?
> As my original https://bugzilla.redhat.com/show_bug.cgi?id=442250
> is still there in the latest F-10\Rawhide,
> and with F8 coming near eol :(
>
> Frank

This now seems to be sorted in F-10, is sporadic in F-9.
No longer have F8 insalled.

F10 -- xorg-x11-drv-synaptics-0.15.2-1.fc10.i386
F9 -- xorg-x11-drv-synaptics-0.15-3.fc9.i386

Frank

[Matěj (matj-redhat-bugs)]

Reporter, could you confirm, this has been fixed in F-10, please?

Thank you

[David (david-redhat-bugs)]

No, I can see that this issue has NOT been resolved in F10 and is still apparent, at least with xorg-x11-drv-synaptics-0.15.2-1 which seems to be the latest released.

[root@clevo ~]# rpm -q -a | grep xorg-x11-drv-synaptics
xorg-x11-drv-synaptics-0.15.2-1.fc10.i386

[root@clevo ~]# uname -a
Linux clevo 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux

Changing the mouse orientation setting to left still incorrectly makes a tap on the touch pad bring up a pop-up menu.

input: PS/2 Mouse as /devices/platform/i8042/serio4/input/input5
input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio4/input/input6

[Peter (peter-redhat-bugs)]

this is back to control-center now, it needs to avoid mapping buttons for devices that announce themselves as type XI_TOUCHPAD (see Comment #6)

[Fedora (fedora-redhat-bugs)]

gnome-settings-daemon-2.24.1-6.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/gnome-settings-daemon-2.24.1-6.fc10

[Ray (ray-redhat-bugs)]

Created attachment 326532
Pushed this untested patch

Would someone mind giving it a go?

[Peter (peter-redhat-bugs)]

Sorry, still changes my touchpad (that's with 2.24.1-7)

[Ray (ray-redhat-bugs)]

Pushing another (again untested) build that may work.

We were calling XSetPointerMapping and the XInput equivalent. Since XSetPointerMapping works on all devices now instead of just the core pointer, it was undoing the fix.

This change drops the XSetPointerMapping call.

[Fedora (fedora-redhat-bugs)]

gnome-settings-daemon-2.24.1-7.fc10 has been pushed to the Fedora 10 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 gnome-settings-daemon'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11131

[Ray (ray-redhat-bugs)]

I spent some time testing this yesterday and it's not working.

[Fedora (fedora-redhat-bugs)]

gnome-settings-daemon-2.24.1-7.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.

[Mike (mike-redhat-bugs)]

Tested 2.24.1-7 on Samsung Q35 - switched mouse to left handed, and touchpad has also switched so that tap no longer gives normal options. So this updated has not worked for this laptop. This confirms comment #22 and a further attempt at fixing this problem is needed.

[Mike (mike-redhat-bugs)]

Please re-open this bug as the problem is not fixed.

[Matěj (matj-redhat-bugs)]

(In reply to comment #25)
> Please re-open this bug as the problem is not fixed.

Please file a new bug, so that we have you as a reporter.

Thank you

[Mike (mike-redhat-bugs)]

https://bugzilla.redhat.com/show_bug.cgi?id=483639

[Bastien (bastien-redhat-bugs)]

*** Bug 455492 has been marked as a duplicate of this bug. ***

[Martin Olsson (mnemo)]

It's marked as fixed in the Fedora operating system only, there is no bugfix created for Ubuntu yet. However, it seems that some people using Fedora also reported that the bugfix that shipped in Fedora did _not_ actually solve the issue so a new RH bug was opened here: https://bugzilla.redhat.com/show_bug.cgi?id=483639

[Frosen (frosen)]

I approve that bug. Is there a workaround for Jaunty? It would be fantastic!

[Robert Hooker (sarvatt)]

This is because of patch 104_always_enable_tapping.patch in xserver-xorg-input-synaptics which hard codes the initial tapbutton values in the source, and the values need to be different when in left handed mode.

- /* 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;

From man synaptics --

       Button mapping for physical buttons is handled in the server. If the device is switched to left-handed (an in-server mapping of physical buttons 1, 2, 3 to the logical buttons 3, 2, 1, respectively), both physical and TapButtons are affected. To counteract this, the TapButtons need to be set up in reverse order (TapButton1=3, TapButton2=1).

They have added support of enabling/disabling TapButtons via input properties in the g-s-d mouse capplet upstream now, but perhaps an additional check for left handedness could be added to change how it assigns the buttons?

http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=4eb9bd09219afbb56f114a2d10bc585e24db803e

Sorry if I'm misunderstanding the situation.

[Sebastien Bacher (seb128)]

the issue is fixed in karmic

[Alberto Milone (albertomilone)]

@Robert
Those values are hard coded in the original driver too.

It looks like upstream decided to apply the following changes in g-s-d:

1) Don't swap mouse buttons for left-handers on the touchpad (otherwise
a tap would be a right-click)
2) If XInput is supported, don't switch the core pointer to left-handed,
as it would cancel our other settings

http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=6a3bedfcb9be30b883a145d7e4ce83fd9cbc3e25

I'm marking the report as invalid for the synaptics driver.