Linux PC with NVIDIA RTX does not wake up TV connected to HDMI automatically

Graphics / Linux Linux
, , ,
1

This is a bug that has bugged me ever since I purchased the RTX 4090. Maybe close to 2 years now. I have gone from Fedora 37 and now up to Fedora 42 with the same issue.

The same PC when it runs Windows 11, it works fine. Windows will trigger a wake up on the TV and let the TV to wake. I have a Mac Mini connected to the same TV and Apple TV connected to the same TV. They all behave the same way, they all will wake up the TV when peripherals wake up the device. Eg remote trigger wake up on the Apple TV. Keyboard tap wakes up Mac Mini and TV turns on.

Now, the issue with Linux Fedora 42 is somewhat infuriating. I have narrowed down to this specific sequence where it wont work.

  1. Turn ON TV manually by TV remote (while PC is OFF)
  2. Turn on PC and login to PC
  3. Let the PC to auto sleep (~15mins) and TV will auto sleep (~40mins)
  4. Tap on keyboard (PC will wake up) but TV remained OFF
  5. <----> this is where the problem
    5.i turn ON TV by TV remote, change the HDMI source for the PC, it says “no HDMI connection detected”
  6. At this point Fedora is at login screen. No matter what you do, the TV will not work, unless you reboot Fedora WHILE the TV is ON.

After step 7, I either have to SSH to my Fedora from my iPad and ‘sudo reboot’ or I have to press reset button on the Fedora.

PC specs:

  1. Gigabyte RTX 4090
  2. Gigabyte B650M AORUS Elite
  3. AMD Rizen 9 7900
  4. OS Fedora 37, 38, 39, 40, 41, 42

Note: I posted this issue on Fedora KDE forum, they said this is NVIDIA driver bug, asked me to post here.

nvidia-bug-report.log.gz (640.8 KB)

2

Are you sure it’s an issue with the GPU not waking the TV, or maybe the GPU doesn’t properly wake to begin with, hence no signal detected by the TV? Did you try to check nvidia-smi via SSH when this condition hits?

That said, always start troubleshooting by reviewing (and sharing :)) the logs. Or better yet, a bug report, as instructed here: »»»»»»»»»» If you have a problem, PLEASE read this first ««««««««««

3

thanks @catt for the response.
I wanna say, the GPU does wake up, at least judging from the GPU fan + the fancy gaming flickering LEDs and stuff (not sure what kids call them these days).

But of course, when time to reproduce the issue - and generate the report, it is “working” for some reasons. Maybe the TV hasnt slept long enough (deep sleep). I will try to reproduce this again overnight.

Either way, I generated the nvidia-bug-report for now (attached in the main post). And will generate another one should I was able to reproduce the issue.

Note: I also updated to Fedora 43 today, seems like it came thru the updates.

4

Hi @catt , I have replicated the issue. Definitely if I leave the PC to auto sleep by itself and the TV autosleep by itself overnight (not sure how long it needs to be before the issue shows, maybe deepsleep TV or something).

I have also attached the log file “nvidia-bug-report-reproduced.log.gz”

Below is nvidia-smi output:

Mon Nov 3 18:41:22 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.95.05 Driver Version: 580.95.05 CUDA Version: 13.0 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 4090 Off | 00000000:01:00.0 Off | Off |
| 0% 24C P8 14W / 450W | 1013MiB / 24564MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 1788 G /usr/bin/ksecretd 6MiB |
| 0 N/A N/A 2090 G /usr/bin/kwin_wayland 16MiB |
| 0 N/A N/A 2195 G /usr/bin/maliit-keyboard 212MiB |
| 0 N/A N/A 2204 G /usr/bin/Xwayland 41MiB |
| 0 N/A N/A 2254 G /usr/bin/ksmserver 6MiB |
| 0 N/A N/A 2256 G /usr/bin/kded6 6MiB |
| 0 N/A N/A 2280 G /usr/bin/plasmashell 367MiB |
| 0 N/A N/A 2374 G /usr/bin/kaccess 6MiB |
| 0 N/A N/A 2375 G ...it-kde-authentication-agent-1 6MiB |
| 0 N/A N/A 2377 G ...ibexec/xdg-desktop-portal-kde 6MiB |
| 0 N/A N/A 2591 G /usr/bin/kdeconnectd 6MiB |
| 0 N/A N/A 2708 G /usr/bin/xwaylandvideobridge 6MiB |
| 0 N/A N/A 2742 G /usr/libexec/DiscoverNotifier 6MiB |
| 0 N/A N/A 22753 G /usr/bin/krunner 25MiB |
| 0 N/A N/A 22814 G /usr/libexec/baloorunner 6MiB |
+-----------------------------------------------------------------------------------------+

Let me know if there is anything I can do to help.

Note: TV model is TCL QM8

nvidia-bug-report-reproduced.log.gz (645.4 KB)

5

It does look like the GPU wakes up successfully. Hopefully NVIDIA can review the bug report and figure this out.

Also, a new driver was published today, which fixes a HDMI issue that may be applicable? https://www.nvidia.com/en-us/drivers/details/257493/
But if you installed the driver via RPM Fusion, it may take some time for this update to become available.

1 Like
6

Thanks @catt - those HDMI fixes do sound promising, especially I am running 4k@144Hz . I will wait for it to propagate to rpmfusion. Last I installed from nvidia .run, it causes some issues when Fedora updates kernel etc. I am okay to wait and re-try to see if this is fixed.

7

I have a bug though: once the screen is woken up, mpv or youtube full screen do not show any display or have black cuts for 1 or 2 seconds (the screen shows the HDR logo, suggesting the monitor itself goes to sleep or changes mode). This is resolved if I reset screen settings in Plasma (e.g. modify HDR support, or refresh rate). Possibly a bug in Plasma or Wayland too. I will test if it is linked to VRR.

8

@zebcom This does sound like a bug I saw several months ago. It was with KDE Wayland plasma when “adaptive sync” was set to Auto at the time for me (iirc). The fix was to set it to disable, and that allowed the video to be played in full screen. I have since updated 2 plasma versions (i believe) and now on Fedora 43, with Plasma 6.5.1 and I just tested w/ Adaptive Sync=Auto and video full screen is working for me. Both HDR enabled or disabled, fyi.

9

Yes. I was going to post: this is not an nvidia bug, it is indeed the adaptive sync in Plasma causing this, but for me it still does it from time to time on Auto. I disabled it completely for the time being. However I never noticed it before upgrading to 580.105.08 driver, so I thought this was caused by the new driver.

10

I am actually surprised that this is still a problem with modern drivers and GPUs (at least, I think it is the same problem). I had this happened to me for even longer and with 2 different GPUs: RTX 3070 and RTX 4080. It bothered me so much that I switched back to Windows until a solution is found (I guess I will have to wait a little longer).

In my case, I was able to reproduce the issue with a different set of steps because of my unique setup (the TV and the PC have different power sources):

  1. Keep the TV without energy (unplugged);
  2. Turn on the PC;
  3. Wait some time to load the login screen;
  4. Plug back the TV and turn it on.

Result? A “no signal” screen, but with the login loaded on the PC. There were only a couple of things I could do at this point:

  • Reboot the PC from the power button in the case (that’s what you did);
  • I could type my password and press enter (yeah, I had to do it in a black screen with no sound), so the compositor would send a signal to my TV and load everything normally;
  • Or I could switch TTYs with Ctrl + Alt + F# back and forth.

It was even easier to reproduce if I used LUKS, but I don’t think the driver was even loaded at that stage (before supplying the decryption key). Besides that, if I turned the PC on before the TV (even with energy), it would sometimes result in “no signal“.

Another important note is that I don’t use suspension (suspend to RAM) or hibernation (suspend to disk). All of that was from turning the PC off which was supposed to be less buggy.

I just have a few questions for @mohdyusuf. Have you tried the password trick I did? Or the TTY one?

I have also researched other solutions but I couldn’t find anything substantial. My hope was that it would be possible to force the compositor to rescan the displays in a service in intervals of time. This is what I got for some Wayland compositors:

  • KDE: kscreen-doctor rescan
  • Gnome: gnome-monitor-config set [DISPLAY SETTINGS]

Maybe this might work as well: ddcutil detect?

Either way, I am on Windows for now because it correctly detects and connects to my TV (LG OLED CX) so I unfortunately can’t test some of these. I hope this helps someone though.

11

@caio.hacktestes I think you just summarized the same problem I have. I had in the past once or twice been able to just punch in the password (when I was on gnome), but I seem to recall on KDE login screen, it may not select the password field by default.

I tried just now doing Ctrl + Alt + F# and I had hoped that it would have worked, but for some reasons it still didnt work for me.

Yes, if I were to boot the PC when the TV was OFF to begin with, it will never work. It is something to do w/ HDMI CEC, I really hope someone knowledgeable enough to at least pickup the mantel and drive this.

I did went thru many ChatGPT ish trying to trigger the rescan of the display, trying some script to wake up the display etc etc. Many things ChatGPT suggested, nothing worked.

I also tried kscreen-doctor rescan as you suggested - thru SSH (ipad to PC).

It just core-dumped instead.

➜  ~ kscreen-doctor rescan
qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-brcm, wayland-egl, wayland, xcb.

[1]    2121 IOT instruction (core dumped)  kscreen-doctor rescan
12

I had in the past once or twice been able to just punch in the password (when I was on gnome), but I seem to recall on KDE login screen, it may not select the password field by default.

Yeah, this happened to me on both GNOME and KDE. It is super annoying.

I tried just now doing Ctrl + Alt + F# and I had hoped that it would have worked, but for some reasons it still didnt work for me.

Dammit. I was hoping that it could at least work as a speedy workaround for now.

Yes, if I were to boot the PC when the TV was OFF to begin with, it will never work.

At least we now have some other steps to reproduce the problem and in a much faster way.

It is something to do w/ HDMI CEC, I really hope someone knowledgeable enough to at least pickup the mantel and drive this.

Given that you tried many other solutions and they all failed (even kscreen-doctor), I am starting to believe it really is a lower level problem in the drivers. I wish I was knowledgeable enough about the HDMI CEC to fix it myself.

Well, at least the kscreen-doctor core dumped seems to an intentional abort and not some random crash.

I wish I could help more. Either way, thanks for testing it.

1 Like
13

Try this command over ssh.

QT_QPA_PLATFORM=wayland kscreen-doctor --dpms off && sleep 1 && QT_QPA_PLATFORM=wayland kscreen-doctor --dpms on
14

Thanks @Mugnarr for the suggestions, I ran that test thru SSH, it seems maybe the kscreen-doctor needs to be run on the system itself (akin thru X session capable) and not through ssh?

This is the coredump it gives me thru ssh

QT_QPA_PLATFORM=wayland kscreen-doctor --dpms off && sleep 1 && QT_QPA_PLATFORM=wayland kscreen-doctor --dpms on
Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-brcm, wayland-egl, wayland, xcb.

[1]    1987 IOT instruction (core dumped)  QT_QPA_PLATFORM=wayland kscreen-doctor --dpms off
15

That command works for me on CachyOS thru SSH

Try this to use x11 instead of wayland.

QT_QPA_PLATFORM=xcb kscreen-doctor --dpms off && sleep 1 && QT_QPA_PLATFORM=xcb kscreen-doctor --dpms on
16

Unfortunately, it behaves the same way.

I also made sure both qt5-base and qt6-base are installed.

➜  ~ QT_QPA_PLATFORM=xcb kscreen-doctor --dpms off && sleep 1 && QT_QPA_PLATFORM=xcb kscreen-doctor --dpms on        
qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-brcm, wayland-egl, wayland, xcb.

[1]    2375 IOT instruction (core dumped)  QT_QPA_PLATFORM=xcb kscreen-doctor --dpms off
17

Run echo $XDG_SESSION_TYPE on the host machine to check if your using Wayland or x11.

If your using Wayland try running this script over SSH.

#!/bin/bash

# Safely reset displays on KDE Plasma Wayland


# Setup session environment
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
export WAYLAND_DISPLAY=${WAYLAND_DISPLAY:-wayland-0}

# Toggle DPMS off/on to wake monitors
QT_QPA_PLATFORM=wayland kscreen-doctor --dpms off
sleep 1
QT_QPA_PLATFORM=wayland kscreen-doctor --dpms on
18

You need to be logged in on your host machine for it to work.

19

Hi @mohdyusuf

I have filed a bug 5649321 for tracking purpose.

Shall try to repro issue in our lab and get back to you if required any additional information.

1 Like
20

thanks @amrits . Appreciate it.

For @Mugnarr , tried your new suggestion. You mentioned, I have to be “logged in on your host machine” - I am not sure how to do this with a lot of steps (which is undesirable imho).

From the black screen of the TV (which is the issue), I tried my best to punch in my password and enter. I am not sure if that logs me in, given I cant see the session (tv blank). I could, for that matter plug in another display on dp port or hdmi and login etc and login and plug back in the TV, but that seems excessive for a workaround.

Either way, I tried ssh-ing to my host (thru iPad) and issued the command, it still going core dumped.

Note, i am on default Fedora 43, KDE 6.5.1, which is wayland.

Last login: Sun Nov  9 16:16:44 2025 from 192.168.68.68
➜  ~ export XDG_RUNTIME_DIR=/run/user/$(id -u)
➜  ~ export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
➜  ~ export WAYLAND_DISPLAY=${WAYLAND_DISPLAY:-wayland-0}
➜  ~ QT_QPA_PLATFORM=wayland kscreen-doctor --dpms off
Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-brcm, wayland-egl, wayland, xcb.

[1]    1995 IOT instruction (core dumped)  QT_QPA_PLATFORM=wayland kscreen-doctor --dpms off
➜  ~ QT_QPA_PLATFORM=wayland kscreen-doctor --dpms on
Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-brcm, wayland-egl, wayland, xcb.

[1]    2018 IOT instruction (core dumped)  QT_QPA_PLATFORM=wayland kscreen-doctor --dpms on
➜  ~