[Feature]Betop Asura 2 SparkLink+ Pro: buttons and rumble work, but SDL gyro/accel is not detected (works in SDL2 and on real Switch)

[anlondon]

Both SDL2 2.32.10 and SDL3 3.4.14 can reliably receive 200Hz motion events, but the values ​​of GetSensorData / GAMEPAD_SENSOR_UPDATE are all inf/nan.

latest.txt

If you need more information, please contact me directly. I'm happy to provide and resolve this issue.

[slouken]

Can you think of a solution besides checking for nan/inf for every report? This controller spoofs an official Nintendo Switch controller, so we can't adjust behavior based on the VID/PID here.

[PTALTS-LK]

Hello, I've encountered a similar issue as well, using equipment from the same company. Below is a summary of my diagnosis assisted by ChatGPT (summarized by ChatGPT, which may contain inaccuracies—please feel free to ask if you have any questions, and I'll do my best to help).

---

I am also using a third-party controller from BEITONG (Betop), specifically the BEITONG KunPeng 20 Intelligent Gaming Controller (BTP-KP20), and I am seeing a very similar IMU/gyro issue in SDL.

The controller mentioned in this issue is a different model, but it is also manufactured by BEITONG/Betop. Since my KunPeng 20 exhibits a very similar problem, I think it may be worth investigating whether there is a common compatibility issue in the Switch-compatible HID/IMU implementation used by Betop controllers.

My device

• Manufacturer: BEITONG (Betop)
• Product: BEITONG KunPeng 20 Intelligent Gaming Controller
• Model: BTP-KP20
• Connection: USB wired
• Mode: Nintendo Switch / NS mode
• USB VID/PID: 0x057E / 0x2009
• Linux kernel: CachyOS kernel 7.1.5-2-cachyos-bore

In NS mode, the controller identifies itself as a Nintendo Switch Pro Controller.

So far I have confirmed:

• Buttons: completely functional
• Analog sticks: completely functional
• Rumble: not fully tested yet, so I cannot confirm whether it works correctly
• Gyroscope / accelerometer: not working correctly through SDL3

Debugging results

I instrumented SDL3's src/joystick/hidapi/SDL_hidapi_switch.c.

First, I confirmed that the controller does send valid IMU reports.

SDL3 receives 0x30 HID reports containing changing accelerometer/gyroscope values. For example:

RAW HID REPORT len=64:
30
78
80
00
00
00
00
08
80
00
08
80
00
4E
FE
2F
FA
5B
03
2B
36
A3
F1
0F
FE
...

The values change when the controller is moved, so the IMU appears to be active and HID input reception is working.

However, SDL3 then attempts to read the IMU calibration data from the Pro Controller's SPI flash.

The relevant request is:

SPI Flash Read
Address: 0x6020
Length:  0x18 (24 bytes)

The controller responds successfully, but all 24 bytes are 0xFF:

FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF

SDL then parses the calibration data as:

Accel Raw : X=-1 Y=-1 Z=-1
Accel Coef: X=-1 Y=-1 Z=-1
Gyro Raw  : X=-1 Y=-1 Z=-1
Gyro Coef : X=-1 Y=-1 Z=-1

Accel denominator: X=0 Y=0 Z=0
Gyro denominator: X=0 Y=0 Z=0

This eventually causes the sensor data exposed by SDL to become inf/nan.

I also checked the WriteSubcommand() execution path and confirmed that the SPI read command itself succeeds:

WriteSubcommand: command=0x10 len=5
WriteSubcommand: WritePacket OK
WriteSubcommand: ReadSubcommandReply OK
WriteSubcommand: FINAL result = SUCCESS

So this does not appear to be a failure to execute the SPI read command. The controller simply returns 0xFF for this calibration region.

SDL2 comparison

This does not appear to be a Linux-specific problem.

I tested the same physical KunPeng 20 in multiple environments:

• Windows + Ryujinx(SDL2): IMU works correctly
• Linux + Yuzu(SDL2): IMU is also detected and works correctly
• Linux + Ryujinx(SDL3): the IMU calibration / sensor data problem described above occurs

In particular, the fact that the same controller works correctly with SDL2 on Linux strongly suggests that this is not caused by the Linux platform itself.

This also suggests that the controller's IMU hardware and basic HID transport are functional, and that the behavior differs between the SDL2 and SDL3 implementations.

Possible calibration compatibility issue

The KunPeng 20 is a third-party controller that emulates a Nintendo Switch Pro Controller, so its firmware may not implement the calibration storage layout in exactly the same way as an original Nintendo Pro Controller.

For example, it may:

• not provide the standard factory IMU calibration data at 0x6020;
• store calibration data at a different address;
• use a different calibration-data layout;
• or use another calibration mechanism entirely.

The official KunPeng 20 manual documents a dedicated motion-sensor calibration mode. However, this only confirms that the controller has a motion-sensor calibration function; it does not establish that its calibration data is stored using the same SPI format or addresses as an original Nintendo Pro Controller.

At this point, I cannot determine whether:

1. the Betop firmware intentionally returns 0xFF for the standard Pro Controller factory calibration region;
2. the calibration data is stored somewhere else or in a different format;
3. or SDL3 needs fallback handling when the expected calibration data is unavailable or invalid.

Since another BEITONG/Betop controller is reported to exhibit a very similar SDL IMU problem in this issue, I think this may be worth investigating as a possible common compatibility issue rather than a problem specific to a single controller model.

I can provide the complete 0x30 IMU reports, SPI read/write logs, the full response to the 0x6020 calibration read, USB descriptor information, and SDL2/SDL3 comparison data if needed.

[anlondon]

Can you think of a solution besides checking for nan/inf for every report? This controller spoofs an official Nintendo Switch controller, so we can't adjust behavior based on the VID/PID here.

The nan/inf is not coming from bad IMU reports, so I do not think a per-report isnan/isinf check is the right fix. I also agree we should not special-case VID/PID: this pad spoofs the official Switch Pro (057E:2009).

What we see on Windows (official SDL 2.32.10 and 3.4.14, same machine):

• HIDAPI Switch comes up as Nintendo Switch Pro Controller, sensors advertised, SetSensorEnabled succeeds, 0x40 Enable IMU is sent.
• Input report 0x30 streams at ~200 Hz. Raw accel/gyro in those reports change when the pad is moved, so the IMU hardware and 0x30 path are alive.
• SDL_EVENT_GAMEPAD_SENSOR_UPDATE /SDL_CONTROLLERSENSORUPDATE fire, but GetSensorData is inf/nan on every sample.

The conversion blows up earlier, in LoadIMUCalibration(). SPI flash read (subcommand 0x10) succeeds, but the payload is all 0xFF. For factory IMU calibration:

• request: address 0x6020, length 0x18
• reply (0x21, ack 0x90, subcmd 0x10):

21 f7 80 00 00 00 00 08 80 00 08 80 0c 90 10 20 60 00 00 18
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

That parses as offset/coeff -1 / -1, denominator 0, then every later 0x30 sample becomes inf/nan. The same all-0xFF SPI body also comes back for stick calibration (0x8010, 0x603D).

SDL already falls back to default Nintendo scales when the SPI read fails. This device takes the other path: the read succeeds with unusable data, so the fallback never runs.

Suggested fix (no VID/PID, not per report): when applying SPI IMU calibration, if the 24 bytes are all 0xFF / clearly unprogrammed, or any axis denominator (coeff - offset) is 0, use the same default scales already used on SPI read failure. That is a one-time check in LoadIMUCalibration(), and it would also cover a genuine Pro with blank/corrupt flash.

This looks like the same Betop NS-mode SPI hole as the KunPeng 20 (BTP-KP20) comment on this issue. Our pad is Betop Asura 2 SparkLink+ Pro, NS mode, 2.4G dongle, USB string BEITONG A2P3A NS DONGLE.

Example live 0x30 (values change across reports):

30 93 80 00 00 00 00 08 80 00 08 80 0c
d5 fe 24 fd 65 0f cf ff eb ff 00 00
...

--
Wireshark capture file:
betop-asura2-ns-057e.zip

The report obtained by the monitoring script written by cursor:
latest.txt

I can attach a USBPcap filtered to 057E:2009 once I have a non-empty export. Happy to test a patch.

[anlondon]

Can you think of a solution besides checking for nan/inf for every report? This controller spoofs an official Nintendo Switch controller, so we can't adjust behavior based on the VID/PID here.

Follow-up: I tried the LoadIMUCalibration() fallback locally (no VID/PID, no per-report isnan/isinf). It works on this pad.

Same Windows 11 machine, Betop Asura 2 SparkLink+ Pro, NS mode, 2.4G dongle only (057E:2009, USB string BEITONG A2P3A NS DONGLE). Steam / JSM / Eden closed.

Build	Result
Official SDL2 2.32.10	sensor_events=2364, nonfinite=2364, accel mean none (all inf/nan)
Official SDL3 3.4.14	same inf/nan (previous latest.txt on this issue)
SDL 3.4.16 + one-time fallback in LoadIMUCalibration()	sensor_events=2994, nonfinite=0, accel mean 9.63 m/s², live gyro

At rest after the fallback (gravity on Y, small tilt/bias on X/Z, gyro near zero with a small ZRO):

• accel ≈ X +0.39, Y +9.58, Z +0.38, |a| ≈ 9.55
• gyro ≈ X 0~0.02, Y 0, Z +0.04 rad/s
• values track when the pad is moved

So official SDL2 2.32.10 also inf on this machine. The live IMU some people see in Yuzu/JSM is not stock 2.32.10; those apps often ship an older or patched SDL2. The hole is: SPI read of factory IMU cal at 0x6020 succeeds with 24× 0xFF, denominator 0, then every 0x30 sample becomes inf. The 0x30 reports themselves are live.

Suggested change: if SPI IMU cal is unusable (coeff == offset on any axis, including all-0xFF), use the same default Nintendo scales already used when the SPI read fails. Sketch against current LoadIMUCalibration():

        if ((sAccelSensCoeffX != sAccelRawX) && (sAccelSensCoeffY != sAccelRawY) && (sAccelSensCoeffZ != sAccelRawZ) &&
            (sGyroSensCoeffX != sGyroRawX) && (sGyroSensCoeffY != sGyroRawY) && (sGyroSensCoeffZ != sGyroRawZ)) {
            ctx->m_IMUScaleData.fAccelScaleX = SWITCH_ACCEL_SCALE_MULT / ((float)sAccelSensCoeffX - (float)sAccelRawX) * SDL_STANDARD_GRAVITY;
            ctx->m_IMUScaleData.fAccelScaleY = SWITCH_ACCEL_SCALE_MULT / ((float)sAccelSensCoeffY - (float)sAccelRawY) * SDL_STANDARD_GRAVITY;
            ctx->m_IMUScaleData.fAccelScaleZ = SWITCH_ACCEL_SCALE_MULT / ((float)sAccelSensCoeffZ - (float)sAccelRawZ) * SDL_STANDARD_GRAVITY;
            ctx->m_IMUScaleData.fGyroScaleX = SWITCH_GYRO_SCALE_MULT / ((float)sGyroSensCoeffX - (float)sGyroRawX) * SDL_PI_F / 180.0f;
            ctx->m_IMUScaleData.fGyroScaleY = SWITCH_GYRO_SCALE_MULT / ((float)sGyroSensCoeffY - (float)sGyroRawY) * SDL_PI_F / 180.0f;
            ctx->m_IMUScaleData.fGyroScaleZ = SWITCH_GYRO_SCALE_MULT / ((float)sGyroSensCoeffZ - (float)sGyroRawZ) * SDL_PI_F / 180.0f;
            return true;
        }
    }

    // Use default values (same as today's SPI-read-failure path)

Happy to test an official patch. New probe log attached (latest.txt, 2026-09-04 18:23). USBPcap for 057E:2009 is already on this issue as betop-asura2-ns-057e.zip.

latest.txt