Bug 1786 - Logitech MX500 mouse sends signal for another button when pressing a button
Logitech MX500 mouse sends signal for another button when pressing a button
Status: RESOLVED OBSOLETE
Product: Drivers
Classification: Unclassified
Component: USB
i386 Linux
: P2 low
Assigned To: Dmitry Torokhov
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-04 12:25 UTC by Frank Green
Modified: 2015-02-19 15:03 UTC (History)
10 users (show)

See Also:
Kernel Version: 2.6.35
Tree: Mainline
Regression: Yes


Attachments

Description Frank Green 2004-01-04 12:25:15 UTC
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.
Comment 1 Vojtech Pavlik 2004-01-09 12:04:15 UTC
Can you check with evtest?
Comment 2 Hynek Schlawack 2004-01-12 05:14:46 UTC
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.
Comment 3 Jeremy Nickurak 2004-09-11 21:17:34 UTC
Still present 8 months later in 2.6.8.1 :)
Comment 4 Niko Mirthes 2004-12-04 16:17:51 UTC
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.
Comment 5 Jeremy Nickurak 2005-02-01 18:58:46 UTC
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.
Comment 6 Nicolas Bigaouette 2005-07-08 12:45:00 UTC
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

Comment 7 Jeremy Nickurak 2005-07-08 12:49:46 UTC
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.
Comment 8 Vojtech Pavlik 2005-07-08 14:14:19 UTC
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.
Comment 9 Jeremy Nickurak 2005-07-08 14:41:26 UTC
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.
Comment 10 Niko Mirthes 2005-07-09 16:49:43 UTC
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
Comment 11 Greg Kroah-Hartman 2005-08-18 16:22:55 UTC
So, is this really a kernel issue?  Or can I just close this thing?
Comment 12 Niko Mirthes 2005-08-22 14:17:06 UTC
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.
Comment 13 Jeremy Nickurak 2005-08-22 18:50:32 UTC
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. :)
Comment 14 Niko Mirthes 2005-08-22 19:25:02 UTC
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 15 Ryo Dairiki 2005-11-05 16:02:35 UTC
> 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.
Comment 16 Greg Kroah-Hartman 2006-03-06 10:35:01 UTC
No response in 2 months, closing.  If this is still a problem, please reopen
with the requested information.
Comment 17 Jeremy Nickurak 2006-03-06 11:19:26 UTC
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?
Comment 18 Greg Kroah-Hartman 2006-03-06 11:50:57 UTC
Dmitry, what do you need from the users here?  Anything anyone else can 
help out with?
Comment 19 Dmitry Torokhov 2006-03-06 13:57:36 UTC
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)? 
Comment 20 Jeremy Nickurak 2006-03-06 15:42:14 UTC
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
Comment 21 Niko Mirthes 2006-03-07 08:20:04 UTC
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. 
 
Comment 22 Eugene Seppel 2006-04-19 11:00:26 UTC
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
Comment 23 Eugene Seppel 2006-04-19 11:02:31 UTC
P.S.
I connect MX510 to USB 2.0 port and to PS/2 port throw USB-to-PS/2 connector and
problem remains.
Comment 24 Eugene Seppel 2006-04-19 11:15:19 UTC
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)
Comment 25 Jeremy Nickurak 2006-05-14 21:49:09 UTC
Please open a seperate bug if your issue isn't with the cruise-control buttons
producing an extraneous button press.
Comment 26 Jeremy Nickurak 2006-10-01 21:01:44 UTC
Still in 2.6.18. Affects both Xorg's mouse and evdev drivers.
Still no easy or completely effective workaround.
Comment 27 Natalie Protasevich 2007-09-04 00:56:55 UTC
Any update on this bug?
Thanks.
Comment 28 Natalie Protasevich 2008-03-03 16:44:48 UTC
Closing the bug, hoping the issue has been fixed in later kernels.
Please reopen if this is not the case.
Comment 29 Jeremy Nickurak 2008-03-03 18:08:12 UTC
Confirmed still present with the MX1000 in 2.6.24, please reopen.
Comment 30 Jeremy Nickurak 2008-11-09 19:52:30 UTC
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? :)
Comment 31 Jeremy Nickurak 2010-03-08 05:39:24 UTC
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.
Comment 32 Jeremy Nickurak 2011-01-16 04:01:42 UTC
Still reported in evtest under 2.6.35.
Comment 33 Jeremy Nickurak 2011-01-16 22:52:33 UTC
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?
Comment 34 Jeremy Nickurak 2011-01-16 23:01:13 UTC
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.
Comment 35 Alan 2015-02-19 15:03:36 UTC
This bug relates to a very old kernel. Closing as obsolete.

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