After much searching, I found this link https://github.com/goodtft/LCD-show/issues/278 for an issue with an LCD display I tried to use years ago. Apparently, it updated my /boot/cmdline.txt file to put ttyAMA0 in my console, instead of the default serial0. Swapping it back to console=serial0,115200 and rebooting, and now bluetooth works again!
I use a Pro Controller with the Pi thanks to those instructions. It works wired and wireless.
Did you have any error messages while installing either the HID module or the userspace driver?
How are the lights on the controller behaving when you connect the cable? Do they start blinking "side to side" quickly? If they do, did you press L + R to pair?
I tried multiple solutions suggested here, but to no luck. In the end, I just started the whole installation all over again and it's working fine now. God knows what happened, but it seems re-installing everything seems to have fixed it... weird.
They were on the latest update.
I already figured it out for myself.
I've uninstalled the xpad and xpadneo drivers from the RetroPie setup utility.
Then I installed the latest neoxpad driver from github, with this patch applied: https://patch-diff.githubusercontent.com/raw/atar-axis/xpadneo/pull/283.patch
Finally I edited the /etc/modprobe.d/99-neoxpad-bluetooth.conf file, comment out the disable ertm thing and make sure to load it with xpad emulation enabled:
# options bluetooth disable_ertm=y
options hid_neoxpad xpad_emulation=1
Reboot and pair both controllers in xpad mode.
Setup both controllers in emulationstation and skip the non-working left and right triggers.
When done simply close emulationstation and add the triggers manually:
input_r2_axis = "+5"
input_l2_axis = "+2"
Both controllers working in x-input mode, without the shitty startup delay when launching retroarch and working rumble for my psx and dreamcast games.
Got it working right after the update, you are master! Thank you very much, you saved many frustrations=)
And luckily the fix commit itself wasn't too long (just quickly browsed it through) but it was clever.
@edward_ci that's how I understand it, yeah. As far as the emulator is concerned, it's just another USB gamepad. If the two gamepads have identical device names/IDs, then they'll use the same config file. So whatever mapping like button_12 = "A" or whatever is set in the config file, will be the same for both gamepads. If "button 12" is whatever button is wired in position "6F" on the board or whatever, and you have that wired to a different physical button, then your "A" button will be that different physical button. They need to be exactly the same.
You can choose a hotkey enable button when you configure your gamepad and this will set it also in RetroArch so you can trigger an action with 2 button combos - see https://retropie.org.uk/docs/Controller-Configuration/#hotkey.
However, this is an emulator feature (RetroArch) and not a global/general input configuration option that will work in any program (including EmulationStation).
If you don't have a 'retropad A' button defined, of course it's not going to work in the menu . My remark was:
How the button is mapped to the underlying core doesn't matter for the menu (RGUI or otherwise).
I agree, but the reason that I don't have a retropad A button defined is because the core doesn't use it for it's logical function in the mapping. I could have had both [N64 "A" and RGUI "A"] if the core used different bindings.
Obviously this is a minority problem for people trying to use pads without the full set of retroarch inputs, and I can still navigate the RGUI using a keyboard in my case :)