OrangePi Zero 3 Bluetooth Issues

[Paulman9]

Batocera build version

40 2024/08/10 12:13

Your architecture

Orange Pi Zero 3 4GB

Your Graphic Processor Unit(s) (GPU)

Integrated

Issue description

Bluetooth issues

Detailed reproduction steps

Installed this rc on my opi zero 3 4gb. Attempted to pair 3 different bluetooth controllers. Scanning works, selecting a device brings up the "Please Wait" message. This eventually goes away without any message and returns to the "Controller & Bluetooth Settings" screen. The device shows up in the "Forget a Bluetooth Device" menu, but it doesn't seem functional; controller mapping doesn't seem to recognise button presses, can't change player assignments for controllers. Same controller plugged in via USB works fine.

Details of any attempts to fix this yourself

No response

Details of any modifications you have made to Batocera.

No changes other than connecting to wifi (which seems to work fine)

Logs and data

batocera-support-20240814210753.tar.gz log after fresh boot > pair > attempt to map

[dmanlfc]

@Paulman9 it's trying to connect but timing out. The Bluetooth chipset on these boards are notoriously bad. You absolutely need the antennae attached to these boards to ensure BT works well. Is it?

[Paulman9]

@dmanlfc Yes I have a metal case with an external antenna. I tried removing the top of the case and getting the device even closer (i.e. touching) and it didn't seem to be any different. I had android on the device before with the same config and it worked well enough. Trying to copy roms over and wifi seems flaky as well, despite showing full signal (bad speed/disconnects). Unsure why the wireless chip is so unhappy when it seemed stable enough on the android image.

[dmanlfc]

@Paulman9 it's hard to say as we run a different kernel from Android but utilise the same provided wifi & BT drivers. See if another linux distro yields better results. It would be good to get some feedback so we can try to nail it for you.

[Paulman9]

@dmanlfc I just grabbed the debian bookworm image straight from orangepi to test again. It's using 6.1.31 and bluetooth connected just fine to my bluetooth keyboard. Downloaded from here: https://drive.google.com/drive/folders/1VPf5HCs5jva_J4Y8SfKOnGygWfuxVPiT Reimaged batocera v40 to a different sdcard to ensure no funny business there, and bluetooth still doesn't work. If you know of another image that would be a better test for you, let me know.

[dmanlfc]

@Paulman9 can you get a dmesg & lsmod output from the debian image please? you can drop to the terminal and do something like sudo dmesg > dmesg.txt and lsmod > lsmod.txt. upload the files here.

[Paulman9]

sure thing.

dmesg.txt lsmod.txt

Thanks for your help so far and let me know if there is anything further I can do to help here.

[dmanlfc]

everything is showing as working comparatively to batocera. i suspect a bluez stack regression crept in on this device.

[dmanlfc]

@Paulman9 on the working linux OS, find the file hciattach_opi copy that onto your Batocera system in /usr/bin via sftp or other overwriting the existing file. make sure you do batocera-save-overlay & then reboot. test that.

[dmanlfc]

@Paulman9 also try this early v41 upgrade - https://drive.google.com/drive/folders/1Zdsa5QAKJkN-znlUygaPLcvimf4Q-gav?usp=sharing

[Paulman9]

@dmanlfc replacing the hciattach_opi from the orangepi image didn't seem to make a difference for bluetooth, however, wifi was much faster and stable after doing so. Pretty sure the v41 image wouldn't have made if over wifi before doing that, nearly sustains 150Mbit without dropping out like before. v41 upgrade didn't seem to change anything beyond that, verified v41-dev 2024/08/19 13:24 in system info after.

[Paulman9]

batocera-support-20240820043311.tar.gz also new logs if it helps anything

edit: maybe it is different somewhat now? batocera seems to (sometimes) be convinced the device is connected in the interface, every device I've tried so far seems to disagree though

[dmanlfc]

yeah it's saying it connected sometimes... 2024-08-20 04:33:00,501 filter=E4:17:D8:2A:54:24, Icon=input-gaming, Address=E4:17:D8:2A:54:24 2024-08-20 04:33:00,501 event for 8BitDo Micro gamepad (E4:17:D8:2A:54:24, input-gaming)(paired=paired, trusted=trusted, connected=connected) try the new bluetooth device list option to see if it's listed & connect that way.

[Paulman9]

Yeah I add the device to the list somewhat consistently now. I can even force a "connection" from there if the device is on, but the device itself never leaves the connecting or pairing state (i.e. light keeps blinking like nothing has happened). It won't ever change to (connected) in the bluetooth device list if I try to force a connection and the device is off, so some level of communication seems to be happening, just not far enough for the device to actually work, as far as I can tell.

[Paulman9]

Actually... bluetooth speaker works just fine. Not sure what seperates the two but seems that bluetooth is working at some level right now

edit: slapped the v40 rc on another sd card and a bluetooth speaker also works there (pairing took a few tries, though)

[Paulman9]

Searching one of the errors lead me here where they mentioned setting UserspaceHID=false in /etc/bluetooth/input.conf. Fresh v40 image, setting this flag, save, and reboot, now my bluetooth controller (usually) pairs and works properly. Still a bit janky when setting up sometimes but seems to work properly (in limited testing) after doing so. I don't understand how this relates to the bluez issue referenced on that page as I'm not using a dualshock4 controller, but the userspace setting certainly makes a difference. I don't understand this enough to know the reprocussions of this setting, but hopefully this helps bring some light to this issue. If you'd like anything else tested with this configuration, let me know.

[dmanlfc]

That's interesting intel. We set CONFIG_UHID but as a module. Maybe we should try as core kernel component.