Bug 200995 - Redragon Seymur 2 controller has its axes with problems, 4.17.18 was fine
Summary: Redragon Seymur 2 controller has its axes with problems, 4.17.18 was fine
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-02 18:47 UTC by leozinho29_eu
Modified: 2018-10-11 15:00 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.18.5 4.19-rc1
Tree: Mainline
Regression: No


Attachments
.config (211.93 KB, text/x-mpsub)
2018-09-02 18:47 UTC, leozinho29_eu
Details
File generated with hid-recorder and video (2.79 MB, application/x-tar)
2018-10-11 14:27 UTC, leozinho29_eu
Details
4.19-rc7: File generated with hid-recorder and video (3.03 MB, application/x-tar)
2018-10-11 14:56 UTC, leozinho29_eu
Details

Description leozinho29_eu 2018-09-02 18:47:25 UTC
Created attachment 278247 [details]
.config

The controller Redragon Seymur 2 has problems with the axes with kernel version 4.18.5 and 4.19-rc1. 4.17.18 was fine.

(I'll use the nomenclature gave by jstest-gtk as I'm having troubles to explain it otherwise).

The controller has two handles that were operating properly on 4.17.18. However, with 4.18.5 and 4.19-rc1, the ABS_RX axis does not exist anymore and its action was replace by ABS_Z. The problem is that many other inputs are triggering ABS_Z. ABS_X triggers ABS_Z, ABS_RZ triggers ABS_Z too. The ABS_Z axis itself does not work properly, as if it's kept in a position for some time it resets to 0 (for example, in a racing game when turning the car to left or right it resets). 

These changes made the gamepad unusable, as two axes are set to the same axis (ABS_X and ABS_Z), one axis is assigned to the wrong axis (ABS_RZ does ABS_Z actions instead) and another is impossible to use (ABS_RZ is impossible to trigger).

Steps to reproduce:

1) Connect controller;
2) Press the "MODE" button in the controller to enable the right handle ("Xinput mode");
3) Try to use it;
4) Note how the axes are messed and input is happening incorrectly.

Relevant information:

This is how jstest-gtk showed the controller axes on 4.17.18: https://i.imgur.com/kPIdGeB.png
This is how jstest-gtk showed the controller axes on 4.18.5: https://i.imgur.com/YBQjZgx.png

$ uname -a
Linux Lenovo-ideapad-310-14ISK 4.18.5-041805-lowlatency #201808241320 SMP PREEMPT Fri Aug 24 13:24:56 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 008: ID 0cf3:e360 Qualcomm Atheros Communications 
Bus 001 Device 006: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 004: ID 0bda:57f9 Realtek Semiconductor Corp. 
Bus 001 Device 007: ID 1a2c:0c23 China Resource Semico Co., Ltd 
Bus 001 Device 009: ID 045e:00cb Microsoft Corp. Basic Optical Mouse v2.0
Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 002: ID 0079:0006 DragonRise Inc. PC TWIN SHOCK Gamepad
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ dmesg | grep drag
[   20.113513] dragonrise 0003:0079:0006.0001: input,hidraw3: USB HID v1.10 Joystick [DragonRise Inc.   Generic   USB  Joystick  ] on usb-0000:00:14.0-1/input0
[   20.113520] dragonrise 0003:0079:0006.0001: Force Feedback for DragonRise Inc. game controllers by Richard Walmsley <richwalm@gmail.com>
Comment 1 leozinho29_eu 2018-09-13 05:36:22 UTC
I did a bisect, and the result was:

190d7f02ce8ef6774a69d3ec18c288c8a9601a4e is the first bad commit
commit 190d7f02ce8ef6774a69d3ec18c288c8a9601a4e
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Fri Dec 8 15:28:18 2017 +0100

    HID: input: do not increment usages when a duplicate is found
    
    This is something that bothered us from a long time. When hid-input
    doesn't know how to map a usage, it uses *_MISC. But there is something
    else which increments the usage if the evdev code is already used.
    
    This leads to few issues:
    - some devices may have their ABS_X mapped to ABS_Y if they export a bad
      set of usages (see the DragonRise joysticks IIRC -> fixed in a specific
      HID driver)
    - *_MISC + N might (will) conflict with other defined axes (my Logitech
      H800 exports some multitouch axes because of that)
    - this prevents to freely add some new evdev usages, because "hey, my
      headset will now report ABS_COFFEE, and it's not coffee capable".
    
    So let's try to kill this nonsense, and hope we won't break too many
    devices.
    
    I my headset case, the ABS_MISC axes are created because of some
    proprietary usages, so we might not break that many devices.
    
    For backward compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
    is created and can be applied to any device that needs this behavior.
    
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
    Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

:040000 040000 e308544fb6e4a6d97b1647b5b3591a0dc4285202 7bc232235db62d2445ef7b61095d888fac73b917 M	drivers
:040000 040000 0a1d0d7aa39f7e907961883aeee8e376fe0daa41 0c0d5e242544074400ac7284512f462770888fce M	include
Comment 2 Benjamin Tissoires 2018-10-11 08:36:19 UTC
Thanks for the bisect. Can you provide the report descriptors of the device and some events? Ideally, can you use hid-recorder from the package hid-replay[1].

HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE might be the simplest solution, but I'd like to double check this won't bite us later.

[1] http://bentiss.github.io/hid-replay-docs/
Comment 3 leozinho29_eu 2018-10-11 14:27:25 UTC
Created attachment 278993 [details]
File generated with hid-recorder and video

The attached file has the file generated by hid-recorder and a video showing the behavior of the controller on 4.17.19 using jstest-gtk, where the controller works as intended.

Notice in the video that what is called in jstest-gtk "Axis 2" is enabled by multiple inputs: The "Axis 0" (left analog X) triggers "Axis 2" in a smaller scale together. The same happens with "Axis 4" (right analog Y).

I believe games work as intended even with it doing this bad behavior because "Axis 0" and "Axis 4" movement start before "Axis 2", so in controller settings they always detect 0 and 4 first and 2 never is detected.

What 4.18 and newer did was to remove one of the axis. However, instead of removing this useless "Axis 2" it removed a relevant axis, not sure if "Axis 2" or "Axis 3", thus crippling the controller.

I will reboot and get hid-recorder from 4.19-rc7.
Comment 4 leozinho29_eu 2018-10-11 14:56:31 UTC
Created attachment 278995 [details]
4.19-rc7: File generated with hid-recorder and video

Here is the file with hid-recorder and video from 4.19-rc7.

It is "Axis 3" that no longer exists and its function was replaced by "Axis 2". However, "Axis 2" constantly resets to 0 and still is triggered by other inputs. "Axis 0" still triggers "Axis 2" and what was "Axis 4" in 4.17.19, and now is "Axis 3", still triggers "Axis 2".
Comment 5 Benjamin Tissoires 2018-10-11 15:00:30 UTC
Thanks for the logs. Copying the human readable version of the report descriptors here:

0x05, 0x01,                    // Usage Page (Generic Desktop)        0
0x09, 0x04,                    // Usage (Joystick)                    2
0xa1, 0x01,                    // Collection (Application)            4
0xa1, 0x02,                    //  Collection (Logical)               6
0x75, 0x08,                    //   Report Size (8)                   8
0x95, 0x05,                    //   Report Count (5)                  10
0x15, 0x00,                    //   Logical Minimum (0)               12
0x26, 0xff, 0x00,              //   Logical Maximum (255)             14
0x35, 0x00,                    //   Physical Minimum (0)              17
0x46, 0xff, 0x00,              //   Physical Maximum (255)            19
0x09, 0x30,                    //   Usage (X)                         22
0x09, 0x31,                    //   Usage (Y)                         24
0x09, 0x32,                    //   Usage (Z)                         26
0x09, 0x32,                    //   Usage (Z)                         28
0x09, 0x35,                    //   Usage (Rz)                        30
0x81, 0x02,                    //   Input (Data,Var,Abs)              32
0x75, 0x04,                    //   Report Size (4)                   34
0x95, 0x01,                    //   Report Count (1)                  36
0x25, 0x07,                    //   Logical Maximum (7)               38
0x46, 0x3b, 0x01,              //   Physical Maximum (315)            40
0x65, 0x14,                    //   Unit (Degrees,EngRotation)        43
0x09, 0x39,                    //   Usage (Hat switch)                45
0x81, 0x42,                    //   Input (Data,Var,Abs,Null)         47
0x65, 0x00,                    //   Unit (None)                       49
0x75, 0x01,                    //   Report Size (1)                   51
0x95, 0x0c,                    //   Report Count (12)                 53
0x25, 0x01,                    //   Logical Maximum (1)               55
0x45, 0x01,                    //   Physical Maximum (1)              57
0x05, 0x09,                    //   Usage Page (Button)               59
0x19, 0x01,                    //   Usage Minimum (1)                 61
0x29, 0x0c,                    //   Usage Maximum (12)                63
0x81, 0x02,                    //   Input (Data,Var,Abs)              65
0x06, 0x00, 0xff,              //   Usage Page (Vendor Defined Page 1) 67
0x75, 0x01,                    //   Report Size (1)                   70
0x95, 0x08,                    //   Report Count (8)                  72
0x25, 0x01,                    //   Logical Maximum (1)               74
0x45, 0x01,                    //   Physical Maximum (1)              76
0x09, 0x01,                    //   Usage (Vendor Usage 1)            78
0x81, 0x02,                    //   Input (Data,Var,Abs)              80
0xc0,                          //  End Collection                     82
0xa1, 0x02,                    //  Collection (Logical)               83
0x75, 0x08,                    //   Report Size (8)                   85
0x95, 0x07,                    //   Report Count (7)                  87
0x46, 0xff, 0x00,              //   Physical Maximum (255)            89
0x26, 0xff, 0x00,              //   Logical Maximum (255)             92
0x09, 0x02,                    //   Usage (Vendor Usage 2)            95
0x91, 0x02,                    //   Output (Data,Var,Abs)             97
0xc0,                          //  End Collection                     99
0xc0,                          // End Collection                      100


summary: HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE is going to be the quickest fix.
We *could* rewrite the report descriptor to not have "X, Y, Z, Z, RZ", but it might not worth spending time when the quirk will do just fine in this case.

Note You need to log in before you can comment on or make changes to this bug.