Bluetooth controller randomly disconnects (~10s) on Deck LCD — Wi-Fi/BT coexistence starves BT past the BLE supervision timeout (regression in 3.8.x)

[tvanantwerp]

Your system information

• Steam client version: 1782533657 (build date 2026-06-24 7:24pm UTC - 5:00)
• SteamOS version: 3.8.11 (BUILD_ID 20260620.1, codename holo)
• Kernel: 6.16.12-valve24-1-neptune-616-gc748040e4712
• Device: Steam Deck LCD model 1010 (radio module: Realtek RTL8822CE, combined Wi-Fi + Bluetooth)
• Peripheral Device Xbox Wireless Controller, model 1914
• Opted into Steam client beta?: No
• Opted into SteamOS beta?: No
• Have you checked for updates in Settings > System?: Yes

---

Summary

After updating to SteamOS 3.8.11, a Bluetooth (BLE) Xbox Wireless Controller randomly disconnects for ~10 seconds and then reconnects, repeatedly, during normal play. The problem was not present before the update.

Root-causing with btmon and the rtw88 coexistence debugfs shows the cause is broken Wi-Fi/Bluetooth coexistence arbitration on the shared RTL8822CE radio: the coexistence firmware handshake reports a version mismatch and a null BT firmware version, and the radio-grant arbiter holds GNT_BT = 0 (Bluetooth denied the radio) for 3–5.5 continuous seconds while the controller link is active. That exceeds the BLE link supervision timeout of 3000 ms, so the link dies with HCI reason 0x08 (Connection Timeout). This happens even with Wi-Fi on 5 GHz and lightly loaded, where Bluetooth should not be throttled at all.

Steps to reproduce

1. Pair a BLE Xbox Wireless Controller (PID 045E:0B13) to a Deck LCD running SteamOS 3.8.11.
2. Keep Wi-Fi on (observed on a 5 GHz network, channel 149, RSSI ~ -40 dBm).
3. Use the controller normally, undocked, within a few inches of the Deck.
4. Observe random ~10-second disconnect/reconnect events (no correlation with distance or the dock).

Expected behavior

The BLE controller stays connected. With Wi-Fi on 5 GHz, coexistence should grant Bluetooth ample radio time; there is no in-band conflict to arbitrate.

Actual behavior

The coexistence arbiter starves Bluetooth (GNT_BT = 0) for multiple seconds while the controller is actively communicating, exceeding the 3 s supervision timeout and dropping the link (Reason 0x08).

---

What was ruled out

• Dock / dock firmware — reproduces fully undocked.
• Range / signal — reproduces inches from the Deck; controller RSSI is ~ -58 dBm (strong).
• USB autosuspend of the BT radio — the btusb device (13d3:3553) stayed runtime_status = active throughout the drops; power/control = auto, delay 2000 ms, but it never suspended while connected.
• Connection parameters — negotiated params are normal/healthy (7.5 ms interval, 0 latency, 3000 ms supervision timeout).
• Intentional/auth disconnects — reason code is 0x08 (timeout), not 0x13/0x16 (terminated) or an auth/MIC failure.

---

Evidence / logs

1. HCI disconnect reason — btmon (multiple occurrences):

> HCI Event: Disconnect Complete (0x05) plen 4   [hci0] 2026-06-27 20:44:06.502284
        Status: Success (0x00)
        Reason: Connection Timeout (0x08)
> HCI Event: Disconnect Complete (0x05) plen 4   [hci0] 2026-06-27 20:45:56.342958
        Reason: Connection Timeout (0x08)

2. Negotiated BLE link parameters (healthy) — btmon:

LE Enhanced Connection Complete (0x0a)
        Connection interval:  7.50 msec (0x0006)
        Connection latency:   0 (0x0000)
        Supervision timeout:  3000 msec (0x012c)

3. Wi-Fi/BT coexistence state — /sys/kernel/debug/ieee80211/phy0/rtw88/coex_info (captured live while the controller was connected and in use):

Coex Ver/ BT Dez/ BT Rpt            = 22020720/ 0x20/ 0x00000000 (Mismatch)
WL FW/ BT FW/ BT FW Desired/ KT     = 9.9/ 0x0/ 0x0/ D
BT status/ rssi/ retry/ pop         = busy/ -58dBm/ 0/ 0
Profiles                            = HID(BLE) (multi-link 0)
Coex Mode/Free Run/Timer base       = 5G/ No/ 0
GNT_WL_CTRL/ GNT_BT_CTRL/ Dbg       = RF:SW_BB:SW/ RF:HW_BB:HW/ Off
GNT_WL/ GNT_BT                      = 1/ 0

Note (Mismatch) on the coex version and BT FW = 0x0 (the Wi-Fi firmware cannot read the BT firmware version) — the coexistence handshake is not completing. BT status = busy with GNT_BT = 0 is Bluetooth being denied the radio while it actively needs it.

4. Sustained BT starvation correlated with the drops (sampled GNT_WL/GNT_BT from coex_info every 0.5 s while playing; BT=busy throughout):

21:06:50.71  GNT(WL/BT)=1/0  BT=busy   <-- start of starvation
21:06:51.76  GNT(WL/BT)=1/0  BT=busy
21:06:52.82  GNT(WL/BT)=1/0  BT=busy
21:06:53.87  GNT(WL/BT)=1/0  BT=busy
21:06:54.92  GNT(WL/BT)=1/0  BT=busy   <-- ~4.5 s with GNT_BT=0 -> exceeds 3 s timeout -> drop

Longest continuous GNT_BT = 0 windows observed in one ~90 s session (supervision timeout is 3.0 s — anything past that drops the link):

starved 21:06:50.71 -> 21:06:54.92   (~4.5s)
starved 21:06:56.50 -> 21:06:59.13   (~3.0s)
starved 21:07:20.14 -> 21:07:25.40   (~5.5s)
starved 21:07:40.12 -> 21:07:43.28   (~3.5s)
... plus several ~2.0–2.5 s near-misses (stutters that recover)

5. Firmware versions in play — kernel log (dmesg):

rtw88_8822ce 0000:03:00.0: Firmware version 9.9.15, H2C version 15
rtw88_8822ce 0000:03:00.0: WOW Firmware version 9.9.4, H2C version 15
Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000c lmp_ver=0a lmp_subver=8822
Bluetooth: hci0: RTL: loading rtl_bt/rtl8822cu_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8822cu_config.bin
Bluetooth: hci0: RTL: fw version 0x3d7679d7

(Shipped firmware on disk: /usr/lib/firmware/rtl_bt/rtl8822cu_fw.bin.zst, dated Jun 4 2026, included in the OS image.)

6. Each drop re-registers the controller as a new HID device — kernel log (instance counter increments per reconnect, i.e. one line per dropout):

microsoft 0005:045E:0B13.0034: input,hidraw11: BLUETOOTH HID v5.15 Gamepad [Xbox Wireless Controller] on 14:d4:24:3a:a2:30
microsoft 0005:045E:0B13.0035: input,hidraw11: BLUETOOTH HID v5.15 Gamepad [Xbox Wireless Controller] on 14:d4:24:3a:a2:30
microsoft 0005:045E:0B13.0036: input,hidraw11: BLUETOOTH HID v5.15 Gamepad [Xbox Wireless Controller] on 14:d4:24:3a:a2:30

---

Analysis

The combination of (Mismatch) coex version + BT FW = 0x0 indicates the Wi-Fi (rtw88) and Bluetooth (btusb/rtl_bt) sides are not successfully exchanging coexistence information. As a result the grant arbiter defaults to favoring Wi-Fi (GNT_WL=1 / GNT_BT=0) for multi-second stretches even when Wi-Fi is on 5 GHz and nearly idle, starving the BLE controller link past its 3 s supervision timeout. This is consistent with a regression in the rtw88/BT-firmware coexistence path introduced in the 3.8.x image.

Suggested area to investigate

• rtw88 ↔ btusb/rtl_bt coexistence handshake for RTL8822CE in the 3.8.x kernel/firmware (why BT FW reads 0x0 and the coex version mismatches).
• Grant-arbiter behavior when Wi-Fi is on 5 GHz: it should not hold GNT_BT = 0 for seconds while a BLE HID link is busy.

Workarounds confirmed/expected

• Disabling Wi-Fi removes coex arbitration and is expected to stop the drops (offline-play workaround).
• Bypassing the internal combo radio (external USB Bluetooth dongle, official Xbox Wireless Adapter, or wired USB-C) avoids the issue while keeping Wi-Fi on.