8bitdo Pro 2 in Switch mode reads as two Switch Pro controllers; does not recognize the IMU belongs to the controller

[IcedQuinn]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

On Linux and AntiMicroX 3.3.1 and 3.2.5 the controller appears as a Switch Pro controller. However none of the buttons read. If you attempt to calibrate the controller you receive axis data from the IMU only. (the Switch kernel driver reports switch pro controllers as two devices: the IMU, and the gamepad itself.)

Use of joycond can create a virtual pro controller which does read gamepad data but no IMU data.

On Windows the same controller reports as a Switch Pro with gyroscope mapping options.

Expected Behavior

Controller should appear as a Switch Pro controller, with gyroscope options, on both Windows and Linux.

Steps To Reproduce

• Plug in 8bitdo Pro 2 controller while in Switch Pro mode
• Open AntiMicroX

Environment

- OS: Void Linux
- AntiMicroX version: 3.2.5, 3.3.1

Anything else?

No response

[pktiuk]

Could you collect some logs?
https://github.com/AntiMicroX/antimicrox/wiki/Collecting-Logs

[IcedQuinn]

sure. compressed (original was 5mb despite running for under a minute.)

8bitdo.log.gz

[pktiuk]

AntiMicroX doesn't get any button events from SDL

🐞DEBUG  Processing event: SDL_CONTROLLERAXISMOTION From joystick with instance id: 0 Got button with id: 0 is one of the GameControllers: true is one of the joysticks:false (file /src/inputdaemon.cpp:752)

We get only AXIS-related events.
Could you also test this gamepad with other apps like jstest-gtk, qjoypad or sdl-jstest ?

[IcedQuinn]

we don't have any of those packages in our repos so it may take a hot second

[IcedQuinn]

the second device disappearing was because of some weird permissioning errors. bodged it by changing owner of the input device and the regulat joystick reappears in antimicrox but the IMU is separate.

for some reason the linux driver puts the controller on /dev/input/event16 and the IMU is a separate device on /dev/input/event17. antimicrox sees both of these as switch controllers (only one of them "actually" is.) Although I kinda already stated that so.

Here is evtest:

/dev/input/event16:     Nintendo Switch Pro Controller
/dev/input/event17:     Nintendo Switch Pro Controller IMU

The IMU gives out a different set of inputs:

Event: time 1667026359.880213, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 809079278
Event: time 1667026359.880213, type 3 (EV_ABS), code 3 (ABS_RX), value 64949
Event: time 1667026359.880213, type 3 (EV_ABS), code 0 (ABS_X), value -19
Event: time 1667026359.880213, type 3 (EV_ABS), code 1 (ABS_Y), value -446
Event: time 1667026359.880213, type 3 (EV_ABS), code 2 (ABS_Z), value 4219
Event: time 1667026359.880213, -------------- SYN_REPORT ------------
Event: time 1667026359.880215, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 809085611
Event: time 1667026359.880215, type 3 (EV_ABS), code 3 (ABS_RX), value 73942
Event: time 1667026359.880215, type 3 (EV_ABS), code 5 (ABS_RZ), value 8999
Event: time 1667026359.880215, type 3 (EV_ABS), code 0 (ABS_X), value -14
Event: time 1667026359.880215, -------------- SYN_REPORT ------------

Prior to opening the ticket I looked in to options like using joycond to create a virtual controller. It does work but does not include any IMU data. Apparently what everyone does is use a separate tool to read the IMU and pass it off some UDP protocol to nintendo emulators.

I don't have a PS4/5 controller on hand to check how it reports sensor data.

[IcedQuinn]

changed the title to be more accurate

[IcedQuinn]

so it looks like this should probably be redefined in general to separate issues.

• AntiMicroX should ignore Nintendo Switch Pro IMU controllers for the purpose of listing connected controllers.
• AntiMicroX should match the device IDs so a Switch Pro and Switch Pro IMU are bridged to one device with gyro read from one and buttons from the other

The upstreamed linux kernel driver for all switch protocol controllers uses two devices one for motion data and one for regular inputs. So it's not specific to 8bitdos, looks like.

Thoughts?

[pktiuk]

To be honest I am against introducing custom workarounds for specific gamepads into the AntiMicroX.
If linux kernel and SDL report it as a two devives so let it be,maybe they have some reasons I am not aware.

Moreover AntiMicroX already supports additional sensors (gyro and accelerometr) when they are considered as supported by sdl (see https://github.com/AntiMicroX/antimicrox/issues/375 ).
If you really think these gamepads should be reported as one device with IMU then you shoul report it to sdl. But I would strongly recommend checking firstly their issues and discussions for informations about this. https://github.com/libsdl-org/SDL
https://discourse.libsdl.org/

[pktiuk]

Closing, because it is out of scope of antimicrox

[IcedQuinn]

Opened a ticket upstream.

Testing with sdl2-jstest shows that AntiMicroX is still in the wrong for reading two controllers though. That API shows only one device:

icedquinn@astaraline ~/c/e/s/build (master)> ./sdl2-jstest --list
Found 1 joystick(s)

Joystick Name:     'Nintendo Switch Pro Controller'
Joystick GUID:     030000007e0500000920000000026803
Joystick Number:    0
Number of Axes:     6
Number of Buttons: 16
Number of Hats:     0
Number of Balls:    0
GameControllerConfig:
  Name:    'Nintendo Switch Pro Controller'
  Mapping: '030000007e0500000920000000026803,*,a:b0,b:b1,back:b4,dpdown:b12,dpleft:b13,dpright:b14,dpup:b11,guide:b5,leftshoulder:b9,leftstick:b7,lefttrigger:a4,leftx:a0,lefty:a1,rightshoulder:b10,rightstick:b8,righttrigger:a5,rightx:a2,righty:a3,start:b6,x:b2,y:b3,misc1:b15,platform:Linux'

Though it also fails to read the IMU it correctly rejects that its a controller.

[IcedQuinn]

This now works fine after some fixes to SDL upstream.