Bug 212446 - mouse scrolling events wrong
Summary: mouse scrolling events wrong
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-26 20:07 UTC by Thomas J. Baker
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-28 02:05:40 UTC
Type: ---
Embargoed:


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

Description Thomas J. Baker 2006-10-26 20:07:13 UTC
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
restored:

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


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):

xorg-x11-drv-mouse-1.1.1-1.1

Comment 1 Jim Hayward 2006-10-27 03:30:46 UTC
Created attachment 139550 [details]
Xorg.0.log

Comment 2 Jim Hayward 2006-10-27 03:33:31 UTC
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-27 03:46:31 UTC
Oops, sorry wrong Xorg.0.log.

Comment 4 Jim Hayward 2006-10-27 03:49:30 UTC
Created attachment 139551 [details]
The right Xorg.0.log

Comment 5 Thomas J. Baker 2006-10-27 22:24:01 UTC
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"
endif

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-28 01:37:31 UTC
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-28 02:05:40 UTC
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.