Description of problem:
Having set Left-Hand mouse buttons
Using a kvm switch, if I switch PC's and come back to F9-Beta+ Updates.
The mouse buttons are right-handed again.
Even thought the "mouse preferences" gui says left-handed.
If I just re-boot without changing the with kvm, it holds the mouse settings.
KVM does not affect the F8 boxes, CentOS5 left-handed setup
This would seem to be a bug in the xorg mouse driver, and/or the mouse prefs
applet, not the mousepad editor. ;)
I am switching it over to that component to get looked at.
Thanks for the bug report!
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 302977 [details]
Created attachment 302978 [details]
Xorg.log before deleting xorg.conf
Created attachment 302983 [details]
No xorg.conf recreated!, but am typing into this, so have some sort of display.
Have attached new xorg.0.log
You might also supply what brand/model your mouse is, how it's connected
(usb?),and maybe what brand/model kvm switch your using? I don't know how to
fix it myself, but that might help diagnose the problem.
Created attachment 304772 [details]
dmesg (7th May 2008)
Mouse: Dell Optical Scroll (no model number)
KVM: Aten Dual-VGA Masteview USB CS-1744
Created attachment 304928 [details]
lsusb - result
Created attachment 305007 [details]
/var/log/messages - excerpt
After switching back anf forth using KVM, noticed the following patterns
in messages and Xorg.log
Created attachment 305008 [details]
/var/log/Xorg.0.log - excerpt
May 10 09:08:21 frank-02 kernel: input: USB Optical Mouse as
Have noticed /input/input* goes up by a digit 6,7,8,9,10
Created attachment 305009 [details]
F8 - excerpts for comparison
When KVM used on F8 box, only /var/log/messages change, no change to
input line still goes up by digit:
May 10 09:30:18 frank-01 kernel: input: USB Optical Mouse as
Using lshw found this:
Generic USB device
product: USB Optical Mouse
vendor: Primax Electronics, Ltd
bus info: usb@6:2.4
this device hasn't been claimed
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
I also have this problem. It seems to be caused by USB disconnect - one can
reproduce the problem by just unplugging and reconnecting the mouse cable. Older
versions of Fedora are unaffected.
(In reply to comment #16)
> I also have this problem. It seems to be caused by USB disconnect - one can
> reproduce the problem by just unplugging and reconnecting the mouse cable. Older
> versions of Fedora are unaffected.
I can confirm this.
Mouse attached via USB, running Fedora 9, KDE 4.
After disconnect/reconnect OR suspend/resume the mouse goes back to right-handed.
One needs to switch to right handed, and back to left handed.
I am sure in Fedora 7 the disconnect/reconnect did not affect the
left-handedness. Never tried to suspend in F7.
*** Bug 447693 has been marked as a duplicate of this bug. ***
Another confirmation. I'm using a USB mouse attached to a laptop. After
suspend/resume it changes from left-handed to right-handed. This behaviour
started immediately after an upgrade from Fedora 8 to Fedora 9 (Gnome)
am doing afull F8 re-install to test this,
updates to f9 one by one a-z
Tried as per comment #20, system got trashed whn came to yum update x\* X\*
BUT yum update \*usb\* or \*mouse\* had no effect on leftness.
Then this came up in fedoa-list:
Goin by that maybe it's a power\resume thing. But the script didn't work here.
Where would the usb connect\disconnect\re-connect stuff be found?
Maybe a script there?
I tried "fixing" this with a pm-suspend script in /etc/pm-utils/sleep.d that
would save and restore the pointer settings with xmodmap -pp, but that didn't
work. pm-utils did run xmodmap with the correct arguments but it had no effect
on the X desktop upon resume.
The mailing list post above also anecdotally suggests running xmodmap twice;
that appears to be unnecessary for my system.
Given how long USB mice have been around, and given how long left-handed
computer users have been around, I think this bug should have a higher priority.
Created attachment 311234 [details]
Could it be the kernel,
Thats losing the usb
did a yum install gnome-volume-manager.
Theres a bit on that that goes:
program to run when usb mouse is found\connected.
I tried it with the little xmodemap thigk from:
Didn't work, could someone come up with something?
the only code I know being the "safe cross one"
This a problem with gnome-mouse-properties, changing component.
The X server's behaviour is that a core SetPointerMapping request applies not
only to the core device but also to all extension devices. So when you set the
mouse to left-handed in gnome-mouse-properties, all connected devices are set to
A newly plugged in mouse however comes with the defaults - right handed, hence
why the mapping changes after the KVM switch or the unplugging of the device.
gnome-mouse-properties should listen to DevicePresenceNotifyEvents and re-apply
the left-handed setting for new devices using the DeviceSetButtonMapping request.
(In reply to comment #26)
> A newly plugged in mouse however comes with the defaults - right handed, hence
> why the mapping changes after the KVM switch or the unplugging of the device.
> gnome-mouse-properties should listen to DevicePresenceNotifyEvents and re-apply
> the left-handed setting for new devices using the DeviceSetButtonMapping request.
Wouldn't a fix along these line just work on Gnome?
Not everyone uses Gnome. And in my case the properties were set with xmodmap,
not with gnome-mouse-properties.
Again, this used to work on F8 when it came out, it broke after one of the updates.
Yeah, I'm using KDE, and I'd like to see the issue fixed there too.
(In reply to comment #28)
> Yeah, I'm using KDE, and I'd like to see the issue fixed there too.
File a new bug against the KDE control center as well then. It's very possible
XFCE or any other mouse config tool has the problem.
(In reply to comment #29)
> (In reply to comment #28)
> > Yeah, I'm using KDE, and I'd like to see the issue fixed there too.
> File a new bug against the KDE control center as well then. It's very possible
> XFCE or any other mouse config tool has the problem.
IMHO going that way is misguided.
This used to work when not using any control center, just xmodmap -e "pointer =
3 2 1", and it worked on all version of RH and on all versions of FC, on F7 and
F8 at the time it came out..
(In reply to comment #27)
> Wouldn't a fix along these line just work on Gnome?
> Not everyone uses Gnome. And in my case the properties were set with xmodmap,
> not with gnome-mouse-properties.
yeah, I assumed the original reporter used the g-m-p.
There is the xinput tool that enables you to set the button map on each device
xinput set-button-map "device name" 3 2 1
Not in fedora yet, get it from
> Again, this used to work on F8 when it came out, it broke after one of the
It's an upstream issue, change of behaviour introduced last August. Before the
following commit, all devices would use the core pointer's button mapping.
Since this commit, each device uses its own button mapping.
(In reply to comment #30)
> (In reply to comment #29)
> > File a new bug against the KDE control center as well then. It's very possible
> > XFCE or any other mouse config tool has the problem.
> IMHO going that way is misguided.
> This used to work when not using any control center, just xmodmap -e "pointer =
> 3 2 1", and it worked on all version of RH and on all versions of FC, on F7 and
> F8 at the time it came out..
I disagree with the notion of it being misguided. Upstream X.Org goes more and
more towards per-device configuration and will eventually ditch the core pointer
concept for all but corner cases. With the upcoming X Input Extension 2, many
tools such as xmodmap will lose much of their meaning.
The sooner we can get the config tools to update, the less painful the future
Yea, Peter is right. gnome-settings-daemon currently loops through every device
and applies the button remapping on startup. It doesn't listen for new devices,
however. We need to fix that.
Still borked F10-Alpha
*** This bug has been marked as a duplicate of bug 324721 ***