batocera-linux / batocera.linux

batocera.linux
https://batocera.org
Other
2.02k stars 522 forks source link

left D-pad input map for libretro/fbneo broken on clean install #11476

Closed udance4ever closed 7 months ago

udance4ever commented 7 months ago

Batocera build version

39 2024/03/04 10:11

Your architecture

x86_x64

Your Graphic Processor Unit(s) (GPU)

Integrated Intel Iris Graphics 6100

Issue description

Input bindings for Dpad are mapped incorrectly for libretro/fbneo core. If I go back to a 2nd instance of Batocera (also v39), it works just fine. I did a fresh install to a new USB stick and the issue is reproducible.

Detailed reproduction steps

  1. Use balenaEtcher to flash v39 to a new USB stick
  2. add fbneo rom of your choice (I used robotron)
  3. connect a gamepad via USB (do not connect via Bluetooth to keep things simple) (my gamepad is a 8BitDo Lite)
  4. go into Controller Mapping to ensure D-pad is assigned up,down,left,right
  5. verify D-pad controls ES navigation
  6. boot fbneo rom
  7. observe D-Pad left/right does not work

optional steps to confirm it’s not the hardware and isolate to just fbneo (and technically libretro/mame):

  1. boot another libretro core (ie. Snes9x) and rom (I used Castlevania)
  2. observe D-Pad left/right works just fine

I’ve attached a working system directory below in “attempts to fix this myself” to help with debugging

Details of any attempts to fix this yourself

I initially posted my findings on Reddit in this thread.

I’m able to toggle good and bad behavior at will swapping the following two system directories in this tarball:

system-debug-fbneo-input.tgz

see included README.txt for details. I’ve included recursive diff (which is quite short because I’ve minimized both system directories to 2.5MB (system.init - fresh install) and 29MB (system.working - has more retroarch history/config)

Details of any modifications you have made to Batocera.

no modifications. I made sure the issue is reproducible on a fresh install, without the network on the latest v39 release.

Logs and data

batocera-support-20240405151526.tgz

reminder that I’ve attached a tarball (tgz) of a pair of system directories - one that exhibits the defective behavior and one that is correct. the only differences are in the retroarch and ES directories (for the most part):

system-debug-fbneo-input.tgz

udance4ever commented 7 months ago

hmm - there is a tangential issue going on. at the end of the day, the proposed changes in my pull request fix the primary issue.

the heart of the problem may lie in how ES modifies es_input.cfg and makes it go corrupt if you do funky things like swap controllers p1 (8BitDo Lite) and p2 (M30 Modkit) like I just tried.

When I can reliably reproduce this 2nd issue, I’ll file a separate issue.

For now, I avoid swapping controllers and it’s stable.

The pull request specifically rolls back one specific inputConfig to its working v38 version.

udance4ever commented 7 months ago

the heart of the problem may lie in how ES modifies es_input.cfg and makes it go corrupt if you do funky things like swap controllers p1 (8BitDo Lite) and p2 (M30 Modkit) like I just tried.

tried stress testing the controller & BT stack yesterday by swapping/adding/forgetting/remapping controllers, pulling out cables midstream even hacking away at BT link keys - anything to try to confuse ES but couldn't!

my hypothesis is this eventually happens on a developer machine & the corrupted es_input.cfg gets checked into source. just a heads up.

going to let this all be until it happens again.