Debian

Bug #615892
Comment #13

Comment 13 for bug 615892

Revision history for this message

Mitch Walker (mitch-esolation) wrote on 2010-10-08:

#13

I just bought one of these mice (RAT7), and had the same problem. After a little digging online and with the system, I've tracked down the problem and have a permanent fix.

The real problem here is that the mouse has a "mode" button that changes modes by registering a button click WITHOUT SENDING A RELEASE. It's probably not a bug that the x server then sees every subsequent mouse click as a button combination, including the standard button 1 (left button) click.

You can see this for yourself by using the xinput tool.

On my model (7), repeatedly pressing the "mode" button (lighted, on the index finger guard) releases the previous button and presses the next one without release. In this way it loops through buttons 13, 14 and 15.

That is:

*click* press 13
*click* release 13, press 14
*click* release 14, press 15
*click* release 15, press 13
(repeat ad nauseum)

Apparently during part of the start-up process, the mouse sends its first press-without-release, and the server jams. HUP'ing the server is the only way to break this state.

The permanent fix to this problem is to configure X to ignore buttons 13, 14 and 15 (at least on the RAT7; use xinput to discover the problematic buttons on other models).

This can be also be done with xinput: Ex:

xinput --set-button-map <device_id> 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0 16 17 18 19 20 21

The number of buttons in that list and the position of the zeros (disabled buttons) depends on the model.

This fix is at least good for the session. I don't know if it "sticks" between boots. If it doesn't, you could add this remapping to your xorg.conf, like so:

Section "InputClass"
        Identifier "Mouse Remap"
        MatchProduct "Saitek Cyborg R.A.T.7 Mouse"
        MatchDevicePath "/dev/input/event*"
        Option "ButtonMapping" "1 2 3 4 5 6 7 2 9 10 11 12 0 0 0 16 17 18 19 20 21"
EndSection

Again, you may need to tweak these values depending on your model and X server version. Use xinput --list to get that product string.

Hope this helps someone.

I just bought one of these mice (RAT7), and had the same problem.  After a little digging online and with the system, I've tracked down the problem and have a permanent fix.

The real problem here is that the mouse has a "mode" button that changes modes by registering a button click WITHOUT SENDING A RELEASE.  It's probably not a bug that the x server then sees every subsequent mouse click as a button combination, including the standard button 1 (left button) click.

You can see this for yourself by using the xinput tool.

On my model (7), repeatedly pressing the "mode" button (lighted, on the index finger guard) releases the previous button and presses the next one without release.  In this way it loops through buttons 13, 14 and 15.

That is:

*click*  press 13
*click*  release 13, press 14
*click*  release 14, press 15
*click*  release 15, press 13
(repeat ad nauseum)

Apparently during part of the start-up process, the mouse sends its first press-without-release, and the server jams.  HUP'ing the server is the only way to break this state.

The permanent fix to this problem is to configure X to ignore buttons 13, 14 and 15 (at least on the RAT7; use xinput to discover the problematic buttons on other models).

This can be also be done with xinput:  Ex:

xinput --set-button-map <device_id> 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0 16 17 18 19 20 21

The number of buttons in that list and the position of the zeros (disabled buttons) depends on the model.

This fix is at least good for the session.  I don't know if it "sticks" between boots.  If it doesn't, you could add this remapping to your xorg.conf, like so:

Again, you may need to tweak these values depending on your model and X server version.  Use xinput --list to get that product string.

Hope this helps someone.