Distribution: Gentoo Linux Hardware Environment: Using USB(uhci) for mouse on two computers (a desktop and a laptop) Software Environment: gcc-3.2.2, glibc-2.3.1, xfree86 4.3.0(desktop) & 4.3.99.901(laptop) Problem Description: When using kernel 2.6 and a Logitech MX500 optical mouse, it triggers a problem where the top scroll button (above the scroll wheel, intended for easy continuous scrolling) seems to send a signal for the top scroll button as well as the bottom side button. This problem does not occur when it was tested with 2.4.20 as well as on two different computers running Windows XP. Steps to reproduce: Using a Logitech MX500 mouse, edit XF86Config using the IMPS/2 protocol and using 7 Buttons with a ZAxisMapping of "4 5". When using the IMPS/2 protocol, the bottom side button acts as a middle mouse button and the the top side button acts as a right mouse button. Using a program that uses the middle mouse button and the scroll wheel at the same time (such as Galeon 1.3), click on the top scroll button. In Galeon 1.3, it will think that you have scrolled up as well as having clicked the middle mouse button (same as the bottom side button using the IMPS/2 protocol). You can also use the ExplorerPS/2 protocol with 7 Buttons and a ZAxisMapping of "6 7", run "xmodmap -e "pointer = 1 2 3 6 7 4 5"" in an xterm, create an .imwheelrc file with: "(null)" None, Up, J None, Down, M And then run "imwheel -k -b "67"" at an xterm, and when you press the bottom and top side buttons, it will actually type J and M, but when you use the top scroll button, it will think you have scrolled up as well as pressed that bottom side button.
Can you check with evtest?
I can acknowledge this problem with the Logitech MX700, evtest-output follows. Input driver version is 1.0.0 Input device ID: bus 0x3 vendor 0x46d product 0xc506 version 0x1600 Input device name: "Logitech USB Receiver" Supported events: Event type 0 (Sync) Event code 0 (Sync) Event code 1 (Key) Event code 2 (Relative) Event code 17 (LED) 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 code 277 (ForwardBtn) Event code 278 (BackBtn) Event code 279 (?) Event code 280 (?) Event code 281 (?) Event code 282 (?) Event code 283 (?) Event code 284 (?) Event code 285 (?) Event code 286 (?) Event code 287 (?) Event type 2 (Relative) Event code 0 (X) Event code 1 (Y) Event code 8 (Wheel) Event type 17 (LED) Event code 10 (?) Testing ... (interrupt to exit) Event: time 1073912132.602297, type 1 (Key), code 278 (BackBtn), value 1 Event: time 1073912132.602310, -------------- Config Sync ------------ Event: time 1073912132.618287, type 2 (Relative), code 8 (Wheel), value 1 Event: time 1073912132.618301, -------------- Config Sync ------------ Event: time 1073912132.698279, type 1 (Key), code 278 (BackBtn), value 0 Event: time 1073912132.698294, -------------- Config Sync ------------ Event: time 1073912134.417993, type 1 (Key), code 279 (?), value 1 Event: time 1073912134.418006, -------------- Config Sync ------------ Event: time 1073912134.433982, type 2 (Relative), code 8 (Wheel), value -1 Event: time 1073912134.433995, -------------- Config Sync ------------ Event: time 1073912134.473983, type 1 (Key), code 279 (?), value 0 Event: time 1073912134.473993, -------------- Config Sync ------------ He seems to accompany the events with wrong ones in both cases. The only difference is that code 278 is mapped by default to the middle button and 279 is meaningless, so it appears to work fine. Kernel 2.6.1-mm2, gentoo Linux. Problem existed already in the 2.6-test-Kernels - tell me if you need any other assistance.
Still present 8 months later in 2.6.8.1 :)
I'm also experiencing this problem with a Logitech MX510 using Fedora Core 3's kernel tree and with 2.6.10-rc3. Can anyone say one way or another whether this problem actually originates with the kernel input layer? I've seen it go away using Debian's evdev patches to Xfree86, which allow the use of evdev as a protocol. I've added to a similar bug report at freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=1947 I'd like to open a more specific bug there, but I haven't the experience to determine where this originates and report to the appropriate bugzilla.
Just upgraded to an MX1000. Same issue. This bug's now over a year old. This bug is sometimes not seen by users, because a odd (and wrong) X configuration causes these mouse buttons to be discarded. This works because on the MX500, MX510, and MX700 put these buttons as the last buttons on the mouse. There is no such hack to fix the MX1000, as there are additional buttons after the cruise control. Please increase severity, as newer hardware has no workaround. Please retitle bug "Logitech MX500,MX510,MX700,MX1000 mice send signal for another button when pressing a button" to reflect the wider scope of this bug.
Using kernel v2.6.12.2 (vanilla patched with fbsplash) I own a Logitech MX700 (duo with the keyboard) and the cruise buttons, witch are button 7 and button 8, give a 2 button events when pressed. Here is xev's ouput for cruise up (button 7): ButtonPress event, serial 31, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2053452, (171,12), root:(1398,30), state 0x10, button 7, same_screen YES ButtonPress event, serial 31, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2053468, (171,12), root:(1398,30), state 0x10, button 4, same_screen YES ButtonRelease event, serial 31, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2053468, (171,12), root:(1398,30), state 0x810, button 4, same_screen YES ButtonRelease event, serial 31, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2053540, (171,12), root:(1398,30), state 0x10, button 7, same_screen YES ButtonPress event, serial 31, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2054324, (171,12), root:(1398,30), state 0x10, button 7, same_screen YES ButtonPress event, serial 31, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2054340, (171,12), root:(1398,30), state 0x10, button 4, same_screen YES ButtonRelease event, serial 31, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2054340, (171,12), root:(1398,30), state 0x810, button 4, same_screen YES ButtonRelease event, serial 31, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2054439, (171,12), root:(1398,30), state 0x10, button 7, same_screen YES And xev's output for cruise down (button 8): ButtonPress event, serial 28, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2108419, (160,9), root:(1387,27), state 0x10, button 8, same_screen YES ButtonPress event, serial 28, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2108438, (160,9), root:(1387,27), state 0x10, button 5, same_screen YES ButtonRelease event, serial 28, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2108438, (160,9), root:(1387,27), state 0x1010, button 5, same_screen YES ButtonRelease event, serial 28, synthetic NO, window 0x1a00001, root 0x60, subw 0x0, time 2108540, (160,9), root:(1387,27), state 0x10, button 8, same_screen YES
See also the corresponding xorg filing: https://bugs.freedesktop.org/show_bug.cgi?id=3696 Whether this needs to be fixed in the kernel or in userspace.... I dunno.
The mx700 and m1000 mice generate these events in hardware. There is nothing to be fixed in software. The cruise control can be disabled by some tool that reprograms the mouse, unfortunately I don't remember the name.
Cross-posted to http://bugzilla.kernel.org/show_bug.cgi?id=1786 and https://bugs.freedesktop.org/show_bug.cgi?id=3696 logitech_applet ( http://freshmeat.net/projects/logitech_applet/ ) and more recently lmctrl ( http://freshmeat.net/projects/lmctl/ ) will disable the cruise-control, leaving only the regular button presses. Unfortunately they do this by disabling one of the key features of these mice, the cruise control. The way the mouse is designed to work, the way it's advertised, and the way it functions under Windows and OSX is for the cruise control buttons to not function as buttons, but only as the repeating scroll wheel events. It is possible through special options to remap them under Windows and OSX to function as seperate buttons, but this is a non-standard configuration. Whether done in kernel-space or user space, one or the other must be configured, not both. Given that the default in the non-linux world is to have repeated scroll events without an extra button, I suggest that this should be the default configuration under linux. AFAICT, the only way to do this is to allow the hardware to continue sending signals for the extra button press, but cause them to be ignored on some level. My attempts to do this at a XFree86 and Xorg application level have only resulted on both the button and cruise-control events being ignored together, so as best as I can tell, the solution must be to filter the button press at the X driver level or at the linux driver level. If this means a hack/work-around for oddly behaving hardware, so be it. Either that, or we disable the cruise-control by standard, and introduce some kind of radical new infrastructure to communicate that certain buttons (11 and 12 in this case) are associated with a particular function, and need auto-repeat emulated in user-space somewhere. As appealing as this idea is to me, it'll require somebody taking a serious leadership role and significant re-working of code to get all the widget environtments to talk the same language. In lieu of that, a workaround at the kernel/X driver level is the easiest cleanest solution I can personally think of. If anybody else has any other suggestions on how to get these devices working properly after a year and a half, I'm all ears.
I've had some minor problems since buying a logitech mouse and keyboard last year. The keyboard, a Logitech Internet Navigator Keyboard, is reported here: http://bugzilla.kernel.org/show_bug.cgi?id=2340 I had it mostly sorted out via the the hack i posted with that bug report. I've since given up as it's a major pain in the ass. The keyboard is now plugged into a usb port, and since it has a mouse-style wheel, a few or more of the convenience keys are taken as mouse button presses. I use it as having 105 keys. I also have a Logitech MX 510, as i mentioned earlier herein in comment #4. I've had some success with the Xorg project's evdev_drv. It's an input driver for X that uses the event devices. Some information about it is here: https://bugs.freedesktop.org/show_bug.cgi?id=968 Using the tarball and patches there, plus (of course) a hack, i've managed to get all buttons producing events under X and probably at a console, though i haven't really checked at a console. A src.rpm for Fedora Core 4 and some patches are here: http://straw.sh.nu/evdev_drv/ There's a patch to update the tarball attached to bug #968 at freedesktop.org to what's currently in cvs there. The next release of Xorg will likely include the evdev driver. The other two button-hack patches limit the number of buttons available to the the mouse. The evdev-ten-button-hack.patch eliminates the spurious button press event i was seeing using the foremost smartscroll (cruise control) button. This button was reporting both 4 and 11 under X. Since the MX-510 appears to have ten buttons, i luckily avoid the spurious button event. The other patch, the evdev-twelve-button-hack.patch is for a friend on irc. I'm uncertain as to whether it has the same effect. It's an insanely simple hack, so folks can experiment i guess. evdev-Xfuncproto-is-stale.patch might need applying as well. Also at http://straw.sh.nu/evdev_drv/ are a udev rule to allow a symlink, /dev/mouse, to which ever event device my mouse is assigned. Again, this can be adjusted to preference. usbmouse and usbmouse.usermap are an attempt to allow a user or group to own certain values in /proc, since kde supports the mice to an extent and needs this. lmctl, logitech_applet, and a kernel parameter (psmouse.smartscroll=) allow toggling of the smartscroll (cruise control) buttons. I've patched lmctl here: http://straw.sh.nu/evdev_drv/lmctl-add-MX510.patch to add my mouse. It's very simple to add more. Last I checked, either way (smartscroll enabled or not) had no effect on whether one or both of the smartscroll buttons produced a spurious event. I'll double check this in the next few days. I also have some event logs: http://straw.sh.nu/evdev_drv/evtest.log and http://straw.sh.nu/evdev_drv/input-event.log
So, is this really a kernel issue? Or can I just close this thing?
From what i and others can gather, X is introducing the extraneous button events on these mice. The event logs I posted in comment #10 seem to support this. Also, a recent patch against Xorg's new evdev driver introduces a spurious event (when pressing one of the cruise control buttons) where there wasn't one prior to the patch. I have no objections to closing this bug and encouraging folks to comment on existing X bugs that cover this problem.
I'm not sure how that's indicated. My evtest shows the following on a scroll-down event: > Event: time 1124761381.573535, type 2 (Relative), code 8 (Wheel), value -1 > Event: time 1124761381.573551, type 0 (Reset), code 0 (Reset), value 0 The following on a CC-down-press event: > Event: time 1124761383.709189, type 1 (Key), code 279 (?), value 1 > Event: time 1124761383.709208, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1124761383.733187, type 2 (Relative), code 8 (Wheel), value -1 > Event: time 1124761383.733204, type 0 (Reset), code 0 (Reset), value 0 (followed by wheel Relative and Reset events repeating as the button's held) and the following on the CC-down-release: > Event: time 1124761384.077114, type 1 (Key), code 279 (?), value 0 > Event: time 1124761384.077130, type 0 (Reset), code 0 (Reset), value 0 When the cruise-control is disabled via lmctl, there are no button events. The extra button events appear without talking to X. This is all being tested on my MX1000 mouse. If i'm misinterpreting this somehow, I apologise, and look forward to being corrected. :)
Pardon me, folks. Having learned how evtest actually works (you can press buttons!), I've got the same behaviour with a Logitech MX-510.
> comment #13 I think this is another bug of the kernel. Recent logitech keyboards have strange mappings for keyboards and mice. And I write a patch to fix this mapping. This also supresses doubled events like your post. Please look at: #5048 This patch only works for corldless desktop lx500. As button mappings and device id must be different between you and me. Please add your device id entry and edit extra mappings.
No response in 2 months, closing. If this is still a problem, please reopen with the requested information.
Definately still an issue here. Precisely what additional information would be helpful? I'm not sure what exactly was requested in the previous comment, or how best to get it?
Dmitry, what do you need from the users here? Anything anyone else can help out with?
It looks like to support that smart scrolling as is HID driver would have to postpone reporting BackBtn and TaskBtn until some kind of timeout has passed (so we either report these or repeated scroll events) and I am not keen on doing this... What king of events do these mice generate when cruise control is disabled (lmctl)?
7On mine (MX1000) with CC disabled, it just produces normal button presses, in X.org, interpreted as buttons 11 and 12. These are button events which, when CC is enabled, are superfluous. With CC disabled, evtest gives the following output, for each mouse button in order. The only difference when CC is enabled with lmctl is that each CC up/down event is accompanied by a Wheel up/down event, which, after a delay, is auto-repeated as long as the CC up/down button is held. This is all under 2.6.15-rc6, without any special patches: > Left button: > Event: time 1141688220.633603, type 1 (Key), code 272 (LeftBtn), value 1 > Event: time 1141688220.633620, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688220.745181, type 1 (Key), code 272 (LeftBtn), value 0 > Event: time 1141688220.745199, type 0 (Reset), code 0 (Reset), value 0 > > Middle button: > Event: time 1141688221.537458, type 1 (Key), code 274 (MiddleBtn), value 1 > Event: time 1141688221.537473, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688221.705434, type 1 (Key), code 274 (MiddleBtn), value 0 > Event: time 1141688221.705449, type 0 (Reset), code 0 (Reset), value 0 > > Right button: > Event: time 1141688222.353325, type 1 (Key), code 273 (RightBtn), value 1 > Event: time 1141688222.353340, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688222.505297, type 1 (Key), code 273 (RightBtn), value 0 > Event: time 1141688222.505311, type 0 (Reset), code 0 (Reset), value 0 > > Scroll up: > Event: time 1141688225.000901, type 2 (Relative), code 8 (Wheel), value 1 > Event: time 1141688225.000913, type 0 (Reset), code 0 (Reset), value 0 > > Scroll down: > Event: time 1141688226.608633, type 2 (Relative), code 8 (Wheel), value -1 > Event: time 1141688226.608644, type 0 (Reset), code 0 (Reset), value 0 > > Tilt left: > Event: time 1141688229.200224, type 1 (Key), code 280 (?), value 1 > Event: time 1141688229.200231, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688229.296214, type 1 (Key), code 280 (?), value 0 > Event: time 1141688229.296226, type 0 (Reset), code 0 (Reset), value 0 > > Tilt right: > Event: time 1141688229.920108, type 1 (Key), code 281 (?), value 1 > Event: time 1141688229.920116, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688230.024091, type 1 (Key), code 281 (?), value 0 > Event: time 1141688230.024097, type 0 (Reset), code 0 (Reset), value 0 > > Back side button (aka "Back"): > Event: time 1141688234.423366, type 1 (Key), code 275 (SideBtn), value 1 > Event: time 1141688234.423380, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688234.543352, type 1 (Key), code 275 (SideBtn), value 0 > Event: time 1141688234.543369, type 0 (Reset), code 0 (Reset), value 0 > > Middle side button (aka "app switch"): > Event: time 1141688235.303229, type 1 (Key), code 277 (ForwardBtn), value 1 > Event: time 1141688235.303242, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688235.439214, type 1 (Key), code 277 (ForwardBtn), value 0 > Event: time 1141688235.439228, type 0 (Reset), code 0 (Reset), value 0 > > Front side button (aka "Forward"): > Event: time 1141688236.231081, type 1 (Key), code 276 (ExtraBtn), value 1 > Event: time 1141688236.231095, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688236.367063, type 1 (Key), code 276 (ExtraBtn), value 0 > Event: time 1141688236.367082, type 0 (Reset), code 0 (Reset), value 0 > > Cruise-control Up: > Event: time 1141688237.862818, type 1 (Key), code 278 (BackBtn), value 1 > Event: time 1141688237.862834, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688238.014792, type 1 (Key), code 278 (BackBtn), value 0 > Event: time 1141688238.014806, type 0 (Reset), code 0 (Reset), value 0 > > Cruise-control Down: > Event: time 1141688238.742670, type 1 (Key), code 279 (?), value 1 > Event: time 1141688238.742683, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1141688238.886654, type 1 (Key), code 279 (?), value 0 > Event: time 1141688238.886672, type 0 (Reset), code 0 (Reset), value 0
I can also verify that the extraneous CC events remain. It's worth noting that lmctl has been forked to http://lomoco.linux-gamers.net/ . Also, see comment #2 from http://bugzilla.kernel.org/show_bug.cgi?id=5408 (mentioned herein with the wrong bug number (5048) in comment #13) which includes an attempted fix for the superfluous button events. I've not had the chance to test the patch, though. This is with a Logitech MX510.
Also have the same problem with Logitech MX510 mouse and kernel 2.6.16.5 Mouse work well with 2.4.26 kernel. XFree86 4.3.0, AMD64 (x86 mode) Section from XF86Config-4 Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "ExplorerPS/2" Option "Buttons" "7" Option "Resolution" "800" Option "Device" "/dev/psmouse" Option "ZAxisMapping" "6 7" Option "Emulate3Buttons" "off" EndSection
P.S. I connect MX510 to USB 2.0 port and to PS/2 port throw USB-to-PS/2 connector and problem remains.
Also i have problem with "back" button on left side of MX510 mouse. This button's normally behavior is to navigate back in browser. Under kernel 2.4.26 and Windows XP it works normally, but with 2.6.16.5 kernel it also sends event of a middle button (paste). One more problem with MX510 mouse in 2.6.16.5 kernel is with scrool wheel. scrool-down sends event as a scrool-down, but scrool-up sends event as Mouse5 button (it can be seen in Quake3 under Linux)
Please open a seperate bug if your issue isn't with the cruise-control buttons producing an extraneous button press.
Still in 2.6.18. Affects both Xorg's mouse and evdev drivers. Still no easy or completely effective workaround.
Any update on this bug? Thanks.
Closing the bug, hoping the issue has been fixed in later kernels. Please reopen if this is not the case.
Confirmed still present with the MX1000 in 2.6.24, please reopen.
Confirmed still present with 2.6.27. Can somebody please update the version, or rig my account with such powers as for me to periodically poke this bug every year or so? :)
This behavior persists in 2.6.31, with evdev 2.2.5. Here's an annotated evtest output, with my MX1000. Filing also exists with freedesktop xorg at https://bugs.freedesktop.org/show_bug.cgi?id=5578 Clicking the cruise-control-up button produces the following, where it should be a press and release of the Up wheel button: Event: time 1268026127.353861, type 4 (Misc), code 4 (ScanCode), value 90007 Event: time 1268026127.353882, type 1 (Key), code 278 (BackBtn), value 1 Event: time 1268026127.353896, -------------- Report Sync ------------ Event: time 1268026127.369838, type 2 (Relative), code 8 (Wheel), value 1 Event: time 1268026127.369858, -------------- Report Sync ------------ Event: time 1268026127.465861, type 4 (Misc), code 4 (ScanCode), value 90007 Event: time 1268026127.465878, type 1 (Key), code 278 (BackBtn), value 0 Event: time 1268026127.465890, -------------- Report Sync ------------ Clicking the cruise-control-down button produces the following, where it should be a press and release of the Up wheel button: Event: time 1268026129.377860, type 4 (Misc), code 4 (ScanCode), value 90008 Event: time 1268026129.377882, type 1 (Key), code 279 (TaskBtn), value 1 Event: time 1268026129.377896, -------------- Report Sync ------------ Event: time 1268026129.401829, type 2 (Relative), code 8 (Wheel), value -1 Event: time 1268026129.401850, -------------- Report Sync ------------ Event: time 1268026129.537856, type 4 (Misc), code 4 (ScanCode), value 90008 Event: time 1268026129.537876, type 1 (Key), code 279 (TaskBtn), value 0 Event: time 1268026129.537888, -------------- Report Sync ------------ Clicking the wheel-left-tilt produces the following, where it should be a press and release of the left wheel button: Event: time 1268026131.521867, type 4 (Misc), code 4 (ScanCode), value 90009 Event: time 1268026131.521887, type 1 (Key), code 280 (?), value 1 Event: time 1268026131.521893, -------------- Report Sync ------------ Event: time 1268026131.537833, type 2 (Relative), code 6 (HWheel), value -1 Event: time 1268026131.537855, -------------- Report Sync ------------ Event: time 1268026131.609851, type 4 (Misc), code 4 (ScanCode), value 90009 Event: time 1268026131.609867, type 1 (Key), code 280 (?), value 0 Event: time 1268026131.609872, -------------- Report Sync ------------ Clicking the wheel-right-tilt produces the following, where it should be a press and release of the right wheel button: Event: time 1268026132.777866, type 4 (Misc), code 4 (ScanCode), value 9000a Event: time 1268026132.777883, type 1 (Key), code 281 (?), value 1 Event: time 1268026132.777888, -------------- Report Sync ------------ Event: time 1268026132.801849, type 2 (Relative), code 6 (HWheel), value 1 Event: time 1268026132.801871, -------------- Report Sync ------------ Event: time 1268026132.881868, type 4 (Misc), code 4 (ScanCode), value 9000a Event: time 1268026132.881887, type 1 (Key), code 281 (?), value 0 Event: time 1268026132.881891, -------------- Report Sync ------------ Note that each button press has a correct Wheel or HWheel event in between the incorrect press/release buttons for the secondary event. Note also that holding the button down will correctly repeat the respective Wheel or HWheel event.
Still reported in evtest under 2.6.35.
To reiterate, since there's no workaround for this entire family of devices.... This bug should be titled "Logitech MX500,MX510,MX700,MX1000 mouse family sends signal for another button when pressing a button". It should also have its version field updated. Natalie/Dmitry/Anybody-else: Do you have any suggestions about how we can proceed to address this?
To be extra extra clear, this doesn't just affect "cruise control". It also effects the horizontal "tilt" scroll where present in hardware (because horizontal-tilt is handled the same way as the CC buttons), so it's not just extraneous features that are broken, and it's not anything that can be fixed by tools like lomoco.
This bug relates to a very old kernel. Closing as obsolete.