Bug 200995
Summary: | Redragon Seymur 2 controller has its axes with problems, 4.17.18 was fine | ||
---|---|---|---|
Product: | Drivers | Reporter: | leozinho29_eu |
Component: | Input Devices | Assignee: | drivers_input-devices |
Status: | NEW --- | ||
Severity: | normal | CC: | benjamin.tissoires |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.18.5 4.19-rc1 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
.config
File generated with hid-recorder and video 4.19-rc7: File generated with hid-recorder and video |
Description
leozinho29_eu
2018-09-02 18:47:25 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 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. |