8BitDo Lite Analog Left input not being mapped correctly

[udance4ever]

Batocera build version

40o 2024/06/28 20:36

Your architecture

x86_64

Your Graphic Processor Unit(s) (GPU)

Integrated Iris

Issue description

My ultimate goal is to play a ps3 title that requires the Analog Left stick on a 8BitDo over USB-C on a ROG Ally. I was having issues and couldn’t figure out if it was the Ally, v40-dev, or my controller.

I fell back to v39 on a 2015 MBP, can reproduce an issue in ES navigation in both v39 and v40-dev. evtest reports all the correct inputs but ES moves the cursor down if you press Left Analog left, right (or down :). Up works.

Detailed reproduction steps

1. install Batocera v39 or v40-dev 6/28/2024
2. plug 8BitDo Lite in via USB-C cord (eliminates any BT issues)
3. configure gamepad 3a. “Left Analog Up” is mapped to “Hat 0 Up” 3b. “Left Analog Left” is mapped to “Hat 0 Left”
4. confirm D-pad moves around ES correctly in all 4 directions
5. observe Left Analog left, right go down

Details of any attempts to fix this yourself

reproduced the issue in both v39 and v40-dev 6/28/2024

confirmed evtest reports the correct inputs for up, left, down, right (in this order):

Event: time 1720220410.702845, type 3 (EV_ABS), code 17 (ABS_HAT0Y), value -1
Event: time 1720220410.810847, type 3 (EV_ABS), code 17 (ABS_HAT0Y), value 0
Event: time 1720220412.682845, type 3 (EV_ABS), code 16 (ABS_HAT0X), value -1
Event: time 1720220412.810831, type 3 (EV_ABS), code 16 (ABS_HAT0X), value 0
Event: time 1720220422.111145, type 3 (EV_ABS), code 17 (ABS_HAT0Y), value 1
Event: time 1720220422.219147, type 3 (EV_ABS), code 17 (ABS_HAT0Y), value 0
Event: time 1720220422.599108, type 3 (EV_ABS), code 16 (ABS_HAT0X), value 1
Event: time 1720220422.699112, type 3 (EV_ABS), code 16 (ABS_HAT0X), value 0

Workaround

while this is not a workaround in Batocera, I installed rpcs3 on Windows 11 and confirmed there are no issues mapping X-Input from a wired 8BitDo Lite to the correct controls in RPCS3.

Details of any modifications you have made to Batocera.

overlay:

1. hiscore.dat updates
2. updated coco_flop.xml and coco_cass.xml software lists
3. custom build of /usr/bin/mame/mame that accepts coco_cass software list
4. es_system.cfg patch to accept 3ds.squashfs
5. Emulator.py with patch to accept relative paths in batocera.conf

Logs and data

batocera-support-20240705160832.tar.gz

[dmanlfc]

i suspect either an 8-bitdo firmware issue (ensure you're on the latest) or how the kernel module xpad_noone is handing the controller incorrectly. use sdl2-jstest -t 0 to test the controller left analog is reported & moves correctly. adjust the number of your controller, i suspect -t 1 will be necessary with the Rog Ally.

[udance4ever]

hey thanks for the input and did more testing. Just to be clear, this is ES related before any emulator (eg. RPCS3) launches.

What I discovered is before doing any controller mapping, the left analog on the 8BitDo moves the cursor around just fine. If I map the controller, then the left analog goes wonky as described above.

I did a sdl2-jstest -t 1 both before and after and it reads the analog left just fine in both cases.

there is something going on while translating the raw input to ES controls.

what file is generated after a controller map? I’m happy to diff the file before and after a controller remap to see if this might point to the issue.

[dmanlfc]

@udance4ever you may have an erroneous setting in the .sdl2 folder. remove the files in there which is under /userdata/system

[udance4ever]

tried to remove the files and the controller works fine until you try to remap controllers. so it’s something in the remap routine that is buggy.

trying to do the remap again (and ensuring I am pressing the correct buttons), the left analog is not moving the cursor correctly (left and right move down)

UDPATE: tried to delete ~/.sdl2 again, restart ES and the bad remap is persistent. (in fact, now the mapping of the ally gamepad is now corrupt - the D-pad can’t move left and right either). This is easily fixed by remapping the Ally gamepad but the 8BitDo remap is still not correct.

tried to remap the 8BitDo again and the bad remap is stubborn.

[dmanlfc]

Why do you need to remap the 8bitdo? Is the controller not supported out of the box with the correct configuration? Essentially, the values stored in the .sdl2 folder that batocera uses for analog may be incorrect. Try manually adjusting.

[udance4ever]

just sorry for the delay - just getting around to this issue now that I’m testing my x86 build of 41-dev

issue still persists. v41-dev is now able to pair with the 8BitDo Lite over BT and it works fine (but has input lag)

if I put a USB-C cable in - the controls are super wonky.

I think the problem has to do with when the controller is connected by wire, it’s interpreted as generically as an Xbox Controller.

I noticed a few months ago there were lots of xbox controller entries in a file with all the controller maps. perhaps there is clobbering going on with someone else’s controller that is hashing to the same Xbox controller entry?

Is there any way to make the system recognize the controller as an 8BitDo Lite controller over a wired USB connection instead of just generic X-input?