Won’t suspend when put to sleep with Bluetooth controller
This has been driving me nuts for days while I have been trying to figure out what’s causing the issue. I seem to have narrowed it down to when the PC is put to sleep with a Bluetooth controller connected, it doesn’t actually go to sleep. Monitor is blank, but fans keep spinning. Can’t wake it from sleep once it happens. I have to hold the power button until it shuts down. I have tried googling to see if anyone else has had an issue like this, but I can’t seem to find a solution. Appreciate any help provided.
Specs:
Asrock A520M-ITX AC
Ryzen 3900x
16 gb hyperX fury @3200
RX 7900 GRE
Samsung 960 NVME
9 Replies
Gonna need to run
rpm-ostree status -bv and paste the output in here pls
Just to check what version is causing this issueGood afternoon, here is the output:
State: idle
AutomaticUpdates: disabled
BootedDeployment:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-deck:stable (index: 1)
Digest: sha256:b500b47741b798a83987e5d502f5b4a5fe4eaa86514ad29fb066e95889ff831a
Version: 40.20240731.0 (2024-07-31T16:45:14Z)
BootedCommit: c54576c45134913489eff9f7929d6086aa34cd6c8410aa6973346baa99bc0ae7
LiveCommit: 9c4aa37459d086ee293b02e26ce8a6fa56d4b293f90ad9eb72974d5b14edd039
LiveAdded: libayatana-appindicator-gtk3-0.5.93-5.fc40.x86_64
libayatana-ido-gtk3-0.10.2-1.fc40.x86_64
libayatana-indicator-gtk3-0.9.4-3.fc40.x86_64
miniupnpc-2.2.5-5.fc40.x86_64
sunshine-2024.729.24508-1.fc40.x86_64
StateRoot: default
Unlocked: transient
Index 1? Seems like you have an update pending. Try restarting so it gets applied and check if the issue persists
Oh wait nvm it's a transient thing
Forget what I said
@Struggz I think I might have a possible solution. Paste this in the terminal and try putting the PC to sleep with the controller connected:
Yes that worked! Thank you so much!
Oh nice, then I think we found the reason of why it hangs with Bluetooth controllers (seems a recurrent thing).
That will stop working after you reboot (
/run/ directories get wiped each time).
If you want to make this a persistent thing across reboots, you can run this in the mean time:
Awesome! Thanks again
I've been having the same issue and finally figured out that it was the controller and not the dock/HDMI. I gave the second solution a try and it's working as expected in last couple of days.
@Zeglius sorry for tagging in an old post. Is there any reason why the filename is deleteme and the message contents mention deletion? Maybe it was a reminder for you to look at a later time for a fix using an update?
Yeah, it is kind of experimental.
We tried to ship that override in bazzite, but there were a lot of cases breaking sleep in other devices,
So got reverted. And so, this workaround should be used on an individual basis
Got it. Thanks!