Logitech MX1000 mouse generating XF86Audio* keypress events

[Alan Briolat]

Binary package hint: xorg

Since Jaunty, I've found that my Logitech MX1000 wireless mouse generates key events for some mouse button clicks, rather than the expected button events. For example, when clicking the middle of the three buttons on the left side of the mouse (previously button 9) generates XF86AudioPlay KeyPress events. Here is the output from xev when I click the button:

-------------------------------------------------------------------------------------
KeyPress event, serial 30, synthetic NO, window 0x3e00001,
    root 0x13c, subw 0x0, time 3416337, (1,174), root:(1292,220),
    state 0x10, keycode 208 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XKeysymToKeycode returns keycode: 172
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x3e00001,
    root 0x13c, subw 0x0, time 3416497, (1,174), root:(1292,220),
    state 0x10, keycode 208 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XKeysymToKeycode returns keycode: 172
    XLookupString gives 0 bytes:
    XFilterEvent returns: False
-------------------------------------------------------------------------------------

When I press the *real* "play/pause" button, this is what I get (pretty much exactly the same!):
-------------------------------------------------------------------------------------
KeyPress event, serial 37, synthetic NO, window 0x1800001,
    root 0x13c, subw 0x0, time 3673352, (3,160), root:(1294,206),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x1800001,
    root 0x13c, subw 0x0, time 3673440, (3,160), root:(1294,206),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False
-------------------------------------------------------------------------------------

Also, the horizontal scrolling generates XF86AudioRaiseVolume and XF86AudioLowerVolume for left and right respectively. All other mouse buttons correctly generate ButtonPress events with the correct button numbers.

What's even more interesting is that I use xbindkeys to map my audio keys to mpc commands, and these events aren't caught by xbindkeys, but they are caught by GNOME's keyboard shortcut mechanism if I set something to use them there. I have no other mouse- or keyboard-mangling utilities installed.

I'm running a fresh install of Jaunty 64-bit with all updates applied. This bug was present in the beta, RC and final releases, but not in Intrepid.

If anybody knows of a way to trace where the mouse button event goes, let me know and I'll see what other information I can dig up!

[Alan Briolat (alan-codescape)]

I'm not sure when or why, but this problem seems to be fixed now...