Re: [PATCH v5 0/2] HID: flydigi: add support for vader 5 pro

[MIrian Shilakadze <mirian@msh.ge>]

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