fix: connect A2DP after pairing and enable JustWorksRepairing for BT headsets

[carroarmato0]

Summary

• PLAT_bluetoothPair() now calls bluetoothctl connect after bluetoothctl pair so the A2DP audio profile is opened immediately after bonding. Without this, earbuds time out (~2 s) waiting for the host to initiate the audio channel and disconnect themselves (BlueZ reason 2 = remote terminated).
• bt_init.sh now sets JustWorksRepairing = always in main.conf before starting bluetoothd. The XRadio BT controller firmware generates link keys with store_hint=0, so BlueZ never persists the key to disk. After a sleep/wake cycle the key is gone; with JustWorksRepairing=never (the BlueZ default) earbuds can't reconnect without the user re-pairing manually. Setting it to always lets the earbuds re-initiate the bond from their side on wake.

Fixes #467 (no sound after sleep when using BT headphones).

Root cause

The XRadio chip used in TrimUI devices sets store_hint=0 in the MGMT NEW_LINK_KEY event. BlueZ respects this flag and skips writing [LinkKey] to the device info file, so the device is never considered Paired=true. This means:

1. After pairing, nothing triggers an A2DP connection → earbuds disconnect in ~2 s.
2. After sleep/wake, the controller's volatile key memory is cleared and BlueZ rejects reconnect attempts from the earbuds.

Files changed

File	Change
workspace/all/common/generic_bt.c	Add bluetoothctl connect after bluetoothctl pair in PLAT_bluetoothPair()
skeleton/SYSTEM/tg5040/etc/bluetooth/bt_init.sh	Patch main.conf to JustWorksRepairing=always before bluetoothd starts
skeleton/SYSTEM/tg5050/etc/bluetooth/bt_init.sh	Same patch for tg5050

I've tested this using my Raycon Earbuds and seems to work reliably. Before this fix the earbuds would simply not connect (or get disconnected immediately)

[frysee]

I'm not sure this is working as expected. BT is always a bit of a clusterfuck, but at least with my XM-6s I do not get automatic reconnect after sleep with this patch.

[carroarmato0]

I'm not sure this is working as expected. BT is always a bit of a clusterfuck, but at least with my XM-6s I do not get automatic reconnect after sleep with this patch.

I've recently come in possession of a Smart Pro thx for a benefactor. I'll perform some extra tests and see what comes up. 😄

[carroarmato0]

As I mentioned yesterday on Discord, I started fresh without this PR:

• Brick: unable to pair
• Smart Pro: unable to pair

After reapplying my PR: both devices were able to pair with the Raycon earbuds.

On both devices, while playing a game (GB game through Gambatte), the sound works through BLE.
I put the device in sleep mode, wait a few minutes, and then turned it back on, the earbuds did not disconnect, and the sound continued to resume when the game was resumed.

When I disconnect the earbuds while the game is still on, I can see visually on the both devices that the disconnect happened (the volume bar appears, and shows the regular AMP symbol rather than bluetooth).
However, the game does not switch to the internal speakers unless the emulator is restarted.

When I turn the ear buds back on, they stay in pairing mode. They do not attempt to reconnect with the device, and the device does not attempt to reconnect as well. Which I think makes sense because when the device disconnects, it's removed from the cache code that I introduced. Maybe I should look into that.

[carroarmato0]

Two remaining issues found during testing that are out of scope for this PR:

Audio doesn't switch back to internal speakers mid-game

The disconnect is detected correctly (the volume bar updates to show the amp icon), so audiomon is doing its thing. The problem is that minarch opens the ALSA device at startup and holds onto it — when audiomon rewrites .asoundrc and flips the sink, minarch has no idea and keeps writing to the old device. You'd need minarch to either poll for audio config changes or handle a signal to reinitialize its audio output. Not something we should tackle here.

Earbuds don't reconnect after manual power-off/on

Sleep/resume works because bt_init.sh restarts bluetoothd on wake, which sets up the JustWorksRepairing context fresh and lets the earbuds re-initiate pairing from their side. Manual power cycle is different — bluetoothd stays running, the earbuds come back up and wait for the device to reach out, time out, and fall into fresh pairing mode instead of reconnecting. The device never proactively tries to connect to paired audio devices. Fixing this would need something like a background bluetoothctl monitor that watches for a trusted device to reappear and calls bluetoothctl connect <addr> for it.

Both are worth tracking as follow-up issues, but the current PR does it's job to pair successfully with my ear buds.
I think in the case of XM-6s because they operate differently, so additional patches might be needed

[carroarmato0]

@frysee what's in your /etc/bluetooth/main.conf and which device are you on?

[frysee]

@frysee what's in your /etc/bluetooth/main.conf and which device are you on?

Brick, and the defaults.

[carroarmato0]

Brick, and the defaults.

Ok, so same chip (XRadio), same device, patch applied, pairing works, but sleep/resume reconnect fails specifically with the XM-6s.

According to Jean-Claude:

The most likely explanation is that Sony XM-6s simply won't do JustWorks re-pairing after authentication fails. Here's what probably happens:

  1. Device wakes from sleep → bluetoothd restarts → volatile key memory cleared
  2. XM-6s come back and present their stored link key
  3. BlueZ rejects it (no matching key)
  4. Sony firmware treats this as a security failure and refuses to fall back to JustWorks — they either wait for user-initiated pairing or give up entirely

  The Raycon earbuds don't care — when they get rejected they just re-initiate as JustWorks and BlueZ accepts it via JustWorksRepairing=always. Sony XM-6s are premium headphones built with security in mind; they're designed to not silently re-pair without user intent.

  The actual fix for XM-6s (and likely other quality headphones) would be to preserve the link key across sleep despite store_hint=0. BlueZ by default respects that hint from the XRadio firmware and refuses to persist the key to disk. If we could override that,  essentially force BlueZ to store the key anyway — the XM-6s would reconnect fine because authentication would succeed on both sides.

[frysee]

BT just is a joy to work on, everything is so consistent.

[carroarmato0]

@frysee I submitted another patch. It looks like the device does not attempt itself to reconnect.
It looks like BlueZ loads all pairing data after restart but never initiates outgoing connections, it passively waits. Raycon-style earbuds reach out from their side (and JustWorks catches any key mismatch). Sony XM-6s and other premium headphones either expect the host to connect first, or give up rather than falling back to JustWorks re-pairing.

So give this a try, hopefully works for you