Description of problem: Noticed that scrolling up on my mousewheel was causing strange behaviour in Firefox, I initially assumed xorg, but also investigated firefox. After exhausting configuration options in Firefox, I went back to xorg and discovered the problem, and a quick hack that works for me. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.4.99.901-22.20080415.fc9.i386 How reproducible: Always xorg.conf: Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "IMPS/2" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection xev output when scrolling up on the mousewheel one click: ButtonPress event, serial 32, synthetic NO, window 0x2800001, root 0x56, subw 0x0, time 10177073, (96,128), root:(97,849), state 0x0, button 4, same_screen YES ButtonRelease event, serial 32, synthetic NO, window 0x2800001, root 0x56, subw 0x0, time 10177073, (96,128), root:(97,849), state 0x800, button 4, same_screen YES ButtonPress event, serial 32, synthetic NO, window 0x2800001, root 0x56, subw 0x0, time 10177073, (96,128), root:(97,849), state 0x0, button 8, same_screen YES ButtonPress event, serial 32, synthetic NO, window 0x2800001, root 0x56, subw 0x0, time 10177073, (96,128), root:(97,849), state 0x0, button 9, same_screen YES ButtonRelease event, serial 32, synthetic NO, window 0x2800001, root 0x56, subw 0x0, time 10178254, (96,128), root:(97,849), state 0x0, button 8, same_screen YES ButtonRelease event, serial 32, synthetic NO, window 0x2800001, root 0x56, subw 0x0, time 10178254, (96,128), root:(97,849), state 0x0, button 9, same_screen YES Workaround: echo "pointer = 1 2 3 4 5 8 9 6 7" > ~/.Xmodmap By swapping buttons 6/7 for 8/9 using Xmodmap I was able to get the mousewheel to generate the 6/7 button press events instead of 8/9 which was causing strange Forward/Back behaviour in Firefox.
For me, the wheel was not recognized at all until is added the kernel (cmdline) parameter: psmouse.proto=imps
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
yikes. this looks like a broken mouse. buttons 6/7 are assigned to the hwheel, and ff takes 8/9 to be default for forward/back IIRC. so you essentially create a number of left/right scroll events now. anyway, these button events shouldn't happen in the first place when you scroll the wheel. what mouse do you have? and can you attach a Xorg.log please, we can check if you're using evdev. If so, testing with the mouse driver gives us a better indication of whether the problem is driver, kernel or hardware..
current xev output: mwheel UP: ButtonPress event, serial 29, synthetic NO, window 0x3e00001, root 0x56, subw 0x0, time 392141624, (124,32), root:(125,578), state 0x10, button 4, same_screen YES ButtonRelease event, serial 29, synthetic NO, window 0x3e00001, root 0x56, subw 0x0, time 392141624, (124,32), root:(125,578), state 0x810, button 4, same_screen YES ButtonPress event, serial 29, synthetic NO, window 0x3e00001, root 0x56, subw 0x0, time 392141624, (124,32), root:(125,578), state 0x10, button 6, same_screen YES ButtonPress event, serial 29, synthetic NO, window 0x3e00001, root 0x56, subw 0x0, time 392141624, (124,32), root:(125,578), state 0x10, button 7, same_screen YES mwheeldown: ButtonPress event, serial 29, synthetic NO, window 0x3e00001, root 0x56, subw 0x0, time 392146416, (124,32), root:(125,578), state 0x10, button 5, same_screen YES ButtonRelease event, serial 29, synthetic NO, window 0x3e00001, root 0x56, subw 0x0, time 392146416, (124,32), root:(125,578), state 0x1010, button 5, same_screen YES ButtonRelease event, serial 29, synthetic NO, window 0x3e00001, root 0x56, subw 0x0, time 392146416, (124,32), root:(125,578), state 0x10, button 6, same_screen YES ButtonRelease event, serial 29, synthetic NO, window 0x3e00001, root 0x56, subw 0x0, time 392146416, (124,32), root:(125,578), state 0x10, button 7, same_screen YES
Created attachment 312056 [details] xorg configuration file
Created attachment 312057 [details] xorg log /var/log/Xorg.0.log
Mouse is a Logitech TrackMan Wheel p/n: 804360-1000 http://www.logitech.com/index.cfm/mice_pointers/trackballs/devices/166&cl=us,en Connected via PS2 through a DKVM-4K http://www.dlink.com/products/?model=dkvm-4k
do you see the same problem if connected directly? Please add Option "AutoAddDevices" "off" to your ServerLayout section. This way we ensure that the driver is the mouse driver instead of evdev. if the problem persists, it's below X. Otherwise, it's the driver.
Tried Option "AutoAddDevices" "off" and Option "AutoAddDevices" "False" Neither worked for me 100%, I think it fixed my ScrollDown but not my ScrollUp. Searched around, found mention of the issue being introduced in sometime after xf86-input-evdev-1.1.5-r2 (Gentoo) and being fixed by the time xf86-input-evdev-1.99.2 came out. http://bugs.gentoo.org/show_bug.cgi?id=199317 Don't know if this relates to Fedora 100% but hopefully gives you a lead on a solution.
hmm, didn't really see anything there, but most of it was caused by evdev-1.2 anyway. next step: please compile evtest [1] and run it on /dev/input/eventX (whatever your mouse is). you need to do so w/o the server running, and scroll the wheel up and down. don't press any other buttons to reduce the noise. Pipe the output into a file and attach it here. [1] http://game-sat.com/~brian/Howtos/evtest.c
One commenter of the Gentoo bug mentioned: "I think that problem lies in the order of so-called (honestly I don't know the internals of the driver, I was just looking around) axes. In case of "normal" mouse they go: "RelAxis", "AbsAxis", "Buttons", but in case of my mouse (Logitech Internet 1500 Laser Cordless Desktop - keyboard + mouse) they go: "AbsAxis", "RelAxis", ... This confuses the driver (probably some indexing issue)." It ended up being /dev/input/event2 not sure the entire output is useful, here are just the scroll up and down. Event: time 1216393352.968889, -------------- Report Sync ------------ Event: time 1216393353.479316, type 2 (Relative), code 8 (Wheel), value 1 Event: time 1216393353.479320, type 1 (Key), code 275 (SideBtn), value 1 Event: time 1216393353.479321, type 1 (Key), code 276 (ExtraBtn), value 1 Event: time 1216393353.479332, -------------- Report Sync ------------ Event: time 1216393354.418661, type 2 (Relative), code 8 (Wheel), value -1 Event: time 1216393354.418666, type 1 (Key), code 275 (SideBtn), value 0 Event: time 1216393354.418666, type 1 (Key), code 276 (ExtraBtn), value 0 Event: time 1216393354.418677, -------------- Report Sync ------------
And the header. Input driver version is 1.0.0 Input device ID: bus 0x11 vendor 0x2 product 0x6 version 0x4f Input device name: "ImExPS/2 Logitech TrackMan" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 272 (LeftBtn) Event code 273 (RightBtn) Event code 274 (MiddleBtn) Event code 275 (SideBtn) Event code 276 (ExtraBtn) Event type 2 (Relative) Event code 0 (X) Event code 1 (Y) Event code 6 (HWheel) Event code 8 (Wheel) Testing ... (interrupt to exit)
(In reply to comment #11) > One commenter of the Gentoo bug mentioned: > "I think that problem lies in the order of so-called (honestly I don't know the > internals of the driver, I was just looking around) axes. In case of "normal" > mouse they go: "RelAxis", "AbsAxis", "Buttons", but in case of my mouse > (Logitech Internet 1500 Laser Cordless Desktop - keyboard + mouse) they go: > "AbsAxis", "RelAxis", ... This confuses the driver (probably some indexing > issue)." may have been an evdev 1.2 issue, certainly not an issue with F9. > Event: time 1216393352.968889, -------------- Report Sync ------------ > Event: time 1216393353.479316, type 2 (Relative), code 8 (Wheel), value 1 > Event: time 1216393353.479320, type 1 (Key), code 275 (SideBtn), value 1 > Event: time 1216393353.479321, type 1 (Key), code 276 (ExtraBtn), value 1 > Event: time 1216393353.479332, -------------- Report Sync ------------ > Event: time 1216393354.418661, type 2 (Relative), code 8 (Wheel), value -1 > Event: time 1216393354.418666, type 1 (Key), code 275 (SideBtn), value 0 > Event: time 1216393354.418666, type 1 (Key), code 276 (ExtraBtn), value 0 > Event: time 1216393354.418677, -------------- Report Sync ------------ If you look at the evtest output, for each wheel press you also get button events for the two buttons. This is below X, so if you start X now, it will generate events for each button event on the device, leading to the strange behaviours you mentioned. your mouse is broken. Well, either that or the kernel screws it up. Reassigning to kernel.
Defective by design maybe, I have two of them, they both act the same. It has worked fine since FC3.
Just my $0.02 I have the same problem, I also have a DKVM-4K... I think the problem is the marriage between Linux and the DKVM. Let me first state that I am no Linux guru. I have however persistently bashed my head against this problem. Some system info: I am running Ubuntu, the problem has persisted since at least when I jumped onto the Linux train with Ubuntu 8.04 (released approx. 15-18 months ago) up to the present day 9.04. I have a Logitech EX110 (budget wireless) keyboard / mouse combo pugged in via the DKMV and then through to the PS/2 ports. So why do I believe that DKVM and Linux do not match well? Well, my observations are as follows: If I boot with the DKVM set to the ubuntu computer, there is nothing wrong! I get no bogus key-events what so ever. However, when the boot process is done while the DKVM-4K set to another computer (which is a quite natural thing to do, who wants to watch it boot?), I get bogus button 8 and 9 events when I switch back to the ubuntu computer and use the scroll wheel - which screws up my Firefox experience as they are mapped to the back button... I have no clue whats going on really. My speculation is that if the DKVM emulates the mouse while HAL does it setup instead of being passing all communications through to the acutal mouse, something goes wrong. Perhaps the HAL believes that it is a Microsoft mouse at the other end or something. xev tells me a similar story as the one I have seen here when the setup is wrong, but I get them in the following order: When I scroll downwards I get: button 5 press button 5 release button 5 press button 5 release ...etc... When I change direction and start scrolling upwards I get: button 4 press button 4 release button 8 press button 9 press button 4 press button 4 release button 4 press button 4 release ..etc... When I then change the direction again (down) I get: button 5 press button 5 release button 8 release button 9 release button 5 press button 5 release button 5 press button 5 release ..etc... The interesting part is that 8 and 9 are pressed when I change from down to up and released when I change back down again. I have done queries using xinput list-props on both the "ImExPS/2 Logitech Explorer mouse" and the "Macintosh mouse button emulation" and... nothing is different from a "wrong" detected state and a "correct" one. Anyway, this is as I said on an Ubuntu computer, but I seeing this I get the impression that it is perhaps something more fundamental than the distro. I hope this is useful to you. Cheers! / Daniel
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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 to the applicable version. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.