wifi and bluetooth turns off

[Cezant64gamejr]

so im on arch and ran the recommended install and now whenever i run linux-soundboard in terminal it opens and everything else works but when i launch it it turns both my wifi and bluetooth off and i have to renable them in kde but other than that its fine and i have to switch output devices to and from my headphones to hear audio and it says something about width and height request properties how do i set them

[germanua]

Please, read the Instructions on how to submit a proper bug report. Currently, I am not sure what could be causing this issue, so I will need more information from you to investigate it further.
It would also be very helpful if you could provide some screenshots of what is happening.
Note: You don't have to start the application through the terminal every time. It is installed on your system as a standard application and can be found using your system's application search.

[Cezant64gamejr]

https://pastebin.com/Gzpzdrr7

would this be better?

[germanua]

Hey @Cezant64gamejr - thanks for the extra log, that's a big help. Looks like there are actually two or three separate things bundled together here, so let's split them up.

Wi-Fi/Bluetooth turning off

My leading theory is swhkd, the Wayland hotkey helper we launch directly (with a setuid binary, so it can grab your keyboard for global hotkeys). An exclusive grab like that can block other things listening on the same input device, including a laptop's Wi-Fi/Bluetooth toggle key if it lives on the same device node. Before I chase this further, a few things would really help:

1. Right after it happens, before re-enabling anything, run:

   rfkill list
   

   If Wi-Fi and Bluetooth both show Soft blocked: yes, that's a software toggle and points at swhkd. If they've vanished entirely, or journalctl -k shows firmware/reset errors around the same moment, it's more likely a driver-level issue - possibly tied to the Bluetooth problem below rather than hotkeys at all.

2. Test whether swhkd is actually the trigger by pulling its setuid bit and relaunching:

   bash/zsh:

   sudo chmod u-s "$(command -v swhkd)"

   fish:

   sudo chmod u-s (command -v swhkd)

   You'll see "Hotkeys unavailable" banner on next launch - that's expected. If Wi-Fi/Bluetooth survive after that, we've found it. Restore it afterward with:

   curl -fsSL https://raw.githubusercontent.com/germanua/Linux-SoundBoard/main/install.sh | bash -s -- repair
   

3. Or, without touching swhkd at all, force the X11 hotkey backend for one run (works fine inside a Wayland session, via XWayland):

   bash/zsh:

   LSB_FORCE_X11=1 linux-soundboard

   fish:

   env LSB_FORCE_X11=1 linux-soundboard

   If it doesn't happen this way either, that also points at swhkd.

4. Also: what does swhkd --version print, and does the drop happen the instant the window opens, or specifically when you trigger a sound through its hotkey?

Having to switch outputs to hear anything

I can already explain this one from your log — no more testing needed. Your Mic Passthrough source is set to your WH-CH720N's own microphone, and that same headset is also your default output. Most Bluetooth headsets can't run full-quality output (A2DP) and mic capture (HFP/HSP) at the same time, so it keeps swapping profiles — that's the repeated Failure in Bluetooth audio transport lines in your log — and the swap doesn't always come back cleanly.

Go to Settings → General → Microphone Source and pick a different mic if you have one, or turn off Mic Passthrough if you don't need your voice mixed into the soundboard's output. If you do need the headset's own mic, this is a PipeWire/WirePlumber+BlueZ limitation more than something we can route around on our end.

"width and height request properties"

I don't have the exact line - could you paste the full warning text from a terminal launch (not the system-info paste)? It's almost certainly a harmless GTK layout warning we need to fix on our side; there's no width/height setting in the app for you to change. I just need the literal text to know which widget it's coming from.

Thanks again for writing this up in detail - makes this way easier to actually track down.