I have read about so many issues regarding Bluetooth and Linux its ridiculous. Usually its random disconnecting, not auto reconnecting, not disconnecting properly, basically every issue possible. And ive had them too. I would really love it if i could just have my ps4 controller hook up right when I turn it on for example. Or have my shared speaker system actually disconnect when I turn off blnluetooth (it doesnt).
I’ve mostly only used mint with Bluetooth. Some popos but it had the same issues ofc. Only really used desktops, but also have issues on an atari vcs with mint and Bluetooth, exact same issues my desktop has.
Anyone know some real fixes? This is one of those things that makes it very hard to get people to switch when windows handles bluetooth devices perfectly (in my experience) and linux has just sucked so bad on that front.


Huh, I didn’t realize Bluetooth was still such a problem for some people. I’ve been using Ubuntu and cheap chinese Bluetooth earbuds with a Intel wireless/Bluetooth chip, and they’ve been fine. Haven’t really had many disconnect or connection issues.
Now the 10 year old integrated nvidia gpu on my alienware steam machine, on the other hand… Sleep just broke again when I did an apt upgrade yesterday, time to diagnose that, again. On 24.04 LTS if anyone was interested.
Lucky, it used to be Bluetooth wouldn’t work unless I shutoff my computer and turned it back on. I just stopped using it.
I’ve had a smoother time with Bluetooth since switching to Linux than I did on Windows.
On Windows it would randomly disconnect, or I would need to manually forget and re-pair the device every few months. Now when I turn on the device, it reliably reconnects to either my phone or the Linux device, depending on which one it was connected to last.
Maybe it’s distro / device dependent
Yeah I think a lot of people have crummy Bluetooth devices and Bluetooth is kind of a Dark Art in itself regardless of operating system but anytime something goes wrong that would have been the same way on Windows they just blame Linux because it’s new and they’re not used to it.
Have you added:
options nvidia NVreg_PreserveVideoMemoryAllocations=1options nvidia NVregTemporaryFilePath=/var/tmpto
/etc/modprobe.d/nvidia-graphics-drivers-kms.conf?This was the fix found here that worked for me, the file in the fix didn’t exist but this one was the only nvidia related conf file in modprobe.d and the fix worked and has persisted despite multiple driver updates.
I’m running kubuntu 25.04.
Thanks for trying! But that didn’t seem to work. My file had both of those lines but on the 2nd line had /var instead of /var/tmp. I added the /tmp and rebooting, but still doesn’t sleep. I guess I’m on the nvidia 580 drivers now, I think what had worked for the 470 drivers was the following bellow. I think doing a kernel upgrade messed me up, but I got rid of the previous kernel so not sure which I have to go back to to get it working again.
I actually did the opposite of this guide to see if that would work and it didn’t. Without the nvidia power management services , the device doesn’t sleep it comes right back on after a second of back screen, but with the services the device has a black screen, but is still on, not asleep and I can’t wake it so I have to hard reboot.
"Good news for affected users! I found a fix!
A LITTLE BACKGROUND You may already know that NVIDIA drivers on Linux rely on either of two different methods for power management ( as described here 68 ), which include:
Kernel Driver Callback: Works out of the box with no configuration required, but lacks advanced power management features and preserves only a portion of the video memory.
systemd (/proc/driver/nvidia/suspend): Provides advanced power management features and preserves complete video memory, but requires configuration and setup.
THE CAUSE Having mentioned the above, upon further inspection I found out the 470 driver migrated to systemd method while previous versions relied on Kernel Driver Callback. Apparently this is broken on some setups and kernels.
THE WORKAROUND Now it’s obvious we have to revert back to Kernel Driver Callback method for now that the systemd method is broken, and here’s how you can do that:
Disable NVIDIA systemd services sudo systemctl stop nvidia-suspend.service sudo systemctl stop nvidia-hibernate.service sudo systemctl stop nvidia-resume.service sudo systemctl disable nvidia-suspend.service sudo systemctl disable nvidia-hibernate.service sudo systemctl disable nvidia-resume.service Remove NVIDIA systemd script sudo rm /lib/systemd/system-sleep/nvidiaReboot and you should be able to suspend and resume properly with driver version 470.xx.
NOTE: Backup your configuration just in case, or downgrade the driver if this does not work on your setup. This was tested on Kubuntu 21.04 with GeForce GT 710."
I gotta say, after my last post I promptly upgraded my PC to 25.10 which immediately broke my Nvidia suspend, after a bit more investigation I found restarting the services you listed above fixed the issue. The fix persisted across restarts. I’m running an RTX 3060 so along with the 25.10 it’s a bit of a different setup from yours.
Mine (also Ubuntu, also Intel, but Sony earbuds) also works great.
Almost the only time in recent memory it hasn’t is when I’d accidentally kicked the cable out of the WiFi access point closest to the couch. My laptop was connected to one at the other end of the house, and it turns out that trying to stream video over 2.4GHz WiFi while listening on (also 2.4GHz) Bluetooth headphones isn’t a match made in heaven.
Now Windows on the other hand. My work laptop (also Intel Bluetooth adapter) starts out fine after a reboot, but over the course of a week will go from taking 2-3 seconds for the headphones to connect once powered on, to 30-40 seconds. Sometimes the headphones will connect, disconnect, and then connect again before actually making any sound.
The one thing the two OSes have in common is switching between 2-way voice (HFP) and high-quality music (A2DP) modes is a problem. In Linux it’s fairly reliable, but completely manual. In Windows it’s “automatic”, but frequently gets stuck in the wrong mode, or disconnects entirely when switching.