Black Screen After Sleep on Fedora KDE? My Culprit Was a Bluetooth Chip

Sanjai Shaarugesh — Mon, 09 Nov 2026 06:47:09 +0000

You close the lid, open it later, and get a black screen. No cursor, no login, just nothing. You wait, then you wiggle the mouse. Maybe you hold the power button and reboot.

That was me a few days ago, on Fedora 45 KDE running on a Lenovo IdeaPad Slim 3 (i5-13420H). The odd part is that the same laptop didn't do this on GNOME. So naturally I blamed KDE.

Turns out KDE was innocent. Here's the full story, and the two-minute fix if you have the same problem.

First, a quick explainer: what "sleep" actually is

Linux has two main ways to suspend a laptop:

Deep sleep (S3): nearly everything is powered off except your RAM. Great for battery.
s2idle: the CPU goes into a very light "idle" state while the machine stays partly awake. It's the Windows "Modern Standby" style.

You can check which ones your laptop supports with one command:

cat /sys/power/mem_sleep

Mine printed this:

[s2idle]

The brackets mean "currently active", and there was nothing else in the list. My laptop doesn't have deep sleep at all. Lots of newer laptops are like this, so any guide that says "just switch to deep" won't work for you.

Step 1: Make sure Linux really uses s2idle

I started from a KDE forum thread where someone had a similar black screen. Their fix was editing a file in /etc/elogind/. That's for systems running elogind. Fedora uses systemd, so the equivalent is:

sudo mkdir -p /etc/systemd/sleep.conf.d
sudo vim /etc/systemd/sleep.conf.d/10-s2idle.conf

Put this inside:

[Sleep]
SuspendState=freeze
MemorySleepMode=s2idle

Reboot. This makes sure Plasma doesn't try to pick a sleep mode your hardware can't do properly.

(Side note: my first attempt at this failed because I ran vim without sudo, so the file opened read-only. Classic.)

Step 2: Let the logs tell me what's wrong

Instead of guessing, I read the logs from the boot where it happened:

journalctl -b -1 | grep -iE "PM:|suspend|resume|kwin|drm"

The suspend itself was fine. But there were two lines that stood out:

PM: resume devices took 5.998 seconds
Bluetooth: hci0: RTL: download fw command failed (-110)

Resume should normally take well under 1 second. Mine was taking almost 6, and right next to it, my Realtek Bluetooth chip was failing to reload its firmware and timing out.

Here's what was happening:

The laptop sleeps, and Linux powers down the Bluetooth USB chip to save energy.
On wake-up, it asks the chip to start again.
The chip is slow to answer and times out.
The whole resume waits around for it. The screen looks black or frozen for those seconds.

So the black screen wasn't a KDE bug. A small chip was holding up the entire wake-up.

Step 3: The fix

The kernel module for that chip is called btusb. It has an option to stop it from powering itself down:

echo "options btusb enable_autosuspend=n" | sudo tee /etc/modprobe.d/btusb.conf

Reboot, then check it applied:

cat /sys/module/btusb/parameters/enable_autosuspend

It should print N.

The result

I suspended the laptop again and ran:

journalctl -b | grep -E "PM: suspend (entry|exit)|resume devices took|hci0.*-110"

PM: suspend entry (s2idle)
PM: resume devices took 0.314 seconds
PM: suspend exit

	Before	After
Resume devices	5.998 s	0.314 s
Bluetooth timeout errors	Yes	None

From about 6 seconds down to a third of a second, with one line of config.

What about battery life?

Fair question. s2idle drains more battery than deep sleep, and this fix keeps the Bluetooth chip slightly more awake. In practice:

Normal for s2idle: roughly 1-3% battery per hour while suspended.
To measure yours, unplug the charger, note the battery level, suspend for an hour or more, then compare:

cat /sys/class/power_supply/BAT*/capacity
cat /sys/power/suspend_stats/last_hw_sleep

The second number is how many microseconds your CPU spent in real deep idle. If it's close to the time you slept, things are healthy.

I haven't done my long overnight test yet, so I can't give you a real number. I'll update this post when I do. If you don't use Bluetooth much, turning it off in the tray recovers the little extra it uses.

If your problem comes back (or you have a different laptop)

Check what your laptop supports: cat /sys/power/mem_sleep
After a bad resume, reboot and read the previous boot's log: journalctl -b -1 | grep -E "PM:|hci0" | tail -30
Look for any device with a timeout or a resume devices took line over 1 second.
If it's the GPU instead, you can try i915.enable_psr=0 on Intel graphics:

   sudo grubby --update-kernel=ALL --args="i915.enable_psr=0"

Check for a BIOS update from your vendor. Mine was from 2023.

Undo any of this by deleting the file you created, or with --remove-args for the kernel parameter.

What I took away from this

Black screen after sleep sounds like a graphics or desktop problem, so that's where everyone looks first. But the logs said otherwise. If you read them before touching anything, a lot of "mystery bugs" turn out to be one small device.

If this saved you some rebooting, let me know in the comments. And if it didn't, paste your journalctl output there and we can poke at it together.

DEV Community: Sanjai Shaarugesh