Bug 443284 - mousewheel generating bogus button events
mousewheel generating bogus button events
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-20 03:12 EDT by Michael Best
Modified: 2009-07-14 14:04 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 14:04:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg configuration file (1.21 KB, text/plain)
2008-07-17 11:08 EDT, Michael Best
no flags Details
xorg log /var/log/Xorg.0.log (28.05 KB, text/plain)
2008-07-17 11:09 EDT, Michael Best
no flags Details

  None (edit)
Description Michael Best 2008-04-20 03:12:51 EDT
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.
Comment 1 Gene Czarcinski 2008-05-02 10:33:35 EDT
For me, the wheel was not recognized at all until is added the kernel (cmdline)
parameter:   psmouse.proto=imps
Comment 2 Bug Zapper 2008-05-14 05:46:00 EDT
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
Comment 3 Peter Hutterer 2008-07-16 20:36:51 EDT
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..
Comment 4 Michael Best 2008-07-17 11:07:53 EDT
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
Comment 5 Michael Best 2008-07-17 11:08:38 EDT
Created attachment 312056 [details]
xorg configuration file
Comment 6 Michael Best 2008-07-17 11:09:11 EDT
Created attachment 312057 [details]
xorg log  /var/log/Xorg.0.log
Comment 7 Michael Best 2008-07-17 11:12:44 EDT
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
Comment 8 Peter Hutterer 2008-07-17 20:14:33 EDT
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.
Comment 9 Michael Best 2008-07-17 23:20:32 EDT
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.
Comment 10 Peter Hutterer 2008-07-18 00:12:04 EDT
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
Comment 11 Michael Best 2008-07-18 11:05:12 EDT
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 ------------
Comment 12 Michael Best 2008-07-18 11:06:06 EDT
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)
Comment 13 Peter Hutterer 2008-07-20 20:00:03 EDT
(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.

Comment 14 Michael Best 2008-07-20 21:58:31 EDT
Defective by design maybe, I have two of them, they both act the same.  It has
worked fine since FC3.
Comment 15 Daniel 2009-05-18 17:08:54 EDT
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
Comment 16 Bug Zapper 2009-06-09 20:17:58 EDT
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
Comment 17 Bug Zapper 2009-07-14 14:04:30 EDT
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.

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