Bug 3696

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.