Red Hat Bugzilla – Bug 115147
M$ intellimouse wheel does not scroll up in mozilla.
Last modified: 2007-11-30 17:10:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115
Description of problem:
When I use the mouse wheel to scroll down it works ok. If I try to
scroll up it does not work.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Use the wheel on the mouse to scroll down a page.
2.Try to use the wheel to scroll back up
Actual Results: when I try to scroll up I get the menu I would get if
I right clicked on the desktop.
Expected Results: It should scroll up
This mouse works fine with FC1 and previous versions of RHL.
One additional note: The scroll wheel appears to work normally in
things like konsole. I have only noticed this behavior in mozilla.
I have the exact same problem ... but for me (in GNOME) it happens in
Mozilla, on the desktop and in all other applications I tried in Gnome
(gedit, gterminal, etc.)
Also, it isn't just a right click ... it is a right click followed by
a center button click.
I have a logitech scroll optical mouse.
I have noticed the exact same behavior in Mandrake 10 RC1 and Debian
SID with a 2.6.x kernel.
Here is the applicable portion of my XF86Config file:
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mouse0"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "no"
One other thing that might be applicable ... my mouse is a USB mouse
that connects via a KVM switch.
More information ....
If the mouse is connected directly to the PS2 port ... and not through
the KVM switch, the mouse works correctly.
I currently have Fedora Core 1.90 kernel-2.6.3-1.97.
On any 2.4.x kernel, the mouse works correctly reguardless of whether
it is connected via the kvm switch or not.
My original switch is a Belkin Omniview SE 4-Port KVM switch.
I observe the same indications if using a Cybex AutoView Commander
8-Port KVM Switch...
More information and testing:
The problem is definately related to the KVM switch .....
When connected through the KVM switch, if the system is started while
on it's channel and the channel is never changed...the mouse works
like it is supposed to (in both Gnome and KDE and with all applications).
If I switch to another PC and then switch back to the Fedora Core
Machine via the KVM switch, that is when the error happens.
I switched with the mouse functioning properly in KDE and in Gnome.
I had a problem in both cases...when the prolem happens in GNOME, it
is how I posted before ... a right click followed by a center button
click for a scroll up of the mouse wheel ... when the problem happens
is KDE it is just a right click on the scroll up (not followed by a
center center click)
Unpluging the mouse from the KVM switch (and replugging it in) solves
the problem (ie removing power from the mouse)...but unpluging the KVM
switch mouse cable from the computer (with the mouse still recieving
power from the switch) does not fix the problem.
It made no difference wheter I used the CYBEX Autocommander 8 port or
the Belkin OmniView 4 port switch ... the results were identical and
always reproduceable (I did each test 4 times on each switch (on both
gnome and KDE).
I have a belken as well. I have this problem at home, and it's the
KVM - there's nothing that I know of that we can do. Alan had some
insight at one point into this, adding in case he has a comment but
I'm invoking my first strike right and closing this bug.
But I do not have a belkin KVM, and I reported the bug originally!!
Ignore it if you will but...
Also FWIW FC1 works just fine on this machine. IMO this has something
to do with FC2. I just wish I knew what. Besides I thought 2.6 was
supposed to work with a kvm.
There are two problems here
#1 the KVM case ("not supported") - Seems Belkin KVM doesn't speak
enough of the extended PS/2 protocol to reconfigure the mouse. I guess
its XFree86's fault as it should be able to interpret the "reconnect"
codes sent. But its not a supported setup
#2 Is the Tom Diehl one and looks like it may be a kernel or X thing.
Tom can you have a look at the wheel behaviour with "xev" and see what
event messages it prints when you use the wheel ?
OK ... I found a fix to my problem (I was using a Gentoo 2.6.3 kernel
with exactly the same problem...
I added this to the end of my kernel line in grub.conf:
I also changed the following line in my /etc/X11/XF86Config file:
Option "Protocol" "IMPS/2"
Option "Protocol" "ExplorerPS/2"
Now, I can change channels on the KVM switch and everything works
FWIW just changing my xorg.conf to use ExplorerPS/2 seems to have
resolved this problem for me.
I'm using a Logitech optical wireless mouse through an IOgear 4-port
KVM. This same config worked fine w/ IMPS/2 under FC1.
I also saw the same result as comment #9. I'm running Fedora Core 3,
and changed xorg.conf to use "ExplorerPS/2", CTRL+ALT+BACKSPACE, log
in to KDE, everything works normally now. I'm using a Linksys 4-port KVM.
Similar to #4 I get rid of the problem by unplugging the mouse. After
that I can switch back and forth with no mousewheel or nav-button
issues, but it woul dbe nice to see a solution that works from
startup. Running 2.6 Gentoo.
xorg upgrade 6.8.2 to 18.104.22.1682 brought this change:
buttons 6 and 7 now do the same thing than 4 and 5 in 6.8.2, and vice versa.
however, running commands
xmodmap -e "pointer = 1 2 3 6 7 4 5"
xmodmap -e "pointer = 1 2 3 4 5 6 7"
does not make any diff!
# rpm -qf /usr/bin/Xorg
# rpm -qf /usr/bin/xmodmap
Option "Protocol" "ExplorerPS/2"
Option "Device" "/dev/input/mice"
Option "Buttons" "7"
Option "ZAxisMapping" "6 7"
# Option "SendCoreEvents" "true"
I tried also evdev, did not work.
My problem seems to be fixed in 7.0.0 RC 3 (Fedora ships 7.0.0 RC 2).
The original problem was fixed. The last two comments are about a slightly
different from on either FC4 or a test release of FC5. This should be fixed in
FC5 and FC6, which are the only supported versions, and it does not seem to be a
security bug. Closing