* Re: [PATCH v5 0/2] HID: flydigi: add support for vader 5 pro
@ 2026-11-05 23:51 MIrian Shilakadze
2026-11-06 0:03 ` Denis Benato
0 siblings, 1 reply; 3+ messages in thread
From: MIrian Shilakadze @ 2026-11-05 23:51 UTC (permalink / raw)
To: Denis Benato, 'Jiri Kosina'
Cc: 'Benjamin Tissoires', 'Dmitry Torokhov',
linux-input, linux-kernel, Derek J. Clark
On 9/15/26 9:14 PM, Denis Benato wrote:
> To make optimal use of this device the xpad driver should not
> bind to the controller, and this is the case for more than just
> this controller as Derek told me, so I added some basic infrastructure
> to use the best available driver for the device.
Hi Denis,
I gave v5 a try with a Flydigi Apex 5 (37d7:2501, wired, firmware
0x7045). It uses the same protocol as the Vader 5 Pro, as far as I can
tell. The difference I found is the report ID: 0x03 for output and 0x04
for input. SDL already handles this.
One thing came up that probably affects the Vader too. The driver
ignores the third-party flag in the status reply (the "Allow third-party
apps to take over mappings" setting in Space Station). SDL checks it for
all V2 pads, the Vader 5 Pro included. On my Apex 5, with the flag off,
acquire is ACKed but no 0xef reports come and nothing tells the user
why. After setting it with 0x11 (ff ff ff ff 01), the stream starts and
M1-M4 work. It stays on after a USB replug. I tested this by hand over
hidraw.
Should the driver check the flag and warn or turn it on itself with 0x11?
Supporting the Apex 5 looks small from what I have seen so far.
raw_event already skips the report ID. The descriptor check would need
to learn this layout (output ID 0x03), plus the ID in the hid and xpad
tables. Would you like that as part of this series or as a separate
patch later? I'm happy to write and test it.
Thanks,
Mirian Shilakadze
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v5 0/2] HID: flydigi: add support for vader 5 pro
2026-11-05 23:51 [PATCH v5 0/2] HID: flydigi: add support for vader 5 pro MIrian Shilakadze
@ 2026-11-06 0:03 ` Denis Benato
0 siblings, 0 replies; 3+ messages in thread
From: Denis Benato @ 2026-11-06 0:03 UTC (permalink / raw)
To: MIrian Shilakadze, 'Jiri Kosina'
Cc: 'Benjamin Tissoires', 'Dmitry Torokhov',
linux-input, linux-kernel, Derek J. Clark
On 11/6/26 00:51, MIrian Shilakadze wrote:
> On 9/15/26 9:14 PM, Denis Benato wrote:
>> To make optimal use of this device the xpad driver should not
>> bind to the controller, and this is the case for more than just
>> this controller as Derek told me, so I added some basic infrastructure
>> to use the best available driver for the device.
> Hi Denis,
Hi Mirian,
Thanks for your intrest!
> I gave v5 a try with a Flydigi Apex 5 (37d7:2501, wired, firmware
> 0x7045). It uses the same protocol as the Vader 5 Pro, as far as I can
> tell. The difference I found is the report ID: 0x03 for output and 0x04
> for input. SDL already handles this.
That's easy enough, we can do it.
> One thing came up that probably affects the Vader too. The driver
> ignores the third-party flag in the status reply (the "Allow third-party
> apps to take over mappings" setting in Space Station). SDL checks it for
> all V2 pads, the Vader 5 Pro included. On my Apex 5, with the flag off,
> acquire is ACKed but no 0xef reports come and nothing tells the user
> why. After setting it with 0x11 (ff ff ff ff 01), the stream starts and
> M1-M4 work. It stays on after a USB replug. I tested this by hand over
> hidraw.
>
> Should the driver check the flag and warn or turn it on itself with 0x11?
I think it should have a sysfs property allowing to change it and also set
the most reasonable value at probe.
> Supporting the Apex 5 looks small from what I have seen so far.
> raw_event already skips the report ID. The descriptor check would need
> to learn this layout (output ID 0x03), plus the ID in the hid and xpad
> tables. Would you like that as part of this series or as a separate
> patch later? I'm happy to write and test it.
I have actually a better idea: the friend of mine with the actual hardware
has discovered that a recent firmware update changed things and he
tasked an llm to properly handle the apex 6.
Since you two have the whole range of hardware and SDL has working
code why don't you take over? It would surely be better than me making
the bridge since you do own hardware and care about it.
Let me know if you are interested and I will be more than happy to
make that happen!
Best regards,
Denis
> Thanks,
> Mirian Shilakadze
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH v5 0/2] HID: flydigi: add support for vader 5 pro
@ 2026-09-15 17:14 Denis Benato
0 siblings, 0 replies; 3+ messages in thread
From: Denis Benato @ 2026-09-15 17:14 UTC (permalink / raw)
To: 'Jiri Kosina'
Cc: 'Benjamin Tissoires', 'Dmitry Torokhov',
linux-input, linux-kernel, Derek J. Clark, Denis Benato
Hi all,
A few days ago I was contacted by a friend of mine who was having his
share of issues with his Flydigi Vader 5 Pro controller: specifically
the rumble didn't work correctly, alongside other issues that were
partially solved by using the linked project.
However at the current time his main interest is in Steam support
and the driver was working in everything but Steam, which insists
on using the controller in hid mode rather than evdev mode
by default, and when in evdev mode it is disregarding additional
buttons and the gyroscope.
So we ended up with a perfectly working driver for the controller,
that at the cost of gyroscope support and back buttons has
rumble working correctly in Steam.
Since the driver works in basically everything that is not Steam,
including the browser, I decided to submit it anyway as someone
else will surely be interested in using some other way that is not
the aforementioned program.
To make optimal use of this device the xpad driver should not
bind to the controller, and this is the case for more than just
this controller as Derek told me, so I added some basic infrastructure
to use the best available driver for the device.
I also want to thank the original authors that did the work
of implementing the controller the first time (in SDL).
Best regards,
Denis Benato
Link: https://github.com/DuncanTPerkins/vader5-pro-linux-fix
Link v1: https://lore.kernel.org/all/20260807012334.58737-1-denis.benato@linux.dev/
Link v2: https://lore.kernel.org/all/20260808122439.69159-1-denis.benato@linux.dev/
Link v3: https://lore.kernel.org/all/20260811125856.1692045-1-denis.benato@linux.dev/
Link v4: https://lore.kernel.org/all/20260912015926.230874-1-denis.benato@linux.dev/
v2:
- HID: flydigi: add support for vader 5 pro
- Solve flagged vulnerabilities
v3:
- HID: flydigi: add support for vader 5 pro
- Solve the flagged vulnerability
v4:
- HID: flydigi: add support for vader 5 pro
- Fix rumble possibly getting overwhelmed
- Implement battery reporting
- Improve imu reporting
v5:
- HID: flydigi: add support for vader 5 pro
- Fix reported security issues
Denis Benato (2):
HID: flydigi: add support for vader 5 pro
Input: xpad - introduce a static table to ignore devices
drivers/hid/Kconfig | 8 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-flydigi.c | 1159 +++++++++++++++++++++++++++++++++
drivers/hid/hid-ids.h | 3 +
drivers/input/joystick/xpad.c | 24 +
5 files changed, 1195 insertions(+)
create mode 100644 drivers/hid/hid-flydigi.c
--
2.47.3
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-11-06 0:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-05 23:51 [PATCH v5 0/2] HID: flydigi: add support for vader 5 pro MIrian Shilakadze
2026-11-06 0:03 ` Denis Benato
-- strict thread matches above, loose matches on Subject: below --
2026-09-15 17:14 Denis Benato
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®