Not typically advisable, security being quoted alot for that reason.
I see another thing that could be messing with it, i seen some lines in the prior journal logs that indicated something of a collision between blueman and bluez.
My thought process is that the kernel driver itself seems to be functional. Antenna functional. Power on and power off functional, it responds to commands but just doesnt display anything it finds if its even finding anything. So something between the driver getting loaded into kernel and the handoff to freedesktop is getting borked.
After boot, the kernel hands off command of the driver to blueman and kde desktop. Maybe one is trying to supersede the other.
Edit these:
Add this:
hardware.enableAllFirmware = true;
disable blueman
services.blueman.enable = false;
During my research, i seen some mentions of restarting the desktop display manager fixed the issue which seems to confirm the idea that its getting borked during hand off. Then again you arent getting dbus exception errors so maybe thats just a coincidence
hardware.pulseaudio = {
enable = false;
#package = pkgs.pulseaudioFull;
};
Remove this snip of code, or comment it out. Wireplumber does feature interfacing with PA, but that really only works when wireplumber is in charge. So activating PA at hardware level might be creating some problems, disabling it at hardware level seems like it would fuck with:
services.pipewire = {
enable = true;
alsa.enable = true;
alsa.support32Bit = true;
pulse.enable = true; # <<< Pulse is enabled here
# If you want to use JACK applications, uncomment this
jack.enable = true;
# use the example session manager (no others are packaged yet so this is enabled by default,
# no need to redefine it in your config for now)
#media-session.enable = true;
};
i also found this post, some similarities with your situation. Bluetooth troubles - #19 by DockterTeagle but this guys using a controller so it might not translate perfectly.
But this comment in particular:Bluetooth troubles - #6 by tealtydes is what makes me thing its related as you are both getting thrown a key error along with the missing plugins. (whos missing them? dunno)
Also, apparently setting this:
xdg.autostart.enable = true;
seemed to have a positive effect on integration with freedesktop so this is something worth trying to see if it fixes the problem.
There were also a few scattered mentions of bluetooth being managed by multiple parties, which could be the conflict we are looking for. If system and freedesktop try to command it at the same time, locking up would be the result in many cases.
We can easiliy see if this is the case by running:
$ hciconfig --all
It should vomit a ton of shit, if it does cool thats what we want
After, run this so we can see what the the bluetooth controller is and if its working and responding as expected.
$ bluetoothctl show
After this: run
$ rfkill list
and dump the output here