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.
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
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?
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.
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:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
Did some more research, fix is possible for F9.
X.Org Bug 11683  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
A button mapping per device is thus possible but requires an appropriate
Changing component to control-center, this should be part of gnome-mouse-properties.
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)
(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?
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.
we should fix synaptics, not punt to the user
*** Bug 442250 has been marked as a duplicate of this bug. ***
(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.
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 :(
(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 :(
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
Reporter, could you confirm, this has been fixed in F-10, please?
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
[root@clevo ~]# uname -a
Linux clevo 22.214.171.124-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
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)
gnome-settings-daemon-2.24.1-6.fc10 has been submitted as an update for Fedora 10.
Created attachment 326532 [details]
Pushed this untested patch
Would someone mind giving it a go?
Sorry, still changes my touchpad (that's with 2.24.1-7)
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.
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
I spent some time testing this yesterday and it's not working.
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.
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.
Please re-open this bug as the problem is not fixed.
(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.
*** Bug 455492 has been marked as a duplicate of this bug. ***