Bug 5256 - evdev after maps mouse to wrong keys
Summary: evdev after maps mouse to wrong keys
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: 6.9.0
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact:
Depends on:
Reported: 2005-12-07 12:48 UTC by Jason Holmes
Modified: 2006-03-16 05:02 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Jason Holmes 2005-12-07 12:48:04 UTC
I've been unable to get my mx-1000 mouse to configure correctly, using the same
configuration I had with  I'm currently using, and it isn't
using the horizontal access, it has them mapped to forward and backwords buttons.
Comment 1 Jason Holmes 2005-12-07 12:48:56 UTC
horizontal axis, sorry for the misspelling
Comment 2 Jeremy Nickurak 2006-01-12 17:26:23 UTC
On 6.9.0 here, but my MX1000's buttons map to keyboard events of 'l' and 'r' in
addition to the 6 and 7 mouse buttons.

My config:

Section "InputDevice"
        Identifier      "Mouse0"
        Driver          "evdev"
        Option              "SendCoreEvents"
        Option          "Device"                "/dev/input/event-mx1000"
        Option          "ZAxisMapping"  "4 5 7 6"
        Option          "ButtonMapping" "1 2 3 8 9 10 4 5 6 7"
Comment 3 Jason Holmes 2006-01-12 17:49:22 UTC
I've tried your configuration.  My horizontal wheel movements still map to
forward and back at least in firefox.  they also map to o and p keys
respectively, i'm upgrading to 6.9.0 right now to see if that fixes the problem.
Comment 4 Jeremy Nickurak 2006-01-13 16:49:18 UTC
Well that's kind of creepy. I had assumed that the 'r' and 'l' buttons were
meaningful, but if you're getting o and p, those just happen to be the keys that
are 'r' and 'l' under my dvork keyboard configuration.
Comment 5 Jeremy Nickurak 2006-01-13 16:52:32 UTC
Filed my similar  if slightly different issues under

My configuration used a bunch of extra options not supported my evdev. Removing
them gives me the same behavior. Are you using any extra evdev options or
xmodmap options at all Jason?
Comment 6 Jason Holmes 2006-01-13 18:41:39 UTC
no extra modmap or evdev options, i tried using your configuration, but to no
avail. also upgrading to 6.9.0 had no effect either.
Comment 7 Jason Holmes 2006-01-13 18:45:52 UTC
just for reference this is what xev reports when i click the horizontal scroll
button to the right.
ButtonRelease event, serial 32, synthetic NO, window 0x3a00001,
    root 0x66, subw 0x3a00002, time 4993582, (46,51), root:(798,591),
    state 0x10, button 7, same_screen YES

LeaveNotify event, serial 32, synthetic NO, window 0x3a00001,
    root 0x66, subw 0x0, time 4993582, (46,51), root:(798,591),
    mode NotifyUngrab, detail NotifyInferior, same_screen YES,
    focus YES, state 16

KeyRelease event, serial 32, synthetic NO, window 0x3a00001,
    root 0x66, subw 0x3a00002, time 4993942, (46,51), root:(798,591),
    state 0x10, keycode 33 (keysym 0x70, p), same_screen YES,
    XLookupString gives 1 bytes: (70) "p"

At some point in the 6.8.9 development tree evdev worked perfectly for my mouse.
 but i can't seem to figure out what portion of the evdev driver changed.
Comment 8 Zephaniah E. Hull 2006-02-16 10:54:41 UTC
The evdev driver in the modular tree was recently rewritten, enough so that this
bug likely no longer exists.

If you guys could please retest with the modular CVS evdev driver and let me
know if it is still an issue I'd appreciate it.

Thank you.
Comment 9 Zephaniah E. Hull 2006-03-17 00:02:22 UTC
As I can't reproduce this, and noone is saying that it's still around, I'm going
to close this now.

Please reopen if it happens again with the current code.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.