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>
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
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/
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.
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".
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.