Different directional input values on Linux vs Windows (b0xx controller)

[zzzachzzz]

I have a revision 2 b0xx controller and am running on Linux, Debian 12, and noticed this issue when shield dropping. I am able to shield drop out of dash and shield when dashing left, but not right.

I loaded up 20XX to view the input coordinates being received.

On Linux, these are the values when inputting two directional inputs:

Down & Left:
JX: -0.7000
JY: -0.7000

Down & Right:
JX: 0.6875
JY: -0.7000

Up & Left:
JY: -0.7000
JX: 0.6875

Up & Right:
JY: 0.6875
JX: 0.6875

Whereas on Windows, these inputs all yield positive or negative 0.7000.

I originally reported this issue to b0xx support, and they speculated it could be due to a rounding error that is platform specific to Linux.

Expected Behavior

Input values should be the same as Windows.

Current Behavior

Some of the input values are slightly different, 0.6875 instead of the expected 0.7000.

Steps to Reproduce

1. Run on Linux
2. Have some way of viewing directional input values
3. Use a b0xx controller, or possibly any "Standard Controller" in Dolphin Edit I tried binding directional buttons on keyboard with the device XInput2/0/Virtual core pointer, and in 20XX that yielded 0.7 values for all (on Linux)
4. Perform these directional inputs and observe the coordinate values: Down + Left, Down + Right, Up + Left, Up + Right
5. Note that these values differ from the inputs received on Windows

Environment

Linux (issue confirmed on both Arch and Debian 12)

Shield drop input for dash left, then down:

Shield drop input for dash right, then down:

[rapito]

Thanks for the report @zzzachzzz, this is good information to know. However, I think this issue ultimately is for the b0xx developers to fix not Slippi.

Since the inputs, I believe, come from whatever driver the device uses.

If you already reported the issue on their support page, then it sounds like they acknowledged the problem and should come up with a fix sometime.

(This is not an official response though) Nikki or Fizzi would have the last word on it.

[NikhilNarayana]

there does exist a rounding issue with Standard Controller's modifier button in some cases (#344) so i could believe that some other rounding issues exist

we tested a fix for the issue above but that seemed to break things for box users so it got reverted. because of that i am very cautious about making changes to the input subsystem. we would need extensive testing and documentation for me to feel confident merging in a fix

i do not own a box so i can't perform any tests myself

[JulienBernard3383279]

While I'd say the inconsistency accross OS is a fault either on the HID driver of that OS or Slippi's end (likely the driver), addressing it directly in Slippi, even synchronously with a change in the B0XX profile, would cause issues as some users configured custom controller profiles to circumvent the B0XX's lack of native remapping, that wouldn't be updated.

In my opinion, the proper way to address this is to have the B0XX present itself as a Gamecube to USB adapter rather than a HID controller, so exact GCC coordinates can be provided with no translation, and offer remappings themselves. Otherwise it's bound to run into issues with mapping a [-128,127] or [-32768, 32767] coordinate range to a [-80, 80] coordinate space through HID.

All other modern controller firmwares (Frame1, Prong, pico-rectangle) use that approach by default now. B0XX & its sibling HayB0XX are the only ones that still don't. So I agree it's on them. Not an official response either ftr.

[zzzachzzz]

In case this is of any help in isolating if it's a driver level issue, here are some screenshots taken from a gui for joystick / jstest called jstest-gtk. Bear in mind that the gui is showing down as up and up as down, for some reason.

Down & Left:

Down & Right:

Up & Left:

Up & Right:

[zzzachzzz]

I have no idea what changed, but I'm able to shield drop from both left and right directions now.

New coordinate values

js-test-gtk

Left & Down:
Axis 0: -14071
Axis 1: -13386
Right & Down
Axis 0: 14070
Axis 1: -13386
Left & Up
Axis 0: -13729
Axis 1: 13728
Right & Up
Axis 0: 13728
Axis 1: 13728

20XX Hack Pack

Left & Down:
JX: -0.7125
JY: -0.6875
Right & Down
JX: 0.7000
JY: -0.6875
Left & Up
JX: -0.7000
JY: 0.6875
Right & Up
JX: 0.6875
JY: 0.6875

Edit 3/8/2024
Aaaand it broke again. No idea what might have changed on my system but jstest is back to to the 13728/-13729 values.

[zzzachzzz]

Not that this is any longer relevant to this repo but, for future readers, I have good news! Flashing HayBox has solved the issue for me.

This appears to be the original issue HayBox later fixed:
HayBox Issue 19: HID issues on Linux, macOS

On Linux, some of the coordinates (mostly higher magnitude ones it seems) are off by 1. E.g. cardinals are 0.9875 (79) instead of 1.0 (80)

I suspect that my momentary fix for shield drop on stock firmware might have been the result of re-calibrating with jscal. The other day when I was messing with the calibration, I had again momentarily fixed shield dropping, only to be unable to reproduce the calibration with that result. The stock b0xx firmware may be fixable with just calibration, but I didn't have enough expertise with jscal to get to a reproducible solution.