Samsung TV turns off 10 seconds after login on KDE when used as monitor

Hi! I switched to CachyOS about a month ago on my Lenovo Legion 5 and the process was smooth with no major issues.

My usual setup is the laptop connected to a TV via HDMI, using it as my only display. When I first installed Linux I was away from home and used an older generic TV, with no problems at all. But back at my usual place, connected to my personal Samsung Smart TV (2015 model), I ran into a weird issue:

After booting and logging in, the desktop appears normally for about 10 seconds, then the TV shuts off. Sometimes it powers off completely and needs to be turned on manually, sometimes it reboots on its own, and occasionally nothing happens, but when it does shut off, the standby light blinks rapidly until I turn it back on. After that, everything works fine for the rest of the session. This behavior doesn’t happen on the live USB, nor on Windows (I set up a dual boot to check).

One thing I haven’t confirmed (might be nothing) is that the display refresh rate seems to drop after this happens: mouse movement feels slightly laggier, though it’s barely noticeable.

I’ve tried:

- Disabling Anynet+ (CEC) on the TV, no change.

- The TV is not connected to the internet.

Not a critical issue, just an annoying one, and I haven’t found anything online addressing this specifically. Any ideas?

Specs: Intel i5-10300H, NVIDIA RTX 2060, both / and /home are formatted as ext4, GRUB as bootloader, Wayland, KDE Plasma, all up to date, weekly updates + Timeshift backups.

Weird problem, is the refresh rate set too high? Can you make screen shot of the monitor settings in cachyos?

There are the settings. This TV screen supports a max of 60 Hz, which is the setting I have been using for ever. I’m starting to notice it more: I move the cursor before the screen turns itself off and definitely things feel smoother before than after. If I switch back to my native laptop screen for example I get perfect refresh rate and “feeling” that I don’t get after the tv screen glitches.

A new thing I notice is that in the brief period between me login in and the screen turning itself off is that I lose control over the TV. It doesn’t respond to commands, it ignores if I try to shut it down, etc. It only returns to normal after it reboots itself, but with this issue. Could it be that either KWin or KDE are interfering somehow with the screen or the internal OS of the TV in some way? Because I ran some tests the last few days, and this issue is happening on all Smart TVs I hook my computer to, but not on normal old screens.

I never had a problem like this. If TV react like this, it’s usally because the signal from a source is either out of specs or too “strong” like to high refresh rate.

I don’t know the solution. Maybe you can try to lower the brightness set it to 30%, change Precision del color too “Prefer color accuracy” and update the TV. Also on thing sometimes a monitor / TV reacts weird if you have set to 60 Hz try it with 59.94 Hz. This all I can think off sorry.

Doing more research I found similar issues people where having with powerdevil and KDE in this forum thread. Sadly, while their solution of disabling ddcutil was promising, a quick test here didn’t work. The only thing that changed though is that now the constant red blinking lights in the TV are gone, and it responds, but I need to unplug and plug again the hdmi cable for it to work when it goes out. Leaving it here in case it works for someone with similar issues.

PS: I managed to fix the refresh rate issue though. Turning on adaptive sync and disabling EDR on the native laptop screen fixes it for the TV screen. That just leaves the TV rebooting issue to fix.

Ive got the same problem with my Samsung QN700B its completely random when it turns the tv off. Only thing I found that at least helped before was turning off HDMI CEC and unplugging the tv for 30 seconds or so. This is too much of a coincidence for it to be a problem with the TVs themselves.

Nope thought i fixed it above but it seems to be where its left idle. Defo something going on that you cannot switch off.

Yep, also tried that solution and nothing. I just found out that a way that worked for me to “avoid it” (but not fix it) is to not turn the TV on until after you log in, KDE starts, and you let 10 or so seconds pass by just to be sure. Then you turn it on, and everything will work as normal. I’m pretty convinced there’s a service being started at just that moment that interferes with the TV’s systems in some way, but I lack the technical expertise in that area to find a concrete answer.

Try an Xorg (Plasma on X11) session instead of Wayland to see if it’s cause of Wayland.

Does your laptop have a Mux switch - to set dedicated Nvidia GPU - as primary GPU for handling your display? Or is it on Intel’s iGPU (that’s usually the case)?

  1. Tried to switch to a X11 session (after installing plasma-x11-session), but it only displays a black screen, so I couldn’t test this. Couldn’t switch ttys as well, so I couldn’t debug what was happening.

  2. Yes, it has, and I set the Nvidia card as the primary gpu years ago. Back when I was on windows I had to disable the iGPU because the default mode was causing horrible latency and bottleneck issues, which AFAIK is a known problem of this laptop model, and I have been using the dGPU as default since then without issues.

My issue isnt at login its just random but as i say seems to be when its just on desktop. Rather when something is being displayed on the screen. But it seems to be the same thing I would have said sending the power off. Although i wonder if the recent patches “In cachyos-settings, S01x power management was dropped due to issues with the NVIDIA 595 driver” Could also be the issue.

Did you have the issues prior to the 595 driver ?

Manually setting/adding the TV EDID (Extended Display Identification Data) - might help (or at least - it should do a better job - than automatic detection).

I’m still new to CachyOS, but there’s not much difference - here’s one way to set it: Refresh rate issues after sleep - #4 by Bohjadok (different OP issue - so check just the last part).

Yeah, Wayland has far better support - among the prime advantages over x11 and its primitive bits, but hey - was worth to try. To bad it doesn’t work… out the box - tho, even if you can get it to work - Wayland is still the superior choice. Are you using the proprietary Nvidia driver or Nouveau (tried both, and it’s same)?

Thanks for the help! Sadly, this didn’t do the trick either. No change was observed after following the steps in the thread.

Yeah, I’m going to work over tomorrow to see if I can get the X11 session fixed so I can see if the issue replicates there or not, even if I have no plans on staying on x11 lol. About the drivers, I’m using the proprietary ones, I’ve never been too eager to mess around with those ones.

Was a little behind on the Nouveau drivers - as open source, that project is not relevant anymore. I see a lot has changed in this regard - restructuring the Nvidia drivers install and maintenance, further improving the support of Nvidia open source drivers. So now they’re simply Nvidia-Open even on Arch main branch, as for CachyOS - would go like this…

sudo pacman -S linux-cachyos-nvidia-open nvidia-utils lib32-nvidia-utils nvidia-settings 

Side Note: Above install option - is only for Turing GPUs and above (which you have RTX 2060).

sudo mkinitcpio -P

Tho, above 2x commands are for installing the Open Source drivers - first you’ll have to uninstall the proprietary:

sudo pacman -S nvidia-580xx-dkms nvidia-580xx-utils nvidia-580xx-settings lib32-nvidia-580xx-utils opencl-nvidia-580xx

Don’t see the point of using the proprietary drivers - especially on a Turn GPU (RTX 2060) - where:

“NVIDIA’s GSP firmware is known to cause issues, from suboptimal power management of Turing GPUs” As can be seen on Arch page:Nvidia Proprietary drivers are sort of deprecated at this point - labeled as Legacy, as in: Still maintained by NVIDIA (for security updates and bug fixes) - but no new features, no support for new GPUs and not part of the mainline driver anymore. So Wayland support should get worse (if it hasn’t by now) - compared to Open Source.

Not to say this cures it entirely . Im on open source modules and the tv still goes off randomly as I did constantly this morning until a reboot.

Turns out I mispoke. I actually did have the open drivers all along, as I recently discovered (and checked) when I tried to switch.
But on the matter of the issue, there have been no news. It still happens each time I log in, so lately I have been just turning off my screen before writing the password, login in, waiting 10 seconds, and then turning it back on, bypassing the issue.

So, 2 weeks later. Still haven’t found a solution or mitigation for this. But by looking at the journalctl logs I managed to find a possible related entry.

may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146804] Udev event detected
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854] Udev_Event_Detail
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_subsystem:  drm
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_action:     changemay 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146804] Udev event detected
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854] Udev_Event_Detail
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_subsystem:  drm
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_action:     change
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_connector:  (null)
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_devname:    /dev/dri/card1may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146804] Udev event detected
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854] Udev_Event_Detail
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_subsystem:  drm
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_action:     change
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_connector:  (null)
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_devname:    /dev/dri/card1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_devmode:    (null)
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_hotplug:    1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_major:      226
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_minor:      1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    sysname:         card1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    syspath:         /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    attr_name:       (null)
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146876] (dw_watch_display_connections) Time since last return from sleep = 17041392334 ns = 17041 ms
may 22 22:51:54 Legion-AMC kwin_wayland[1268]: Atomic modeset test failed! Argumento inválido
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_devmode:    (null)
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_hotplug:    1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_major:      226
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_minor:      1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    sysname:         card1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    syspath:         /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    attr_name:       (null)
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146876] (dw_watch_display_connections) Time since last return from sleep = 17041392334 ns = 17041 ms
may 22 22:51:54 Legion-AMC kwin_wayland[1268]: Atomic modeset test failed! Argumento inválido
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_connector:  (null)
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_devname:    /dev/dri/card1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_devmode:    (null)
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_hotplug:    1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_major:      226
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    prop_minor:      1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    sysname:         card1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    syspath:         /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146854]    attr_name:       (null)
may 22 22:51:54 Legion-AMC org_kde_powerdevil[1459]: [  1560][ 17.146876] (dw_watch_display_connections) Time since last return from sleep = 17041392334 ns = 17041 ms
may 22 22:51:54 Legion-AMC kwin_wayland[1268]: Atomic modeset test failed! Argumento inválido

I have isolated this udev event happening every single session at the exact same time the tv screen turns off and reboots. Sometimes, when the reboot itself takes only a second or 2 to occur, I can only find one of these events. But when the reboots are longer (10 or more seconds long), I can find up to six of these happening in quick succession in journalctl.

Sadly, I lack the technical expertise to recognize exactly what is going on, and googling has only yielded decade long posts unrelated to this issue in particular, or implementing solutions already discarded in this thread. I post this here in the hopes someone with more expertise in the matter can help, or at least recognize roughly where the point of failure is to report the bug.

Will update if I find anything else.