Screen doesn't wake up after sleep in Fedora KDE 44

Ask Fedora
,
1

inxi -ezxx

System:
  Kernel: 7.2.7-200.fc44.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 16.2.1
  Desktop: KDE Plasma v: 6.7.5 tk: Qt v: N/A wm: kwin_wayland dm: N/A
    Distro: Fedora Linux 44 (KDE Plasma Desktop Edition)
Machine:
  Type: Desktop Mobo: ASUSTeK model: B150M-A D3 v: Rev X.0x
    serial: <superuser required> part-nu: SKU Firmware: UEFI-[Legacy]
    vendor: American Megatrends v: 2604 date: 02/21/2018
Battery:
  Device-1: hidpp_battery_0 model: Logitech PRO X 2 serial: <filter>
    charge: 66% status: discharging
CPU:
  Info: quad core model: Intel Core i5-6400 bits: 64 type: MCP arch: Skylake-S
    rev: 3 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB
  Speed (MHz): avg: 800 min/max: 800/3300 cores: 1: 800 2: 800 3: 800 4: 800
    bogomips: 21599
  Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Graphics:
  Device-1: NVIDIA TU117 [GeForce GTX 1650] vendor: Gigabyte driver: nvidia
    v: 615.71.09 arch: Turing pcie: speed: 2.5 GT/s lanes: 16 ports:
    active: HDMI-A-1 empty: DP-1,HDMI-A-2 bus-ID: 01:00.0 chip-ID: 10de:1f82
  Display: wayland server: Xwayland v: 24.1.13 compositor: kwin_wayland
    driver: gpu: nv_platform,nvidia,nvidia-nvswitch display-ID: 0
  Monitor-1: HDMI-A-1 model: Mi Monitor res: 2560x1440 hz: 144 dpi: 109
    diag: 686mm (27")
  API: EGL v: 1.5 platforms: device: 0 drv: nvidia device: 2 drv: swrast
    gbm: drv: nvidia surfaceless: drv: nvidia wayland: drv: nvidia x11:
    drv: nvidia inactive: device-1
  API: OpenGL v: 4.6.0 compat-v: 4.6 vendor: nvidia mesa v: 615.71.09
    glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce GTX 1650/PCIe/SSE2
    display-ID: :0.0
  API: Vulkan v: 1.4.341 surfaces: N/A device: 0 type: discrete-gpu
    driver: nvidia device-ID: 10de:1f82 device: 1 type: cpu
    driver: mesa llvmpipe device-ID: 10005:0000
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor gpu: nvidia-settings,nvidia-smi
    wl: wayland-info x11: xdriinfo, xdpyinfo, xprop, xrandr
Audio:
  Device-1: Intel 100/C230 Series Family HD Audio vendor: ASUSTeK H110I-PLUS
    driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 chip-ID: 8086:a170
  Device-2: NVIDIA vendor: Gigabyte driver: snd_hda_intel v: kernel pcie:
    speed: 8 GT/s lanes: 16 bus-ID: 01:00.1 chip-ID: 10de:10fa
  API: ALSA v: k7.2.7-200.fc44.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.6.9 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin
Network:
  Device-1: Intel Wireless 7260 driver: iwlwifi v: kernel pcie:
    speed: 2.5 GT/s lanes: 1 bus-ID: 03:00.0 chip-ID: 8086:08b1
  IF: wlp3s0 state: up mac: <filter>
  Device-2: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: ASUSTeK RTL8111H driver: r8169 v: kernel pcie: speed: 2.5 GT/s
    lanes: 1 port: d000 bus-ID: 05:00.0 chip-ID: 10ec:8168
  IF: enp5s0 state: down mac: <filter>
Bluetooth:
  Device-1: Intel Bluetooth wireless interface driver: btusb v: 0.8 type: USB
    rev: 2.0 speed: 12 Mb/s lanes: 1 bus-ID: 1-10:4 chip-ID: 8087:07dc
  Report: btmgmt ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 4.0
    lmp-v: 6
Drives:
  Local Storage: total: 238.47 GiB used: 8.56 GiB (3.6%)
  ID-1: /dev/sda vendor: TeamGroup model: T-FORCE 256GB size: 238.47 GiB
    speed: 6.0 Gb/s serial: <filter>
Partition:
  ID-1: / size: 236.47 GiB used: 7.92 GiB (3.3%) fs: btrfs dev: /dev/sda3
  ID-2: /boot size: 1.9 GiB used: 662.2 MiB (34.0%) fs: ext4 dev: /dev/sda2
  ID-3: /home size: 236.47 GiB used: 7.92 GiB (3.3%) fs: btrfs
    dev: /dev/sda3
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 32.0 C mobo: N/A
  Fan Speeds (rpm): N/A
Info:
  Memory: total: 16 GiB available: 15.56 GiB used: 2.94 GiB (18.9%)
  Processes: 312 Power: uptime: 2m wakeups: 0 Init: systemd v: 259
    default: graphical
  Packages: pm: rpm pkgs: N/A note: see --rpm Compilers: gcc: 16.2.1
    Shell: Bash v: 5.3.9 running-in: konsole inxi: 3.3.41

cat /sys/power/mem_sleep

s2idle [deep]

Judging from the amount of posts in the fedora discussion it seems this is a widespread issue, but I have seen this resolved from people just updating whether their UEFI/BIOS or after a system update. But none of that is working for me because I already have the latest motherboad BIOS version and I’m currently using the latest build from Fedora, so I guess I’m SOL. Any help appreciated.

2

Can you verify again that your BIOS is updated? Whether this is actually the newest BIOS?

3

Yes I am using the latest BIOS version

image
image1275×861 59.8 KB

4

Please post output of

egrep -E 'FilePath|PreserveVideoMemoryAllocations|UseKernelSuspendNotifiers|PowerManagement' /proc/driver/nvidia/params

and cat /proc/cmdline

Is the system otherwise fully operational but the display, meaning can you ssh into the system?

5

egrep -E ‘FilePath|PreserveVideoMemoryAllocations|UseKernelSuspendNotifiers|PowerManagement’ /proc/driver/nvidia/params

PreserveVideoMemoryAllocations: 2
UseKernelSuspendNotifiers: 1
EnableS0ixPowerManagement: 0
S0ixPowerManagementVideoMemoryThreshold: 256
DynamicPowerManagement: 3
DynamicPowerManagementVideoMemoryThreshold: 200
TemporaryFilePath: ""

cat /proc/cmdline

BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.2.7-200.fc44.x86_64 root=UUID=23f94795-8607-4d3e-a80d-ceedeb66e131 ro rootflags=subvol=root rhgb quiet rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core

SSH into the system? What does that mean?

6

It means using ssh to log in into the system from another system. You would need to enable the ssh daemon on this system and use another system or smart phone or tablet with an ssh client to login.

Or have you tried to switch to a VT after resume? Ctrl+Alt+F4

7

I don’t really get your SSH procedure but I searched around and find that by pressing Ctrl+Alt+F3 and then Ctrl+Alt+F2 I can get to the usual login screen. Although this circumvents it this still doesn’t fix the problem that I don’t immediately return to the login screen after waking up.

8

So the system is alive, and youget the screen back after switching to a VT and back?
I assumed the screen remained dark.

9

When I pressed Ctrl+Alt+F4 there were some texts like Fedora KDE version number etc. I don’t know what that means, but I have to press Ctrl+Alt+F2 just to go back to the desktop again.

10

Looks like you have a simple workaround.

12

Well yea as I have said earlier it circumvents the issue, but it’s not really a solution. When my Windows PC went to sleep, I can just press the power button to bring me back to the login page, not 2 key combinations. And this black screen thing also happened when I tried Bazzite which is based from Fedora Kinoite, although I didn’t try the Ctrl Alt F3 and F2 back then.

13

Is the screen activated by a mouse movement or a keystroke after resuming operation?

look, this could be the nvidia driver having issue with particular monitors, or it’s a kde_win issue for some reason. Few months ago something similar happened on Gnome with nvidia drivers. After resume, displays would suspend again after 10-15s.

14

No, the screen was not activated by mouse movement or keystroke. It did wake the PC up.

15

when the PC was already active! ( after resume finished)

16

So that’s it, then? No permanent fix to this issue?

17

This is a wild guess - try setting the refresh rate to 60Hz. Does it return from sleep?

18

Maybe someone has an idea…
You could ask in Nvidia forums and discuss.kde.org

19

Wow this actually does work, I can get into the login screen without pressing the 2 keystroke combinations above, but this means I’m lowering my refresh rate, which is not ideal considering I’ve already used to 100+Hz from Windows.

20

decide what is more important to you :slight_smile:
A higher refresh rate or no longer having to use the workaround.

Actually this may all just work with a DisplayPort cable.

Are other refresh rates available like 100Hz or 120Hz?

21

I can confirm using the DP cable hooked into my Windows PC resolved this issue, and it also unlocked the full 180Hz for me (HDMI cable can only go to 144Hz). Which is good and at the same time annoying to me because:

  1. Why is there a different treatment between the 2 interface? In the sense that DP cable can get into the login screen without hindrance, while HDMI had to be limited to 60Hz
  2. My monitor only has 1 DP port, which is not practical if I have to change the cable every time I boot to another PC