GPIO Controllers not working anymore on v41 and v42

[TobiasDax]

Batocera build version

batocera-bcm2711-41-20241217

Your architecture

Raspberry Pi 4 B

Your Graphic Processor Unit(s) (GPU)

integrated

Issue description

I haver built an arcade station with two integrated controllers.
They are just basic switches that are wired up to the GPIO Pins of my raspberry pi 4 and the system worked great on Batocera v39.

Now i wanted to update and since the boot partition was to small i created a new boot drive with v41 (BTW the raspberry torrent download link links to v41 and not v42)

On v41 only 2 Buttons per controller are recogniced, i checked a lot of stuff but did not really make any headway into why.

Then i found this reddit post of people having similar issues: https://www.reddit.com/r/batocera/comments/1nk6vx3/pi4_b_gpio_arcade_controls_not_working_on/?show=original

something about how batocera handles gpio has changed and i would love for it to go back to how it was :)

For now i will downgrade to v40 and hope that it works

Detailed reproduction steps

Creasted a new boot device with v41 and now my controllers are no longer working

Details of any attempts to fix this yourself

worked through some stuff with AI, here is an AI summary of what i did:

Investigation Steps

1. Verified Driver Loading

cat /proc/bus/input/devices

Result: Two GPIO controllers detected (GPIO Controller 1 and GPIO Controller 2) at /dev/input/event4 and /dev/input/event5

2. Checked Driver Configuration

dmesg | grep -i "gpio\|mk_arcade"

Result: Driver mk_arcade_joystick_rpi loading correctly with default GPIO mappings:

• Controller 1: GPIOs 4, 17, 27, 22, 10, 9, 25, 24, 23, 18, 15, 14, 2
• Controller 2: GPIOs 11, 5, 6, 13, 19, 26, 21, 20, 16, 12, 7, 8, 3
• Peripheral base address: 0xfe000000 (Pi 4 address)
• Pad types: 1 and 2

3. Tested GPIO Response with evtest

evtest /dev/input/event4

Result: Only 3 inputs working from physical button presses

4. Systematic GPIO Pin Testing

Manually shorted individual GPIO pins to ground while monitoring with evtest:

Working GPIOs:

• GPIO 4 → ABS_Y (joystick axis)
• GPIO 14 → ABS_Y (joystick axis)
• GPIO 15 → ABS_Y (joystick axis)
• GPIO 18 → BTN_NORTH
• GPIO 2 → BTN_MODE

Non-responsive GPIOs:

• GPIO 17, 27, 22 (should be joystick directions)
• GPIO 10, 9, 25, 24, 23 (should be action buttons)
• GPIO 3 (tested, no response)

5. Checked Configuration Files

cat /userdata/system/batocera.conf | grep -i gpio

Configuration found:

controllers.gpio.enabled=1
controllers.gpio.args=map=1,2

6. Module Information

modinfo mk_arcade_joystick_rpi | grep parm

Available parameters:

• map: Enable or disable GPIO layouts (array of int)
• gpio: Custom GPIO numbers for Joystick 1 (array of int)
• gpio2: Custom GPIO numbers for Joystick 2 (array of int)

Additional Notes

• The pinctrl output shows all GPIOs are configured as inputs with appropriate pull-up/pull-down resistors
• Physical wiring has not changed and worked previously
• Issue appeared immediately after Batocera system update

Details of any modifications you have made to Batocera.

uncommented the conf options to activate the GPIO controller

Logs and data

see above

[henriquemenino]

I'm also having this problem and I chose to go back to version 39.
I built an arcade with 4 controllers (since 2016 when I was still using the RPI3 and in 2020 I changed to RPI4), 2 using the GPIO and 2 using board ARC-968 on the USBs.
The arcade has Batocera on a 32GB SD card and the ROMs are on a 64GB external drive on the USB.
Whenever I make the change, I install Batocera on another SD card and versions 41 and 42 have the right GPIO2 command active, making the screen scroll non-stop.

[Ruederox]

Hi
I managed to fix the 2-player GPIO arcade control mapping issue on Batocera v43 (Raspberry Pi 4) using the new gpiod v2.x and evdev libraries. Since the old mk_arcade_joystick_rpi driver is broken due to the updated RPi kernels, using a custom Python background service to emulate gamepads via uinput works perfectly. (1 Joystick per Player, 6 Actions Buttons and Start+Select per Player)

API v2.x Object Handling: In v43, request.get_values() returns a Value object (Value.ACTIVE / Value.INACTIVE) instead of pure integers. You must explicitly read the .value attribute, otherwise evdev crashes with a TypeError (int() argument must be... not 'Value').

Input Isolation for 2 Players: Emulating standard keyboard keys (KEY_UP, etc.) for both players simultaneously causes the EmulationStation UI to block inputs with an "Already taken" error. Mapping Player 2 to separate keys (like KEY_W, KEY_S, etc.) or using unique gamepads solves this menu conflict.

v43 Autostart Execution: Since custom.sh is deprecated, the script needs to be placed in /userdata/system/services/gpio_control.py and handled by a custom service loader via batocera-services enable. Permissions for /dev/uinput and /dev/gpiochip0 must be opened (chmod 666).

I ve got an How to and the needed Scripts. Google AI helped me a bit by the creation

gpio_control.py

How To.txt

ShellScripts.zip

[Ruederox]

I tried to analyze the source code and believe I found logical and structural bugs causing the failure under Kernel 6.18. You refactored the driver to use safe kernel wrappers (readl/writel) which fixes the compilation headers for 6.18, but the architecture is still using raw register masking instead of the actual <linux/gpio/consumer.h> gpiod framework. Because it's still reading the raw register, there is a minor logical bug making map=1,2 accept insertion without any errors, but the bit evaluation loop inside makes it fully deaf:

1. The Bitmask Evaluation Bug (Why map=1,2 inserts perfectly but stays deaf):
   Your macro <#579399028484341780>fine GPIO_READ(g) (readl(gpio + 13) & (1 << (g))) is mathematically 100% correct for the GPLEV0 register on the RPi4. However, inside mk_gpio_read_packet, you are evaluating the result with a strict zero-equality constraint:
   int read = GPIO_READ(pad->gpio_maps[i]);
   if (read == 0) data[i] = 1;

Because GPIO_READ returns the raw bitmask of the 32-bit register, the variable 'read' will only be exactly 0 if ALL 32 pins on the Pi are pressed down to ground at the exact same millisecond. Since unpressed buttons remain at 1 (High due to Pull-ups), 'read' is never 0, completely silencing START, SELECT, and the action buttons. Only Pin 4 (UP) barely triggers because it sits at the edge of the bit field evaluation.

-> The Fix: Change the loop condition to a proper bitwise check directly against the register:
if (!(readl(gpio + 13) & (1 << pad->gpio_maps[i]))) {
data[i] = 1;
} else {
data[i] = 0;
}

2. The Strict 12-Pin Boundary Validation Block:
   Inside mk_setup_pad_gpio, your custom mode enforces a rigid array size check:
   else if (gpio_cfg.nargs != 12) { return -EINVAL; }
   Because of this hardcoded check, any attempt to pass a larger custom array for 2 players (like 24 or 26 pins) instantly rejects the module insertion with "Invalid argument". The array int mk_arcade_gpio_maps_custom needs to be expanded to at least 26 elements and the nargs check adjusted.

[Ruederox]

`
/* - Fixed strict 12-pin limit, extended custom array

• • Fixed Active-Low logic in packet reading
• • Improved axis calculation for pull-up configuration
    */
    #include <linux/input.h>
    // ... weitere includes

/* FIX: Expanded buffer dimension from 12 to 26 (or 32 to have Space) */
#define MK_ARCADE_MAX_CUSTOM_PINS 32
struct gpio_config {
int mk_arcade_gpio_maps_custom[MK_ARCADE_MAX_CUSTOM_PINS];
unsigned int nargs;
};

// ... GPIO/MCP Reads

static void mk_gpio_read_packet(struct mk_pad * pad, unsigned char data) {
int i;
for (i = 0; i < MK_ARCADE_MAX_CUSTOM_PINS; i++) {
if(pad->gpio_maps[i] != -1){
/ FIX: Compares cleanly against the fixed 0/1 return state of GPIO_READ */
if (GPIO_READ(pad->gpio_maps[i]) == 0) data[i] = 1;
else data[i] = 0;
} else data[i] = 0;
}
}
`