protonscr

Bluetooth Controller (Linux controller not actual device) powered off by steam in big picture mode session

steamopen Big PictureDistro Family: Fedora
ValveSoftware/steam-for-linux#8794 · opened 2022-09-12 by abc-mikey · updated 2022-12-26 · 6 comments · github
Aabc-mikey 2022-09-12 github

Your system information

  • Steam client version (build number or date): Sep 9 2022, at 23:46:16
  • Distribution (e.g. Ubuntu): Fedora
  • Opted into Steam client beta?: Yes
  • Have you checked for system updates?: Yes

bluez: 5.65
kernel: 5.19.8
steam-devices: 1.0.0.75

Bluetooth not working with steam.

Found by looking at bluetoothctl that Bluetooth Controller (Linux controller not actual device) was powered off when steam is running in a steamos session.

Trying to power on with bluetoothctl results in immediate power off.

[bluetooth]# list
Controller 28:7F:CF:62:09:D9 nixon [default]
[bluetooth]# show
Controller 28:7F:CF:62:09:D9 (public)
        Name: nixon
        Alias: nixon
        Class: 0x00000000
        Powered: no
        Discoverable: yes
        DiscoverableTimeout: 0x00000000
        Pairable: yes
        UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
        UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
        UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
        UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
        Modalias: usb:v1D6Bp0246d0541
        Discovering: no
        Roles: central
        Roles: peripheral
Advertising Features:
        ActiveInstances: 0x00 (0)
        SupportedInstances: 0x05 (5)
        SupportedIncludes: tx-power
        SupportedIncludes: appearance
        SupportedIncludes: local-name
[bluetooth]# power on
[CHG] Controller 28:7F:CF:62:09:D9 Class: 0x00000104
Changing power on succeeded
[CHG] Controller 28:7F:CF:62:09:D9 Powered: yes
[CHG] Controller 28:7F:CF:62:09:D9 Powered: no
[CHG] Controller 28:7F:CF:62:09:D9 Discovering: no
[CHG] Controller 28:7F:CF:62:09:D9 Class: 0x00000000

I also noticed an error reported by the bluetooth service that gets emitted when trying this:

Sep 12 13:59:19 nixon bluetoothd[987]: src/adv_monitor.c:btd_adv_monitor_power_down() Unexpected NULL btd_adv_monitor_manager object upon power down

However it works as expected from in a gnome classic session.

Aabc-mikey 2022-10-05 github

Here is a trace with btmon -w FILE for 2 scenarios:

  1. Start steam-session going directly into big picture mode only without a DE. Try to turn on controller (peripheral). Ctrl+Alt+F3 to switch to console and start bluetoothctl and try to power on.
  2. Start gnome-session starting steam then opening big picture mode. Turn on controller (peripheral) which connects.

gnome-session-steam-bpm.txt
steam-bpm-session.txt

And here is the script for starting the steam-session if that helps:

steamos-session.txt

Versions at time of these tests:

bluez: 5.65
kernel: 5.19.12
steam-devices: 1.0.0.75
Steam client version: Oct 4 2022, at 21:51:07

Aabc-mikey 2022-10-06 github

Response from the bluez support:

It seems something is requesting power off:

@ MGMT Command: Set Powered (0x0005) plen 1          {0x0001} [hci0] 137.172969
        Powered: Disabled (0x00)

It seems the steam client specifically in -steamos mode is actively powering off Bluetooth.

Ttognee 2022-11-26 github

Can reproduce on Endeavour OS (an Arch based OS)

I need to restart the bluetooth service to make it work during that session

Ttognee 2022-11-29 github

This also happens with the -steamos3 argument

Ww0utert 2022-12-25 github

Same problem here. Every time Steam BPM starts I need to restart the Bluetooth daemon (which will then also power up the BT controller again) to fix this, after this my Bluetooth gamepad works again.

Interestingly, if I power down the controller manually in a state where everything works (using ‘power off’ in bluetoothctl) the Bluetooth daemon does not log anything (as expected). I can cleanly power off/on as much as I want without errors. This in contrast to whatever the steam client does, which triggers the ‘unexpected NULL’ log message reported by @abc-mikey. So it seems not only the steam client is trying to power down Bluetooth, but it is doing it wrong, or at least in a way that breaks the system Bluetooth daemon.

This is using Arch on kernel 6.1.1 and bluez 5.66

Ww0utert 2022-12-26 github

Additional information: I found out the problem goes away if I remove the ‘-steamos’ parameter when starting steam.

In my setup steam is started through steamcompmgr, which by default launches steam with -steamos, somehow this triggers some code path in the steam client that messes with the Bluetooth stack. So far I have not experienced any feature regressions by removing this parameter, at least for my use case. Still it may be worth investigating and fixing the source of this issue when using -steamos

Edit: I just only now see it was already reported by @abc-mikey that the issue is related to the -steamos mode. Should provide a good clue for finding the root cause. It’s not really clear to me what this switch exactly does and what the implications of simply not passing it are (I don’t see a lot of difference in behavior except some ugly mode switching and update progress bar during startup)

Nothing extracted yet.