Bug 5256

horizontal axis, sorry for the misspelling

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"
EndSection

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.

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.

Filed my similar  if slightly different issues under
https://bugs.freedesktop.org/show_bug.cgi?id=5578

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?

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.

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.

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.

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.