Gamepad does not work on Raspberry Pi Chromium browser

[mattiasaksli]

I'm trying to play the WebGL build of my game on the Chromium browser on a Raspberry Pi 4. If two controllers are paired with a dongle, the browser only recognizes input from the last connected Xbox controller, even though the xow status shows that both controllers are connected. No such issue happens on Firefox (though it has awful WebGL performance on the Pi), or when I try to play my game natively. The same issue happens on other websites as well, like this gamepad tester, so the issue seems to be between xow and Chromium.

[kakra]

Chromium has a very strange implementation of the gamepad API where it looks at evdev devices to map the buttons and axes but actually reads the input values from the joydev devices. For this to work, it needs some boilerplate code to read device paths via udev and match the device files, and even apply some hard-coded fixups for known mismatches. Maybe something goes wrong here... All of this black magic wouldn't be needed when using evdev alone. xow is a uinput driver implementation in user space, would be interesting to see if other uinput implementations behave the same, or maybe uhid implementations (like BLE input devices via bluez).

I could imagine that Firefox works differently, or just uses SDL. SDL uses evdev devices only, joydev isn't needed. Firefox probably does the same and doesn't look at joydev at all. You could look at the source code of both browsers to compare from which of the device files the input data is read. But Chromium surely has one of the strangest implementations I've ever seen. I've looked at it while debugging some strange mapping issues in Chrome with the xpadneo driver, and they really mess things up by assuming that one device matches the mapping from another completely unrelated device (in terms of "completely different code path with distinct mapping rules", they are still fed from the same source data of course).

You could also check if the second controller in xow really creates another /dev/input/js* device. If it doesn't, then it's probably a bug in xow, and then it's clear why Chromium doesn't work. Otherwise, it's clearly messed up in Chromium and should be reported there.