The above mice (and quite possibly more) feature "Cruise Control" buttons, which, when pressed, produce a the affect of continuously operating the scroll wheel, or scrolling in minimum increments when clicked without holding. Given that the CC buttons are actually functional buttons, they also produce a second button press/raise as if they were a completely seperate usable button. Some people actually prefer to use it this way, and utilities exist ( http://freshmeat.net/projects/logitech_applet/ and http://www.bedroomlan.org/~alexios/coding_lmctl.html ) which can disable the cruise-control feature without disabling the regular button press. Unfortunately, no such option exists to disable the regular button press without disabling the cruise control function. IMHO, the CC configuration that logitech_applet and lmctl have, plus the ability to disable the regular presses that I would want, would ideally exist and be accessable from xorg.conf. Regardless of whether or not this option is available, the standard/default configuration should not generate these spurious button presses. (Such button presses can be observed causing problems most easilly by attempting to use the cruise control and dragging over text simultaneously in a mozilla/galeon/firefox window, where the text will be selected.) Note: This problem is often not reported by users of the MX500, MX510, and MX700 because a not-entirely-correct configuration can result in the cruise-control buttons, which are the last buttons indexed by the hardware being cut off when the # of buttons is configured artificially low. While this hack works with these mices, it does not work with the MX1000, because it has additional buttons *after* the cruise control.
Further discussion of this issue can be found in a thread here: http://lkml.org/lkml/2005/1/5/126 The relevant post by Vojtech Pavlik can be found here: http://lkml.org/lkml/2005/3/8/250
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.
Original contents lost in bugzilla disk death. xorg-team archives show: Summary: Cruise-control produces extra button presses on MX500,MX510,MX700, and MX1000. Product: xorg Version: 6.8.2 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Input/Mouse AssignedTo: xorg-team at lists.x.org ReportedBy: atrus at bugs.freedesktop.spam.rifetech.com The above mice (and quite possibly more) feature "Cruise Control" buttons, which, when pressed, produce a the affect of continuously operating the scroll wheel, or scrolling in minimum increments when clicked without holding. Given that the CC buttons are actually functional buttons, they also produce a second button press/raise as if they were a completely seperate usable button. Some people actually prefer to use it this way, and utilities exist ( http://freshmeat.net/projects/logitech_applet/ and http://www.bedroomlan.org/~alexios/coding_lmctl.html ) which can disable the cruise-control feature without disabling the regular button press. Unfortunately, no such option exists to disable the regular button press without disabling the cruise control function. IMHO, the CC configuration that logitech_applet and lmctl have, plus the ability to disable the regular presses that I would want, would ideally exist and be accessable from xorg.conf. Regardless of whether or not this option is available, the standard/default configuration should not generate these spurious button presses. (Such button presses can be observed causing problems most easilly by attempting to use the cruise control and dragging over text simultaneously in a mozilla/galeon/firefox window, where the text will be selected.) Note: This problem is often not reported by users of the MX500, MX510, and MX700 because a not-entirely-correct configuration can result in the cruise-control buttons, which are the last buttons indexed by the hardware being cut off when the # of buttons is configured artificially low. While this hack works with these mices, it does not work with the MX1000, because it has additional buttons *after* the cruise control. ------- Additional Comments From atrus at bugs.freedesktop.spam.rifetech.com 2005-07-03 21:10 ------- Further discussion of this issue can be found in a thread here: http://lkml.org/lkml/2005/1/5/126 The relevant post by Vojtech Pavlik can be found here: http://lkml.org/lkml/2005/3/8/250
Can anyone for whom the 7.1 evdev rewrite works confirm/deny if this bug is still present? (It's just segfaulting for me here).
Yea the problem is still in the latest CVS. The mouse really sends two button events, and evdev relays them.. I guess evdev is stuck with having a special case for that mouse...
Created attachment 7749 [details] [review] Proof-of-concept fix for Logitech Devices - PROBABLY ONLY WORKS WITH LX7 MOUSE I'm using the evdev-1.1.2 and a Logitech LX7 mouse. Using the default config (no extra xorg Options), I had the two problems expressed by others: 1) When using horizontal scroll (cruise control) left fires an extra button 11 event and right fires an extra button 12 event. 2) left/right scrolling is reversed (left fires button 7, right fires button 6) When I add 'Option "HWHEELRelativeAxisButtons" "7 6"' to my xorg.conf: 1) Button 11/12 are still fired 2) Horizontal scrolling almost works. The initial scroll is still wrong (7 for left and 6 for right), but then the repeated events are correct (6 left, 7 right). I believe the problem lies in the "fake button" approach of EvdevBtnCalcRemap(). When the user starts a horizontal scroll (say left), EvdevReadInput() immediately sees two events: a button press and a relative axis movement. In EvdevBtnProcess(), the button press is 6, but gets mapped into 11 by "button = state->btn->map[button]". If the remapping never happened, and map[6] = 6, then it would work fine. A similar case would hold for button 7. Therefore, I've attached a proof-of-concept patch (logitech_fix.patch) that fixes the problem for me. It probably won't work for mice other than the LX7, but I don't know enough about the code to make a more general patch. For me, it fixes both problems 1 and 2. I have no idea why this simple patch also fixes #2 (wrong initial scroll), but it does. I hope the maintainer of the evdev module can use this information to make a more general solution. If you need more information, please ask.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
evdev has seen a fair amount of changes recently, and I guess the change you proposed should be in as far as I interpret it. Can you please test with evdev 2.0.1 and check if the problem persists. If it does, I'm happy to accept patches for 2.1.
Lack of feedback from reporter - INVALID.
Still present in xorg evdev 2.6.0 (as packaged in Ubuntu Oneric).
This hasn't seen any attention in over 5 years, let's not pretend we'll fix this.
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.