waybar-bluetooth doesn't start for rfkilled devices on thinkpad

[grfrederic]

As in the title, if during waybars startup the bluetooth controller is blocked by rfkill the waybar-bluetooth module doesn't show up, even if its controller name is set in the config.

If I unblock the module and reload, it works as expected. If I then rfkill block/unblock the module dissapears on block, reappears on unblock.

I usually keep bluetooth off for power saving, so my workaround is to make systemd unblock all devices on boot and then turn off bluetooth with a script after waybar loaded.

[daangoossens22]

I don't get what exactly the problem is. In both cases you say the module dissapears when the bluetooth controller is blocked. Which indicates that you set "format-disabled": "". Maybe you are confusing the states when bluetooth is blocked or powered off, which are different?

[grfrederic]

Sorry, I'll try to be more precise.

If bluetooth is unblocked when waybar starts, the icon appears. If I block it, it dissapears. If I unblock it again, it reappears.

If on the other hand bluetooth is blocked when waybar starts, and unblocked after it starts, the icon doesn't appear (but bluetooth works, I can connect to headphones for example). If I then restart waybar, the icon comes back.

I believe the bluetooth module tries to get some information about the controller when loading and fails to do so if the controller is blocked at that time, but it handles it being blocked/unblocked gracefully if it happens at a later time.

I don't think power on/off matters here, I set the icon to be dim if power is off and brighter if it's on. This part works exactly as expected (ofc again, given waybar started when bluetooth was unblocked).

[grfrederic]

Actually your comment gave me and idea: I set format disabled to "@" so that I can distinguish it from the waybar-bluetooth not loading. I can confirm that if I start waybar with the controller unblocked waybar correctly displays @ after blocking it. If I start waybar with the controller blocked nothing appears, even if I unblock and power on the controller.

[daangoossens22]

Ok, I see now what the problem is. It is probably the same as #1603, since you say you unblock all devices using systemd. If so, make sure the systemd bluetooth service is running when waybar is starting, by executing systemctl enable --now bluetooth.service and if you want to block bluetooth use rfkill block bluetooth instead of disabling/stopping the service.

[grfrederic]

I checked, the bluetooth.service is enabled and running. Weird, seems like in #1603 they got it to load correctly even though the device was rfkilled on boot -- which is exactly what I want in the end.

I won't have access to the machine for some time now, I'll look more into it later. I use the bluetooth media key to rfkill the controller: I checked that it changes the state in rfkill list, but perhaps it also does something else I don't know about. If I remember right, after hitting it the controller doesn't show up in bluetoothctl. Should it still be there?

[daangoossens22]

Hmm, that is indeed weird. For me it also works fine, when I rfkilled bluetooth on startup. That no controller shows up in bluetoothctl show would indicate that waybar would also not find a controller on startup, which it needs to keep track of the connected devices of this controller. For me, the controller also shows up in bluetoothctl show when I blocked bluetooth. Maybe you can try if blocking/unblocking bluetooth via the terminal instead of the bluetooth media keys changes anything.

[grfrederic]

Well, I have some interesting new developments. Using rfkill directly instead of the media key doesn't change anything. But observe:

>  ~ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
	Soft blocked: no
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
11: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
>  ~ rfkill block bluetooth
>  ~ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
	Soft blocked: yes
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
>  ~ rfkill unblock bluetooth
>  ~ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
	Soft blocked: no
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
12: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

First, rfkilling bluetooth soft blocks tpacpi_bluetooth_sw but makes hci0 dissapear. And when unblocked it reappears (with a new, higher id no less!). I googled tpacpi_bluetooth_sw and seems like these are some thinkpad specific shenanigans enabled by the thinkpad-acpi kernel module (indeed I have it loaded).

When hci0 is not present in rfkill list, it is also not present in bluetoothctl show. I guess that explains the waybar-bluetooth not seeing it then.

[daangoossens22]

Interesting, I didn't know that was possible.

As a workaround, I guess the one you mentioned works, by making sure bluetooth is rfkill unblocked at startup and rfkill blocked after waybar has started. Or you can also try to block/unblock only hci0, but I don't know if that is the best thing to do since I have no idea what exactly tpacpi_bluetooth_sw does.

For this case to work natively, the code has to be changed, to track when controllers are added or removed with gdbus. Since currently, it only searches for a controller at startup, which I guess is sufficient for 99% of the cases. If anyone opens a pull request for this, feel free to ping me for a quick review.

[grfrederic]

Ok, thank you for helping me get to the root of this. I adjusted the issue title.

I'm not familiar with dbus and the workaround works reasonably well, I think for now I will just leave it at that. But if I have some free time and energy to attempt a fix, I'll let you know :)