Add Flydigi VADER 4 Pro support

[bakatrouble]

Add a new controller support

Description

The controller outputs custom HID reports for PS5 controller emulation through vendor software, which also contain motion data unlike the normal HID endpoint.

All inputs checked using testcontroller, still not sure how to properly test gyro data and generate mappings for other platforms

[bakatrouble]

Mappings fixed

[slouken]

FYI, this product ID is used by every FlyDigi controller, but they all have different report structures. We need a way to positively identify that this is the Vader 4 Pro controller.

[slouken]

Interesting. I tried this out with the Vader 2, and it has a 32-byte report and rumble works, but gyro data doesn't come through.

[slouken]

Actually, the gyro data is in bytes 4-6 of the packet, for the Vader 2. It looks like it doesn't have an accelerometer sensor.

[slouken]

This driver also works for the Apex 3. If the report format is stable across all FlyDigi controllers, then we can accept this patch, thanks!

What work do you have left before merging? Don't worry about the macOS build failure, I can fix that once this is merged.

[bakatrouble]

There are two paths for parsing the payload in the Space Station software: for "K1" models and the rest, from what I see it should be just for Apex 3.
There are some operations with "masks" I did not closely look into yet that are different for the two paths, will check later.

[bakatrouble]

BTW, I see two ways of detecting the gamepad model in Space Station: from response to a "get config" report and simply from the device name.

[slouken]

I'm guessing the get config report will contain the gyro and accelerometer calibration data. That might give us a single path to get the accelerometer scale that works with all controllers.

[bakatrouble]

These configs look more like profiles with remappings, stick curves etc, the only motion-related stuff there is whether to emulate mouse or right stick and corresponding sensitivity.
Dualsense emulation seems to be based on vigem, maybe it has some hardcoded calibration data?

[slouken]

Suggested change

	#define FLYDIGI_ACCEL_SCALE 256.f
	#define FLYDIGI_ACCEL_SCALE 5120.f

This seems like the correct scale for the Apex 3 controller. The accelerometer axes seem correct. I can double check the gyro once this is merged.

Are the internal sensors updated at 125 Hz?

[bakatrouble]

No idea, I just tuned the value to get 9.8 while my vader4 is laying flat. With 5120, I get 0.5 on the same axis.

[bakatrouble]

Tried to do the same with gyro comparing with the values from dualsense, but my confidence is much lower there.

[slouken]

It looks like the Vader 4 and Apex 3 use different sensor values. Any chance we can differentiate them?

[bakatrouble]

Device name should be enough
Though looks like what is different are buttons bitmasks, are buttons detected correctly on apex 3?

[slouken]

Yes, buttons are working correctly, though there's no C/Z button. We probably should dynamically set the number of available buttons based on the button bitmask.

[bakatrouble]

Figured out that the only difference is that in the non-"K1" models circle button status is reported in a different bit.
@slouken Could you please test which bits are set for the M1-M4 buttons on apex3? The map says that the circle button is reported in a bit that is already taken by M4 on vader4.

[slouken]

Figured out that the only difference is that in the non-"K1" models circle button status is reported in a different bit. @slouken Could you please test which bits are set for the M1-M4 buttons on apex3? The map says that the circle button is reported in a bit that is already taken by M4 on vader4.

The M1-M4 buttons worked correctly here on the Apex 3 with your original PR.

[bakatrouble]

The M1-M4 buttons worked correctly here on the Apex 3 with your original PR.

Hm, maybe it's an ID for an older firmware?
Also just noticed that report[2] is likely the device id, mine is 102 = 0x66

[slouken]

I tested the Apex 3, Apex 4, Vader 2, and Vader 4 Pro, and in all cases the report is 32 bytes and the first three bytes are 0x04, 0xfe, 0x66.

On my Vader 4 Pro, the accelerometer Z axis isn't quite right. When resting the Z axis seems to auto-calibrate to 0, but when pointed up the axis is -11, and pointing down it's 8.5.

[slouken]

We shouldn't report the circle button. That's used on all the controllers I have here to toggle gyro mouse mode.

[slouken]

Here is some more information on the Flydigi protocol:
https://github.com/pipe01/flydigictl/blob/master/pkg/flydigi/protocol/dinput/dinput.go

[bakatrouble]

On my Vader 4 Pro, the accelerometer Z axis isn't quite right. When resting the Z axis seems to auto-calibrate to 0, but when pointed up the axis is -11, and pointing down it's 8.5.

Yeah, that seems to be the case on mine too. Is that critical? And if so, what could be done about it, add a different multiplier depending on whether it's positive or negative?

And in Switch mode, i see Z values from -4.5 to 4, X is from -11 to 11
This gamepad is all over the place

[bakatrouble]

We shouldn't report the circle button

Maybe just change it in a mapping to something like misc4 so it wouldn't be confused with xbox share button? I personally might just find a method to disable the mouse input device in OS and use it as a screenshot button.

[slouken]

On my Vader 4 Pro, the accelerometer Z axis isn't quite right. When resting the Z axis seems to auto-calibrate to 0, but when pointed up the axis is -11, and pointing down it's 8.5.

Yeah, that seems to be the case on mine too. Is that critical? And if so, what could be done about it, add a different multiplier depending on whether it's positive or negative?

And in Switch mode, i see Z values from -4.5 to 4, X is from -11 to 11 This gamepad is all over the place

Normally controllers have calibration data that is either used to adjust the values reported by the controller, or used by the driver to adjust the values reported to the application. The Nintendo Switch reports this calibration data and we use it in that driver, so if the controller isn't working in Switch mode then I'm not sure what we can do about it.

We can't just hardcode values, since they may change from controller production run to production run, or even between units in the same run.

I think we just pass on what the controller is reporting and be done with it, unless we get more information from FlyDigi about how we can handle this.

Also, did you verify that the report rate is 125 Hz? I think that code was pulled from the 8BitDo driver and may not be correct for these controllers.

[slouken]

We shouldn't report the circle button

Maybe just change it in a mapping to something like misc4 so it wouldn't be confused with xbox share button? I personally might just find a method to disable the mouse input device in OS and use it as a screenshot button.

Maybe. Let's leave it out for now (or commented out) and we can revisit that once a way to effectively use it becomes available. The other side effect is that it enables and disables gyro data in the output report on the Apex controllers, so I don't think we want to encourage users to press it.