Hello,

 

I am testing vendor kernel + Ubuntu 24.04 on my board and found an issue with the Bluetooth desktop application.

 

The Bluetooth adapter itself works normally. After enabling Bluetooth from the desktop UI, hciconfig -a shows the Bluetooth device correctly.

 

However, when I click the Bluetooth device in the Blueman interface to open the device window, the Blueman window becomes stuck and stops responding.

 

The strange thing is that if I restart Blueman manually using:

 

killall blueman-manager

export DISPLAY=:0

blueman-manager

 

the Bluetooth manager window opens normally, and device scanning works correctly.

 

However, after closing it and trying to open the device window again from the desktop Bluetooth icon, the problem happens again.

 

I also tested the Bluetooth function using bluetoothctl, and pairing/scanning operations work normally, so I believe the Bluetooth hardware, BlueZ service, and kernel driver are working correctly.

 

Could this issue be related to the desktop session, XFCE login environment, DBus session, or Blueman autostart process?

 

What would be the recommended way to debug this issue?

 

Thanks

Edited September 23Sep 23 by Boardcon-Liuy

I just built and troubleshot kernel:rk-6.1-rkr7.2

So I asked Claude as my thoughts are your desktop environment being the difference.

Claude's reply

Hi, We run GNOME (gnome-bluetooth) on our RK3588 image, not XFCE + Blueman, so I can't reproduce this directly. One detail in your post stands out, though: the copy that works is started with "export DISPLAY=:0", i.e. from SSH or a serial console, outside the desktop session. The copy that hangs is started by the tray applet inside the XFCE session. That difference matters for polkit. Blueman does some operations through its privileged helper (org.blueman.Mechanism), which asks polkit first. For a process in a local desktop session, polkit typically answers "ask the user" and waits for an authentication agent to show a password dialog. If no agent is running in the XFCE session, that call just waits, and the window looks frozen. For a process started from SSH/serial, polkit usually refuses immediately, Blueman handles the refusal, and the window works. That would match "manual start works, every start from the icon hangs". We saw the same session-dependent polkit behaviour on our own image this week (with rtkit/PipeWire, not Blueman). Things worth checking:

1. Is an authentication agent running in the XFCE session? pgrep -a polkit If you only see polkitd (no polkit-gnome-authentication-agent-1, xfce-polkit, lxpolkit...), that is the first suspect.
2. Where exactly is the frozen window stuck? Blueman is Python, so: sudo py-spy dump --pid $(pgrep -f blueman-manager) (py-spy is available via pip).
A pending D-Bus call to org.blueman.Mechanism or polkit would confirm it.
3. Compare the environment of the frozen instance with a working one: tr '\0' '\n' < /proc/$(pgrep -f blueman-manager)/environ | grep -E 'DISPLAY|DBUS|XAUTH|XDG_SESSION' A D-Bus-activated instance without DISPLAY or with the wrong session bus is the other common cause of this kind of hang.
4. Or run the applet with debug output from a terminal inside the desktop: killall blueman-applet; blueman-applet --loglevel debug then click the icon and see where it stops. If the agent is missing, installing one (for example policykit-1-gnome on Ubuntu 24.04) and making sure it starts in the XFCE session (Session and Startup -> Application Autostart) should fix it.

Disclosure: I used an AI assistant (Claude) to analyse your report and draft this reply. The polkit behaviour it's based on is something we measured on our own image; your Blueman case itself I haven't reproduced.

Edited September 24Sep 24 by defcom5-rockchip