Bug 212446 - mouse scrolling events wrong
mouse scrolling events wrong
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-10-26 16:07 EDT by Thomas J. Baker
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-27 22:05:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log (52.45 KB, text/plain)
2006-10-26 23:30 EDT, Jim Hayward
no flags Details
The right Xorg.0.log (50.75 KB, text/plain)
2006-10-26 23:49 EDT, Jim Hayward
no flags Details

  None (edit)
Description Thomas J. Baker 2006-10-26 16:07:13 EDT
Description of problem:

I installed FC6 on three systems yesterday, each with a Logitech MX-1000
cordless mouse. On two of the three systems, mouse scrolling doesn't work
correctly due to the events being different than normal. Using xev to see the
events, on the two broken systems, mouse scrolling events are buttons 8 and 2
instead of 4 and 5. This also messing up middle button pasting

Also, with the same mouse on the working system the middle button (side on this
mouse) was not recognized with the minimal X config. I just verified that this
also happens when I plug an MX500 mouse into my laptop. Side button is not
recognized as button two. Xev reports it as button 8.

By adding an InputDevice section like this the middle mouse button function is

Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "IMPS/2"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "yes"
    Option         "ZAxisMapping" "4 5"

Unfortunately on the two problem systems this doesn't work. The events are still
incorrect, or at least unexpected. I don't know if this is a kernel problem or
what. I'll be able to do some more investigating tonight. I am using the evil
nvidia binary drivers on the three desktop systems but the laptop is intel all
the way.

Seems like by default, some of the mouse button mapping might be off. And of
course, the system I ran FC6 testing from T2 on is the one that works while the
two that don't have been running FC5 until yesterday.

Version-Release number of selected component (if applicable):

Comment 1 Jim Hayward 2006-10-26 23:30:46 EDT
Created attachment 139550 [details]
Comment 2 Jim Hayward 2006-10-26 23:33:31 EDT
I also have the same problem with a clean install of FC6. The problem did not
exist in FC5. I also tried adding my own mouse section to the minimal xorg.conf,
but the problem persists.

My Xorg.0.log is attached.
Comment 3 Jim Hayward 2006-10-26 23:46:31 EDT
Oops, sorry wrong Xorg.0.log.
Comment 4 Jim Hayward 2006-10-26 23:49:30 EDT
Created attachment 139551 [details]
The right Xorg.0.log
Comment 5 Thomas J. Baker 2006-10-27 18:24:01 EDT
So I'm an idiot and had this in my .login:

if ($DISPLAY == ":0") then
  xmodmap -e "pointer = 1 7 3 2 8 6 4 5"

which apparently used to work for FC5 (or at least didn't break anything) but
now messes up FC6. 

So the issue is NOTABUG for me. Jim could you please see if you have any similar
pointer mods in your configuration?
Comment 6 Jim Hayward 2006-10-27 21:37:31 EDT
OK, that makes two of us. The mods were in .Xmodmap. I have no idea why. I don't
recall ever putting them there. They have probably been hanging around there for
years not causing any problems.

I always do a clean install, but I never format /home and I always use the same
user. It's not like I'm a new Linux either. I should have thought too look.

I'll go and hide my REALLY embarrassed self in the corner now. 
Comment 7 Thomas J. Baker 2006-10-27 22:05:40 EDT
Same thing with me. Clean installs with saved /home. Probably needed it in FC2
or something...

Note You need to log in before you can comment on or make changes to this bug.