[SOLVED] Mad Catz R.A.T. 5 mouse issues in Xorg

yenn · 02-09-2016, 07:40 AM

I have R.A.T. 5 mouse and there is this annoying issue every time I start Xorg.

I can move mouse cursor and but only right button click works. Only solution is to kill Xorg, start it again and then finally all buttons works. Also note that if I plug mouse in after Xorg is started, it works like a charm.

Here is a relevant part of Xorg log, which I believe means that mouse is recognized by Xorg.

Code:

[    45.119] (II) config/udev: Adding input device Mad Catz Mad Catz R.A.T.5 Mouse (/dev/input/event1)
[    45.119] (**) Mad Catz Mad Catz R.A.T.5 Mouse: Applying InputClass "evdev pointer catchall"
[    45.119] (II) Using input driver 'evdev' for 'Mad Catz Mad Catz R.A.T.5 Mouse'
[    45.119] (**) Mad Catz Mad Catz R.A.T.5 Mouse: always reports core events
[    45.119] (**) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: Device: "/dev/input/event1"
[    45.170] (--) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: Vendor 0x738 Product 0x1705
[    45.170] (--) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: Found 17 mouse buttons
[    45.170] (--) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: Found scroll wheel(s)
[    45.170] (--) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: Found relative axes
[    45.170] (--) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: Found x and y relative axes
[    45.170] (II) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: Configuring as mouse
[    45.170] (II) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: Adding scrollwheel support
[    45.170] (**) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: YAxisMapping: buttons 4 and 5
[    45.170] (**) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[    45.170] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:12.0/usb3/3-4/3-4:1.0/0003:0738:1705.0002/input/input3/event1"
[    45.170] (II) XINPUT: Adding extended input device "Mad Catz Mad Catz R.A.T.5 Mouse" (type: MOUSE, id 12)
[    45.170] (II) evdev: Mad Catz Mad Catz R.A.T.5 Mouse: initialized for relative axes.
[    45.170] (**) Mad Catz Mad Catz R.A.T.5 Mouse: (accel) keeping acceleration scheme 1
[    45.170] (**) Mad Catz Mad Catz R.A.T.5 Mouse: (accel) acceleration profile 0
[    45.170] (**) Mad Catz Mad Catz R.A.T.5 Mouse: (accel) acceleration factor: 2.000
[    45.170] (**) Mad Catz Mad Catz R.A.T.5 Mouse: (accel) acceleration threshold: 4
[    45.170] (II) config/udev: Adding input device Mad Catz Mad Catz R.A.T.5 Mouse (/dev/input/mouse0)
[    45.170] (II) No input driver specified, ignoring this device.
[    45.170] (II) This device may have been added with another device file.

I also find this page on ArchWiki, but it only contains vague description and fixes for other models (r.a.t. 3, 7, 9), not this one.

Code:

After being plugged, the mouse will seems to work, but you may experience different issues :

    You cannot move windows around when grabbing the window's title bar. (happens with Openbox and other Window manager)
    You cannot click on buttons.
    You cannot get the focus on windows.
[...]
The issues are caused by an interaction between R.A.T Mode button and the X Server. To restore proper function, the 'Mode' button must be disabled.

I find hard to believe that I need special configuration if mouse works after second try. Or is Xorg doing some magic auto-recognition on background so it knows better second time?

yenn · 02-09-2016, 08:48 AM

I dig a little deeper and figured it out.

Linked ArchWiki page is correct, although it doesn't explain what *exactly* is the problem a why these Xorg ButtonMapping fixes it.

The real reason is described here: https://bugs.launchpad.net/ubuntu/+s...92/comments/13

Code:

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).

You can fix it by adding custom Xorg conf file to xorg.conf.d/ directory (/etc/X11/xorg.conf.d on Slackware). Working config for rat 5 is here: https://bugs.launchpad.net/ubuntu/+s...92/comments/19

But first you need to make sure to use exact product string as detected by xinput. Otherwise it won't work.

Code:

yenn@darkstar ~ > xinput --list
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ USB KVM                                   id=10   [slave  pointer  (2)]
⎜   ↳ Mad Catz Mad Catz R.A.T.5 Mouse           id=12   [slave  pointer  (2)]

Older Rats identified themselves as 'Saitek Cyborg R.A.T.5 Mouse', while mine is 'Mad Catz Mad Catz R.A.T.5 Mouse'.

/etc/X11/xorg.conf.d/rat5.conf

Code:

Section "InputClass"
         Identifier "Mad Catz R.A.T.5 Mouse"
         MatchProduct "Mad Catz Mad Catz R.A.T.5 Mouse" # check exact model with xinput
         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" # block buttons 13,14,15
EndSection