Madcatz Cyborg R.A.T. 7 focus issues

Bug #615892 reported by Michael Graessle on 2010-08-10
This bug affects 61 people
Affects Status Importance Assigned to Milestone
xorg (Fedora)
xserver-xorg-input-evdev (Ubuntu)
Nominated for Maverick by Michael Graessle

Bug Description

Binary package hint: xorg

When using the Madcatz Cyborg R.A.T. 7 mouse, Xorg will lock the focus to a single window.

The mouse continues to work but all events continue to go to the active window, even when the action is outside the active window.

This affects all mice on the system until you unhook the R.A.T. 7. Sometimes clicking the mouse's "Mode" button while over another application will also fix the issue.

I've seen this bug using TWM,Metacity and Compiz

This also seems to be an issue on Fedora 13, but is fixed in Xorg git as of 2010.08.09. I've replicated the bug in 10.04 and 10.10 alpha 3.

I've attached evtest-capture and Xorg.log logs (from fedora 13)
Architecture: i386
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100318)
Package: xorg 1:7.5+5ubuntu1
PackageArchitecture: i386
 PATH=(custom, user)
Tags: lucid
Uname: Linux 2.6.35 i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.35

Bryce Harrington (bryce) wrote :

Hi Michael,

        Please run the command 'apport-collect BUGNUMBER', which will attach several files we need for debugging.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-xorglog
tags: added: needs-lspci-vvnn
Changed in xorg (Ubuntu):
status: New → Incomplete

apport information

tags: added: apport-collected
description: updated

apport information

Bryce Harrington (bryce) on 2010-08-12
affects: xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)

I should note that this bug shows up on non-intel hardware was well.

Bryce Harrington (bryce) on 2010-08-12
tags: added: lucid
Bryce Harrington (bryce) on 2010-08-13
tags: removed: needs-xorglog
tags: removed: needs-lspci-vvnn
Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Confirmed
Jm8thew (jm8thew) wrote :

I'd like to note that I am affected by this issue as well. However I did find a work around on my system (mint 9, ubuntu 10.04).

Right after the symptoms begin to pop up and my computer freezes except for the one window, I press ctrl alt backspace, drop back into log in screen, log back in, and usually the mouse works fine after this. If i disconnect and reconnect the mouse, the issue returns. Also, as I recall (it's been awhile since I tried to fix it myself) if I fiddle with the mouse settings using xinput the issue returns again.

Matt Needes (mneedes-q) wrote :

The workaround also works for me on Mint 8 !
jm8thew, THANKS A LOT for sharing the workaround !

Ryan Waters (nikitis) wrote :

I was the original poster of this issue on the ubuntu forums. I can confirm this bug on many distributions, as well as KDE distributions such as SuSE, and Kubuntu 10.04.

If you need me to do anything to help get this fixed let me know with detailed instructions. I'm a long time user of Linux however, I haven't had any experience in debugging things so please be detailed as to what you wish me to do.

Guillaume Ludwig (gml) wrote :

Does anyone know if the RAT 5 suffers the same issue ?

Guillaume Ludwig (gml) wrote :

This bug also appears with the RAT 3 mouse on Ubuntu 10.04.

Apparently no Cyborg RAT mouse works with this version of xorg…

Mitch Walker (mitch-esolation) wrote :

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"

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.

Jm8thew (jm8thew) wrote :

Man great work Mitch that seems to have worked like a charm.

I simply put this in my .Xmodmap file in the user directory:

xinput --set-button-map "Saitek Cyborg R.A.T.7 Mouse" 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0 16 17 18 19 20 21

Jm8thew (jm8thew) wrote :

Well I did I system update and something changed now the above fix wont work. Just a heads up.

Robert Hall (reh07) wrote :

Confirming that Mitch's fix no longer works with RAT 7 mouse.

Robert Hall (reh07) on 2010-10-10
affects: xserver-xorg-video-intel (Ubuntu) → xserver-xorg-input-mouse (Ubuntu)
Mitch Walker (mitch-esolation) wrote :

Just a follow-up so the above comments don't discourage anyone from at least trying: The remapping strategy outlined above still works for me, even after an update to Ubuntu 10.10 (and whatever version of the relevant software that it implies). Here is the exact entry from my Xorg.conf:

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"

And the first few lines of the Xorg.0.log:

X.Org X Server 1.9.0
Release Date: 2010-08-20
[ 21.654] X Protocol Version 11, Revision 0
[ 21.654] Build Operating System: Linux 2.6.24-27-server i686 Ubuntu
[ 21.654] Current Operating System: Linux metro 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686
[ 21.654] Kernel command line: root=UUID=bd093912-d6dc-454b-b709-ae4b992b6bf2 ro quiet splash
[ 21.654] Build Date: 16 September 2010 05:39:22PM
[ 21.654] xorg-server 2:1.9.0-0ubuntu7 (For technical support please see

The hardware is a Cyborg R.A.T. 7 attached to a Dell Latitude E6400 (Intel Corporation 82801I (ICH9 Family) USB [UE]HCI)

Robert Hall (reh07) wrote :

@Mitch: Thank you, It got it working.

All I did was update to xorg-edgers (does not seem relevant) and actually copy-pasted your entry into my Xorg.conf. I believe the first time I wrote "1 2 3 4 5 6 7 8 9 10 11 12 0 0 0 16 17 18 19 20 21" instead of "1 2 3 4 5 6 7 2 9 10 11 12 0 0 0" (note the 8.) Not sure if that may have had something to do with it.

Regardless, adding Mitch's fix to /etc/X11/xorg.conf does indeed fix the bug for RAT 7.

Sean (seanrijs) wrote :

I can confirm this works on a Saitek Cyborg R.A.T.5 Mouse.
Although the xinput tool had no effect, putting this in the xorg.conf did had effect.

I did the following on Ubuntu 10.10:
create a /etc/xorg.conf file with:
Section "InputClass"
        Identifier "Mouse Remap"
        MatchProduct "Saitek Cyborg R.A.T.5 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"
Restart X or reboot.

Xiaorong Kuo (kuoxiaorong) wrote :

Another solution (for the R.A.T.5; untested on the 7) is to simply edit the Xmodmap file to say "pointer = 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0", then reboot/restart X. This didn't require any editing of xorg.conf. Worked for 10.10; has been working on my computer for days now.

Yarro LeHock (yarro) wrote :

How can I create a /etc/xorg.conf file with:
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"

Sorry guys but I'm new to Ubuntu... So if you can write the procedure step by step, I'll be grateful.

meza (reg-meza) wrote :

Mitch's fix in #17 works perfectly with RAT7 and 1010

David Collins (davidapc) wrote :


Steps to get RAT 7 working:

1) Open terminal

2) Type (without quotes) "sudo gedit /etc/X11/xorg.conf" (Enter password if needed)

3) In the text file that opens up, add this to the bottom:

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"

4) Save file

5) Restart computer (or just restart the X server if you know how)

6) Use mouse!

Above solution is based on Mitch Walker's comment #17.

airbornemist6 (airbornemist6) wrote :

Worked for me, running kxstudio 64-bit. Thanks guys!

Mitch's xorg.conf fix works also for the RAT 3 version of the mouse, but with modified match and mapping:

Section "InputClass"
  Identifier "Mouse Remap"
  MatchProduct "Saitek Cyborg R.A.T.3 Mouse"
  MatchDevicePath "/dev/input/event*"
  Option "ButtonMapping" "1 2 3 4 5 6 7 0 0 0 0 0 0 0"

Amujuri (avsilesh-gmail) wrote :
Download full text (3.7 KiB)

This might help those still having problem with Mitch's method. This is what worked for me ....

I use RAT 5 on my HP HDX 16 laptop with Ubuntu 10.10 running on it. I install everything that comes through automatic updates.

So had my RAT working when I used Mitch's "0" mapping method since Sep'10. But recently I got the problem back and when I checked my xorg.conf file, the mouse section was missing and adding it back to the end of the file didn't work. This is how I diagnosed the problem : I made the following changes from when the mouse used to work and when it didn't.

1. Updated packages in the OS through automatic updates.
2. Disconnected RAT from Ubuntu for a while when I took it to use on my Windows machine to play some games.
3. I saved the monitor display settings, which saves it in xorg.conf file.

This is what I did that made it work again: I took the RAT mapping section from the end of the xorg.conf file to somewhere in the middle after the mapping of my keyboards and laptop touchpad. Main change I think is that RAT should be configured before my monitor gets configured (some kind of dominating strategy I don't know of). So probably for those having problem my suggestion would be to place the RAT mapping somewhere after the keyboard configuration (since its the most important) and before anything else that might play with the X-server.
And for me just setting the 13'th value to "0" works, to be more sure you might use "0" for 14 and 15 as well.

Following is my xorg.conf file:

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings: version 260.19.06 (buildd@yellow) Mon Oct 4 15:59:51 UTC 2010

Section "ServerLayout"
    Identifier "Layout0"
    Screen 0 "Screen0" 0 0
    InputDevice "Keyboard0" "CoreKeyboard"
    InputDevice "Mouse0" "CorePointer"
    Option "Xinerama" "0"

Section "Files"

Section "InputDevice"
    # generated from default
    Identifier "Mouse0"
    Driver "mouse"
    Option "Protocol" "auto"
    Option "Device" "/dev/psaux"
    Option "Emulate3Buttons" "no"
    Option "ZAxisMapping" "4 5"

Section "InputDevice"
    # generated from default
    Identifier "Keyboard0"
    Driver "kbd"

Section "InputClass"
       Identifier "Mouse Remap"
       MatchProduct "Saitek Cyborg R.A.T.5 Mouse"
       MatchDevicePath "/dev/input/event*"
       Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 10 11 12 0 14 15"

Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier "Monitor0"
    VendorName "Unknown"
    ModelName "Samsung SyncMaster"
    HorizSync 26.0 - 81.0
    VertRefresh 24.0 - 75.0
    Option "DPMS"

Section "Device"
    Identifier "Device0"
    Driver "nvidia"
    VendorName "NVIDIA Corporation"
    BoardName "GeForce GT 130M"

Section "Screen"


Chris_28 (kr15t1j4n) wrote :

How can I fix this in Kubuntu. Im new to Linux, pls help. Thanks

Darren Salt (dsalt) wrote : (for xserver-xorg-input-evdev) works around this with an extra configuration option:
 Option "AutoReleaseButtons" "13 14 15"

I have the following in my xorg.conf; it is suitable for placing in a file in "/etc/X11/xorg.conf.d". All three logical mode buttons are remapped, and the thumbwheel is remapped for horizontal scrolling.

Section "InputClass"
        Identifier "R.A.T."
        MatchUSBID "06a3:0ccb"
        Driver "evdev"
        Option "Buttons" "17"
        Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 7 6 12 13 13 13 16 17"
        Option "AutoReleaseButtons" "13 14 15"
        Option "ZAxisMapping" "4 5 6 7"

David Collins (davidapc) wrote :

Chris_28: Did you follow the instructions listed above? Also, give details such as which RAT mouse you have (there are a few different versions)

Darren Salt (dsalt) wrote :

Those of you with R.A.T. 3, 5, or 9: what's the USB ID?

Darren Salt (dsalt) wrote :

… also, output from input-events (found in input-utils) for the mode button. The kernel sees it (R.A.T. 7) as buttons 8, 9 and 10.

As root, or via sudo:

Note which eventN is used for the mouse, and use the number in the next command; here, it's currently 4. Also, hold the mouse off the pad, leaving its motion sensor clear. Again, as root or via sudo:
 input-events 4

Press the mode button three times, then let input-events time out.

Paste the result here…

(I expect that the R.A.T. 5 and 9 have the same button nos. as the R.A.T. 7 – for the mode button, 0x118, 0x119 and 0x11A. I'm mostly interested in the R.A.T. 3 here.)

Borislav Petrović (chubzor) wrote :

affected. Hope there will be some official *fix* soon.

Adam Ziegler (mrbond) wrote :

Many thanks for the xorg.conf workaround - does the job quite nicely for RAT 7 and 10.10 Server.

Andrea Ieri (andrea-ieri) wrote :

I am successfully using the following modified version of Darren's suggestion for my RAT9 on an updated and unpatched ArchLinux box:

Section "InputClass"
        Identifier "R.A.T.9"
        MatchUSBID "06a3:0cfa"
        Driver "evdev"
        Option "Buttons" "17"
        Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 7 6 12 0 0 0 16 17"
        Option "AutoReleaseButtons" "13 14 15"
        Option "ZAxisMapping" "4 5 6 7"

Horizontal scrolling is working as well! Yay!

Drake (farahon-3) wrote :

There won't be any official fix, a guy from the mad catz staff told me that there is no plans to support linux and he gave me this link

adrenochrome (adrenochrome) wrote :

seems to be 0x115 - 0x116 - 0x117 for RAT3

# input-events 6
   bustype : BUS_USB
   vendor : 0x6a3
   product : 0xccc
   version : 256
   name : "Saitek Cyborg R.A.T.3 Mouse"
   phys : "usb-0000:00:1d.0-1.1/input0"
   uniq : ""
   bits ev : EV_SYN EV_KEY EV_REL EV_MSC

waiting for events
22:25:50.961314: EV_MSC code=4 value=589830
22:25:50.961319: EV_KEY BTN_FORWARD (0x115) released
22:25:50.961322: EV_MSC code=4 value=589831
22:25:50.961323: EV_KEY BTN_BACK (0x116) pressed
22:25:50.961329: EV_SYN code=0 value=0
22:25:52.075507: EV_MSC code=4 value=589831
22:25:52.075512: EV_KEY BTN_BACK (0x116) released
22:25:52.075515: EV_MSC code=4 value=589832
22:25:52.075516: EV_KEY BTN_TASK (0x117) pressed
22:25:52.075520: EV_SYN code=0 value=0
22:25:53.163696: EV_MSC code=4 value=589830
22:25:53.163701: EV_KEY BTN_FORWARD (0x115) pressed
22:25:53.163706: EV_MSC code=4 value=589832
22:25:53.163707: EV_KEY BTN_TASK (0x117) released
22:25:53.163711: EV_SYN code=0 value=0
timeout, quitting

Timo Aaltonen (tjaalton) wrote :

you mentioned it being fixed in xorg git last fall, which means that 11.04 has the necessary fixes in

affects: xserver-xorg-input-mouse (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)
Changed in xserver-xorg-input-evdev (Ubuntu):
status: Confirmed → Fix Released
Changed in xorg (Fedora):
status: New → Invalid
kwikshot (joebentley10) wrote :

I'm still getting the same issue with my R.A.T 3 in 11.04 Natty

kwikshot (joebentley10) wrote :

Mitch.W's fix did it for me!

David Collins (davidapc) wrote :

kwikshot: If you want more attention for RAT 3, it might be an idea to open a new bug. People glancing at this bug report will only see RAT 7 and assume everything is fixed.

Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: nobody → Sestili Spurio Luigi (djdarth84)
Robert Hall (reh07) wrote :

Confirming that this has not been fixed as of 11.04

Sameer Dhar (avielus) wrote :

I just logged in to note that post # 20 worked perfectly for me, without needing to edit xorg.conf. Create a ~/.Xmodmap file with the contents of 'pointer = 0 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0' and restart X. Thanks a lot for the help

error23 (error23) wrote :

I tried all of yours methodes but any of them didn't work for me so i made my tests with xinput
for R.A.T.3 and realised that the buttons 10 11 12 don't work so I adapted yours method and it didn't work again so I realised that if I run "xinput set-button-map 9 1 2 3 4 5 6 7 8 9 0 0 0 13 14 0 0 0 0" it works just you must run it before pressing any key and before event motion of your mouse and it works for automatise the whole thing you can make a script or other way to run the command
before you run kde

kubuntu 11.04

Valentin Crone (va-crone) wrote :

I have also this bug with R.A.T3 Gaming Mouse in Ubuntu 11.04.
I connect to my session (GNOME) and I use ctrl+alt+impécr|syst+k to do disapear this bug.
After, the mouse is usable, but if I use the button to change the sensivity, this bug reappears.

(PS: Sorry in advance for my bad english..)

Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: Sestili Spurio Luigi (djdarth84) → Peter Badurek (p-badurek)
Lee Yarbrough (rugbyape) wrote :

I can confirm that the xorg.conf workaround from Mitch is still working for ubuntu 11.10 (and that the bug is still there for the first log in preventing any clicks after a little bit).

Lee Yarbrough (rugbyape) wrote :

One other thing about the xorg work around: For the button mappings I used "1 2 3 4 5 6 7 8 9 10 11 12 0 0 0" otherwise my backbutton wouldn't work if I replaced it with a two.

GA (ga) wrote :

This bug still exist in ubuntu 11.10 as of the date of my comment, the status of bug must be changed.

#to fix follow these steps:

cd /usr/share/X11/xorg.conf.d/
sudo nano 910-rat.conf

# add the following to the file

Section "InputClass"
        Identifier "R.A.T."
        MatchProduct "R.A.T.7|R.A.T.9"
        MatchDevicePath "/dev/input/event*"
        Option "Buttons" "17"
        Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 7 6 12 0 0 0 16 17"
        Option "AutoReleaseButtons" "13 14 15"
        Option "ZAxisMapping" "4 5 6 7"

# save by pressing Ctrl+X then Y then Enter
# reboot
sudo reboot now

GA (ga) wrote :

just read that it is better to put the file inside /etc/X11/xorg.conf.d/ so it may not overwritten at update time
#so on comment #49 replace
cd /usr/share/X11/xorg.conf.d/
#with this
cd /etc/X11/xorg.conf.d/
#if folder doesn't exist, create it
sudo mkdir /etc/X11/xorg.conf.d/

Thank you very much @GA (# 49). Cyborg Mouse RAT 7 works on Ubuntu 10.10 (Maverick Meerkat)

Horizontal scrolling is working!

Forward and reverse buttons are working fine!

Noel Merino Hernández (aka Blackout)

Dylan Bartlett (dylanbrtlett) wrote :

But is not fixed, can someone tell us why it has been marked as such?

Thanks for the workaround GA your solution worked perfectly.

Can this even be classified as a bug in xorg though? This seems more like a driver issue and getting a proper fix from madcatz wont happen. Its a shame really.

Jochums Johannes (infernoid) wrote :

Confirmed this bug is not fixed in 11.10

and not fixed in 12.04 :(

description: updated
smogol (juancarlos-furest) wrote :

Same for me: bug present on 12.04 with R.A.T 5
fix #19 worked for me.

Roberto Ranieri (djroby4) wrote :

Comment #49 doesn't work. The mouse works for a few minutes and then it completely stops working (does nothing at all). Please help me! (Mint 12)

From this page:

... a boy reported that the RAT 7 works perfectly in Ubuntu 12.04 (Precise Pangolin)

Just follow the instructions given by GA (# 50)

Happy hacking...!


Roberto Ranieri (djroby4) wrote :

@noel-merino. Nope, it doesn't. At least for an higher time than five minutes. Mint 13 here (precise-based).

Zebra-Rake (faheyd) wrote :


As of Linux Mint 13, this bug is still in effect. In fact, you cannot install Linux Mint 13 with this mouse attached to your computer, as mouse clicks in some of the install menu items are simply not selectable.

USB ID: Bus 004 Device 002: ID 06a3:0ccb Saitek PLC
Kernel: 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Tyler Adam (jesuisnerd) wrote :

Wanted to report that post #49/50 currently works for my R.A.T.7 in Arch Linux x86_64. I've created "/usr/share/X11/xorg.conf.d/ 15-ratmouse.conf" and placed GA's code inside, just replacing

MatchProduct "R.A.T.7|R.A.T.9" with

MatchUSBID "06a3:0cd7"

(not to say that the MatchProduct doesn't work, but I'd already taken the time to find the usb ID)

Bus 001 Device 003: ID 06a3:0cd7 Saitek PLC
Linux Archy 3.5.3-1-ARCH #1 SMP PREEMPT Sun Aug 26 09:14:51 CEST 2012 x86_64 GNU/Linux

iliis (samuelbryner) wrote :

I can confirm the solution posted (Xorg ButtonMapping) works partly in Fedora 17 x86_64. It solves the Mode-Button-Issue but I have to logout and login again after a reboot for the focus to work corretly (otherwise, the focus is locked on one window).

Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: Peter Badurek (p-badurek) → NORMAND Tristan (tetris-01)
Marcus G (iceagezerocool) wrote :

Fix dosnt work on Ubuntu 13.04 can you confirm this?

The solution given by @GA (#49) works like a charm with R.A.T. 7 in Linux Mint 15 Olivia (32 bits) with XFCE 4.10 Desktop.

Horizontal scrolling is working!
Forward and reverse buttons are working fine!

lsb_release -a
LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch
Distributor ID: LinuxMint
Description: Linux Mint 15 Olivia
Release: 15
Codename: olivia

uname -a
Linux blackout 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:19:35 UTC 2013 i686 i686 i686 GNU/Linux

Thank you very much to @GA!!!


Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: NORMAND Tristan (tetris-01) → nobody

this issue seems still to be present in ubuntu 13.10 xfce...

eraserix (eraserix) wrote :

This bug is definitely not fixed, you still need to hack around in your xorg config. I use the entry below, you may need to adapt MatchProduct line (copy/paste the string found when running the command 'xinput'). I've no idea what "AutoReleaseButtons" actually should do or if it has ever been commited to xorg. Mapping the buttons to zero is all one should ever need.

$ cat /usr/share/X11/xorg.conf.d/50-madcatz-quirks.conf
Section "InputClass"
        Identifier "Mad Catz Inc. R.A.T. 7"
        MatchProduct "Mad Catz Mad Catz R.A.T.7 Mouse"
        MatchIsPointer "true"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
        Option "Buttons" "17"
        Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 7 6 12 0 0 0 16 17"
        Option "ZAxisMapping" "4 5 6 7"

Would be nice if a quirks-file could be added to xorg.

Vladimir (vladimirivanoviliev) wrote :

I can confirm that this bug is still not fixed in Ubuntu 16.04 Beta 2. It's a shame that the fix is not added 5 years later. I would strongly suggest to consider including it as I hit it 2 times before finding this thread (and the fix) and both times installed different distro (as I didn't find the source of the issue). Guess how many users declined to use Ubuntu because of this.

wastix (wasticot) on 2016-08-22
Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: nobody → wastix (wasticot)
assignee: wastix (wasticot) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers