DualShock 4 Bluetooth issues

mrttime

New to RetroPie and have scoured the internet trying to find a solution but have no luck. Bluetooth connectivity will recognize the controller as a “wireless controller” but when I go into the security mode menu and select “DisplayYesNo” nothing happens. Gets hung up and the cursor is frozen. Doesn’t let me select it and starts imputing text at the bottom when keyboard is pressed. Help!

Pi Model or other hardware: Pi 4
Power Supply used: CanaKit 3.5A RaspPi 4 Power Sup
RetroPie Version Used: 4.7.1
Built From: Raspberry Pi imager_1.6.dmg
USB Devices connected:
Controller used: DualShock 4
Error messages received: no error message
How to replicate the problem: Go through Bluetooth connection process with DS 4 controller

mitu

Do an update for RetroPie and OS/packages to make sure you've got the latest version, then try to pair again the controller.
Make sure that the controller is still in pairing mode when choosing the security mode. Other settings should be let at default (i.e. connect mode) and before attempting to pair again, remove the device from the Remove Bluetooth device.

mrttime

@mitu Thanks for the reply. I updated the software and the OS and I’m still having the same issue. I can get through 90% of the setup but when I select “DisplayYesNo” from the security mode menu it doesn’t do anything and starts entering blank lines at the bottom. If I keep pressing enter the screen starts scrolling up.

mrttime

@mitu quick update. Got it to connect by installing the sixaxis driver but when I went to restart the raspberry pie it wouldn’t re connect. Uninstalled the Bluetooth wireless controller and tried reinstalling only to receive an error unable to connect. Sometimes I get the same issue as before and sometimes it can’t find the wireless controller.

endo

I can confirm the same exact bluetooth problem happening with my recent Pi4 4GB purchase running RetroPie 4.7.1 built using the the Pi Imager. What's more strange in my case is I also have a Pi400 working without any issues at all using the same SD with RetroPie installed which makes it seem hardware related but it's my understanding the hardware is the same between the two devices. On the standalone Pi4 I'm getting a series of errors from bluez stating it's not ready and I'm not able to power it on via bluetoothctl. I've used a separate SD and a new image with no success on the standalone Pi4 whereas it continues to work without issue on the Pi400.

mitu

@endo said in DualShock 4 Bluetooth issues:

On the standalone Pi4 I'm getting a series of errors from bluez stating it's not ready

This looks to be a different issue. Is bluetooth enabled ? Check what sudo rfkill list all reports.

mrttime

@mitu this software is so buggy and inconsistent. Sometimes I’ll get a bluez error, sometimes the wireless controller will have been connected without me even choosing the controller from the list of found devices (even after I have removed it from the list of connected devices). Other times it won’t find anything. Other times nothing happens and I can start inputting code at the bottoms of the splash screen. If I have the luck of it connecting by random chance (didn’t even get through to choose which device to connect and it connected automatically once) I won’t be able to re connect it on a different gaming session from boot even though the connect mode is set to boot. I’m beginning to think I made a big mistake running retro pie as an emulator.

mitu

@mrttime I'm regularly using a DS4 controller on a Pi4 (and before that, on a Pi3) and I don't have an issue, either pairing it or using it.
The Bluetooth pairing/connection part it a bit finicky indeed and sometimes requires a 2nd re-scan to find and pair the controller, but it should work.
Do you have any other devices connected to the Pi ? Do you have the Pi in a case or something similar that would interfere with the the Bluetooth wireless ?

mrttime

@mitu You’re telling me... Works fine plugged in but it’s been nothing but a pain to get it up and running in wireless mode. I don’t have anything else connected to it besides the keyboard I use to try and set it up. I have it in an official Raspberry Pi case. The case obviously doesn’t interfere with the Bluetooth connectivity because it’s finding the controller and other Bluetooth devices.

Update: latest error: An error occurs connecting to the bluetooth device (Creating device failed: org.bluez.Error.AuthenticationFailed: Authentication Failed)

mrttime

@mitu update: I thought it could maybe be that the PS4 controller is defective or maybe just a model that doesn’t comply with Pi4 but I tried my Xbox One controller and I got the same issue. Doesn’t accept input past security menu and the screen starts moving up with each enter input pressed. I’ll go into the Bluetooth menu to check if the device is synced and it shows the controller as being synced but won’t connect to the Pi.

endo

@mitu I've checked rfkill and all is unblocked. I've also tested bluetooth with the standalone Pi 4 with Raspberry Lite and the full Raspberry OS with desktop and all are stating org.bluez.Error.NotReady. When I use bluetoothctl to manually try setting up my controller (which works fine with my Pi400), the Pi 4 sees the controller, let's me pair with it, connects to it, and then immediately disconnects. All the while this is happening, the controller itself is still in pairing mode like nothing has actually happened. I'm debating whether to try and return the board as I just purchased it or just buy a bluetooth dongle and see if that works. Pretty frustrated with the whole process.

endo

After another round of research and troubleshooting, I found that running the command below prior to pairing the controller and after each reboot of the OS, works 99% of the time for me. The closest I've gotten to answer so far is laid out in this article on Github. It has to do with the order in which devices and services are starting. I tried the sleep method in the article with no luck. I'm going to keep searching to see if there is a better resolution until this gets resolved in the OS itself because I don't want to have to run that command each time I restart the Pi.

sudo systemctl restart bluetooth

@mitu have you seen or heard of this problem before? That article on Github is from 2018 but this still seems to be a lingering problem for some.

@mrttime hopefully this works for you like it did me so that you can at least move forward with a workaround.

mitu

@endo Can you post the contents of the /etc/bluetooth/main.conf file ?

Is the bluetooth service enabled ?By default it's enabled and automatically started at boot (you can check with systemctl status bluetooth).

endo

@mitu Below is the main.conf. I posted it as code as it was posting really large otherwise. I haven't modified this file manually at all. I did a restart and verified that the bluetooth service shows as active (running) using systemctl status bluetooth although I still have to execute sudo systemctl restart bluetooth for the controller to automatically reconnect.

[General]

# Defaults to 'BlueZ X.YZ', if Name is not set here and plugin 'hostname' is not loaded.
# The plugin 'hostname' is loaded by default and overides the Name set here so
# consider modifying /etc/machine-info with variable PRETTY_HOSTNAME=<NewName> instead.
#Name = BlueZ

# Default device class. Only the major and minor device class bits are
# considered. Defaults to '0x000000'.
#Class = 0x000100

# How long to stay in discoverable mode before going back to non-discoverable
# The value is in seconds. Default is 180, i.e. 3 minutes.
# 0 = disable timer, i.e. stay discoverable forever
#DiscoverableTimeout = 0

# How long to stay in pairable mode before going back to non-discoverable
# The value is in seconds. Default is 0.
# 0 = disable timer, i.e. stay pairable forever
#PairableTimeout = 0

# Use vendor id source (assigner), vendor, product and version information for
# DID profile support. The values are separated by ":" and assigner, VID, PID
# and version.
# Possible vendor id source values: bluetooth, usb (defaults to usb)
#DeviceID = bluetooth:1234:5678:abcd

# Do reverse service discovery for previously unknown devices that connect to
# us. This option is really only needed for qualification since the BITE tester
# doesn't like us doing reverse SDP for some test cases (though there could in
# theory be other useful purposes for this too). Defaults to 'true'.
#ReverseServiceDiscovery = true

# Enable name resolving after inquiry. Set it to 'false' if you don't need
# remote devices name and want shorter discovery cycle. Defaults to 'true'.
#NameResolving = true

# Enable runtime persistency of debug link keys. Default is false which
# makes debug link keys valid only for the duration of the connection
# that they were created for.
#DebugKeys = false

# Restricts all controllers to the specified transport. Default value
# is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW).
# Possible values: "dual", "bredr", "le"
#ControllerMode = dual

# Enables Multi Profile Specification support. This allows to specify if
# system supports only Multiple Profiles Single Device (MPSD) configuration
# or both Multiple Profiles Single Device (MPSD) and Multiple Profiles Multiple
# Devices (MPMD) configurations.
# Possible values: "off", "single", "multiple"
#MultiProfile = off

# Permanently enables the Fast Connectable setting for adapters that
# support it. When enabled other devices can connect faster to us,
# however the tradeoff is increased power consumptions. This feature
# will fully work only on kernel version 4.1 and newer. Defaults to
# 'false'.
#FastConnectable = false

# Default privacy setting.
# Enables use of private address.
# Possible values: "off", "device", "network"
# "network" option not supported currently
# Defaults to "off"
# Privacy = off

[GATT]
# GATT attribute cache.
# Possible values:
# always: Always cache attributes even for devices not paired, this is
# recommended as it is best for interoperability, with more consistent
# reconnection times and enables proper tracking of notifications for all
# devices.
# yes: Only cache attributes of paired devices.
# no: Never cache attributes
# Default: always
#Cache = always

# Minimum required Encryption Key Size for accessing secured characteristics.
# Possible values: 0 and 7-16. 0 means don't care.
# Defaults to 0
# MinEncKeySize = 0

[Policy]
#
# The ReconnectUUIDs defines the set of remote services that should try
# to be reconnected to in case of a link loss (link supervision
# timeout). The policy plugin should contain a sane set of values by
# default, but this list can be overridden here. By setting the list to
# empty the reconnection feature gets disabled.
#ReconnectUUIDs=00001112-0000-1000-8000-00805f9b34fb,0000111f-0000-1000-8000-00805f9b34fb,0000110a-0000-1000-8000-00805f9b34fb

# ReconnectAttempts define the number of attempts to reconnect after a link
# lost. Setting the value to 0 disables reconnecting feature.
#ReconnectAttempts=7

# ReconnectIntervals define the set of intervals in seconds to use in between
# attempts.
# If the number of attempts defined in ReconnectAttempts is bigger than the
# set of intervals the last interval is repeated until the last attempt.
#ReconnectIntervals=1,2,4,8,16,32,64

# AutoEnable defines option to enable all controllers when they are found.
# This includes adapters present on start as well as adapters that are plugged
# in later on. Defaults to 'false'.
AutoEnable=true

mitu

The config is ok - it looks like the stock config that's shipped with Raspberry Pi OS/RetroPie.

mrttime

@mitu Still getting connection issues. (Creating device failed: org.bluez.Error.AuthenticationFailed: Authentication Failed)

mitu

@mrttime Sorry, don't have any ideas about this one. You can enable debugging in the bluetooth service - see here - and provide a log from the pairing process (use pastebin.com for posting the log), maybe that will shed some light on the error.

mrttime

@mitu OK. Thanks anyway. In one last attempt to maybe figure it out when I get to the point of choosing the security mode and select 1 DisplayYesNo the cursor activates at the bottom of the blue screen and when I press the directional buttons I get output that looks like ^[[C^[[3^[[3^[[D^[[B etc. etc. depending on the key I press.

evancg

I have this exact same issue using a couple of different Retropie images. It might work the very first time I boot the image, but maybe not - and any following boots I have the same problem (also with a Pi 4).

evancg

@mrttime and @endo

I'm curious if you have the same issue I noticed I have from this thread:

https://www.raspberrypi.org/forums/viewtopic.php?f=140&t=306920

On boot, bluetoothctl and do a "list" to see what the MAC address of your bluetooth device on your pi controller.

Then perform a sudo systemctl restart bluetooth.service

Then go into bluetoothctl and do a list again to see if it's a different MAC address.

When I do this, I do get a different MAC address and at that point, I can connect to bluetooth devices as expected. I have no idea why it has this changing MAC address though. I think I've had this issue on 2 different Pi 4 units.

Editing: Restarting bluetooth.service doesn't always fix it - it seems more likely that just restarting bluetooth gives it a chance to get the right MAC address (which is why sometimes it always works on a reboot).