Fedora KDE Custom Patches

2026-08-07.md

Laptop not suspending on lid close

Symptom: Closing the lid only turned off the screen; the laptop stayed awake (fans running, network alive).

Root cause: Not a KDE/logind config issue. The kernel's btintel_pcie driver (Intel Bluetooth over PCIe, controller a876 at PCI 0000:00:14.7) was failing its PCI suspend callback with -EBUSY:

btintel_pcie 0000:00:14.7: PM: pci_pm_suspend() ... returns -16
PM: Some devices failed to suspend, or early wake event detected
systemd-sleep: Failed to put system to sleep. System resumed again: Device or resource busy

This aborted systemd-suspend.service every time, and the system woke back up within ~1–4 seconds — fast enough that only the screen-blank was noticeable.

• System: Fedora 44, kernel 7.1.6-201.fc44.x86_64, sleep mode: s2idle only (no S3/deep sleep on this hardware)
• Confirmed via: journalctl -k -b | grep -i btintel and systemd-inhibit --list
• Ruled out: KDE PowerDevil lid-switch handling (was fine — it correctly owns handle-lid-switch via a block inhibitor), kernel/firmware updates (already fully current, no fix available upstream yet), Bluetooth rfkill soft-block (doesn't touch the PCI binding, so doesn't fix it alone)

Fix applied: A systemd-sleep hook that unbinds the Bluetooth PCIe device before suspend and rebinds it after resume, working around the driver bug without disabling Bluetooth permanently.

/usr/lib/systemd/system-sleep/btintel-pcie-fix (root:root, mode 755):

#!/bin/sh
case "$1" in
  pre)  echo "0000:00:14.7" > /sys/bus/pci/drivers/btintel_pcie/unbind ;;
  post) echo "0000:00:14.7" > /sys/bus/pci/drivers/btintel_pcie/bind ;;
esac

Installed with:

sudo install -m 755 -o root -g root <source> /usr/lib/systemd/system-sleep/btintel-pcie-fix

install does copy + chmod + chown in one step; no service enable/restart needed — systemd-logind runs every executable in that directory automatically around every suspend/hibernate/resume.

To revert:

sudo rm /usr/lib/systemd/system-sleep/btintel-pcie-fix

No other system state was touched — deleting the file fully restores default behavior.

Verified fixed: Journal shows systemd-suspend.service completing with res=success (previously always 1/FAILURE), no more btintel_pcie suspend errors, Bluetooth firmware reloading cleanly on resume.

Loose end (unconfirmed, self-resolved): Right after the first successful re (kscreenlocker_greet) logged one pam_unix(kde:auth): authentication failure on a fingerprint attempt. PAM stack for fingerprint is authselect's fingerprint-auth (pam_fprintd.so before falling back to password). Fingerprint worked again on the next try and hasn't recurred — worth keeping an eye on if it comes back after future resumes