LG gaming monitor and DisplayPort deep sleep shenanigans

adxk · 2023-12-26 21:45:29

Hello. I own a LG 27GP850-B gaming monitor, it's connected to my PC with a DisplayPort cable. When I turn the monitor off with the power button, I can't seem to interact with my PC. For example: can't pause a YouTube video with the spacebar, can't remotely connect to my PC on my phone using Moonlight, because the display "doesn't exist".
When I turn the monitor back on, KDE display configuration window says "A new output has been added. Settings have been reloaded". This monitor unfortunately does not have a Deep Sleep toggle in it's OSD menu. HDMI seems to be working fine, but my refresh rate is limited.

This issue only happens on Wayland (tried GNOME and KDE). On X11 session this does not happen, but I don't want to use X11 because of janky VRR support and other issues. For fun, I've also tested this on Windows - no issues there.
Specs: Arch Linux, AMD Ryzen 5 5600, MSI MPG B550 GAMING PLUS /w latest BIOS, Radeon RX 6700XT.

Also tried a couple of amdgpu kernel parameters, but some of them did nothing and others caused a black screen. I'm out of ideas, any advice? Thanks in advance!

seth · 2023-12-26 22:13:14

You could try to remove https://archlinux.org/packages/extra/x86_64/kscreen/ or disable the kded module.

because of janky VRR support

https://wiki.archlinux.org/title/Variable_refresh_rate
https://bbs.archlinux.org/viewtopic.php … 6#p2138866

and other issues

like that you can't turn off your monitor?

adxk · 2023-12-26 22:43:33

seth wrote:

You could try to remove https://archlinux.org/packages/extra/x86_64/kscreen/ or disable the kded module.
because of janky VRR support
https://wiki.archlinux.org/title/Variable_refresh_rate
https://bbs.archlinux.org/viewtopic.php … 6#p2138866
and other issues
like that you can't turn off your monitor?

I don't think removing KScreen would work, I already tried disabling it from KDE Services menu and it also happens on GNOME (obviously, no KScreen there).

X11 makes my games stutter, my mouse pointer is lagging with VRR, Wayland overall seems much smoother.

EDIT: OK, so I've managed to set up my X11 session with the correct parameters. Mouse is no longer laggy, but there's one last problem - 100 FPS doesn't feel like 100 FPS in a game. Limiting the game to 75 FPS is much better. That's what I meant when I said that Wayland feels smoother. This is my Xorg amdgpu.conf file:

Section "OutputClass"
     Identifier "AMD"
     MatchDriver "amdgpu"
     Driver "amdgpu"
     Option "VariableRefresh" "true"
     Option "TearFree" "on"
     Option "SWCursor" "true"
EndSection

Last edited by adxk (2023-12-26 23:45:20)

seth · 2023-12-27 08:18:42

"TearFree" wll introduce vsync, if you've also a syncing compositor and game, you can easily end up waiting for 3 vblank signals and regardless what you "feel", you're not noticing the difference between 75Hz and 100Hz but witness some artifact (ie. imperfection in the output chain) exposing a much more significant difference (because you obviously are going to notice the difference between 25Hz and 50 Hz(

1. Disable "TearFree", it conflicts with the idea of "VariableRefresh" anyway (and idk how the driver handles that)
2. For KDE, make sure to suspend the compositor (SHIFT+Alt+F12)
3. You've seen that VRR is disabled for a buch of processes by mesa?

Wrt the wayland situation, do you get the same problem w/ eg. weston or sway?

adxk · 2023-12-27 10:23:55

seth wrote:

"TearFree" wll introduce vsync, if you've also a syncing compositor and game, you can easily end up waiting for 3 vblank signals and regardless what you "feel", you're not noticing the difference between 75Hz and 100Hz but witness some artifact (ie. imperfection in the output chain) exposing a much more significant difference (because you obviously are going to notice the difference between 25Hz and 50 Hz(
1. Disable "TearFree", it conflicts with the idea of "VariableRefresh" anyway (and idk how the driver handles that)
2. For KDE, make sure to suspend the compositor (SHIFT+Alt+F12)
3. You've seen that VRR is disabled for a buch of processes by mesa?
Wrt the wayland situation, do you get the same problem w/ eg. weston or sway?

OK, so the issue with games feeling laggy at high FPS was a different issue that is now fixed. After tinkering with my Xorg config, I've made some observations:

TearFree off, SWCursor false:
System feels snappy, but mouse pointer is skipping unless there's stuff moving on the screen. Disabling composition makes things even worse - for example, scrolling webpages has noticable input and animation lag.

TearFree off, SWCursor true:
Same as above, but mouse cursor keeps blinking, there are some UI artifacts, a lot of input lag and whole DE feels like it's running at 30 FPS.

TearFree on, SWCursor false:
Mouse skipping issue still present.

TearFree on, SWCursor true:
Smoothest experience overall, games feel smooth and input lag is minimal, just like on Wayland.

I did not know about Mesa disabling VRR for some processes.

Also, I've installed Sway to try if the original Wayland issue is present there. I did my usual "YouTube pause test", I could pause the video with the spacebar, but I couldn't scroll the page with my mouse while the monitor was off. I launched Chromium through the terminal and could see some warnings and errors print out there after power cycling the monitor.

I think that I will stay on X11 with my current config (both TearFree and Software cursor on).

Last edited by adxk (2023-12-27 11:50:55)

seth · 2023-12-27 15:00:49

OK, so the issue with games feeling laggy at high FPS was a different issue that is now fixed.

OOC and for posteriority: what and how exactly?

TearFree off, SWCursor false:
System feels snappy, but mouse pointer is skipping unless there's stuff moving on the screen. Disabling composition makes things even worse - for example, scrolling webpages has noticable input and animation lag.

This is only w/ VRR enabled?
adaptive_sync is disabled for kwin_x11, what if you follow the other thread and try to force adaptive_sync generally enabled?

adxk · 2023-12-27 15:21:30

OOC and for posteriority: what and how exactly?

The only thing I did was to lower my mouse's USB polling rate to 500 Hz. I also rebooted a couple of times.

adaptive_sync is disabled for kwin_x11, what if you follow the other thread and try to force adaptive_sync generally enabled?

Do you mean the "drirc" file stuff that was posted?

seth · 2023-12-27 15:34:47

Do you mean the "drirc" file stuff that was posted?

Yup.

lower my mouse's USB polling rate to 500 Hz

Assuming the problems described in #5 do not hinge on 'Option "VariableRefresh" "true"', does returning it to 125Hz deal w/ them?

adxk · 2023-12-27 16:58:04

seth wrote:

Do you mean the "drirc" file stuff that was posted?
Yup.
lower my mouse's USB polling rate to 500 Hz
Assuming the problems described in #5 do not hinge on 'Option "VariableRefresh" "true"', does returning it to 125Hz deal w/ them?

My polling rate was previously set to 1000Hz. I'm staying on 500Hz, because I remember it being much smoother also on Windows.

Making changes to .drirc file brought no results at all.
Also I forgot to answer, yes - the "mouse lag" on the desktop happens only when VariableRefresh is set to true in X11 conf.

I made some more observations using my display's OSD:
- Wayland: On the desktop while doing nothing - refresh rate stays on 48Hz, but even slight movement of my mouse brings it up to 165Hz - very smooth and seamless, like on Windows.
- X11: On the desktop while doing nothing and when moving the mouse - refresh rate flucates between 48-80Hz and it's laggy, but for example when I'm moving a window or scrolling a webpage, the refresh rate jumps to 165Hz and the cursor is smooth.

seth · 2023-12-27 21:41:44

I'm staying on 500Hz, because

I understand your intentions but the question is whether incremental polling rate has detrimental impact on the performance (as apparently has at 1000Hz)

On the desktop while doing nothing and when moving the mouse - refresh rate flucates between 48-80Hz and it's laggy

W/ the HW cursor only, I assume (as that is painted directly into the scanout buffer by the driver and doesn't "repaint")

adxk · 2023-12-28 11:01:05

I understand your intentions but the question is whether incremental polling rate has detrimental impact on the performance (as apparently has at 1000Hz)

Actually, it seems that the polling rate change was a fluke. I've tested 1000Hz and 125Hz in-game and it was running well on both settings.

W/ the HW cursor only, I assume (as that is painted directly into the scanout buffer by the driver and doesn't "repaint")

That's correct. Also, you mentioned that X11 disables VRR for KWin. Does that mean that VRR should be disabled while I'm on the desktop? I've checked how VRR works on Windows and it stays on 165Hz unless I run a game or watch a video on fullscreen.

EDIT - More experimenting:
X11 TearFree false and SWCursor off: games feel great, tested DOOM 2016 and it runs even smoother than on Wayland, because there's no VSync in Vulkan so the game reaches it's hardcoded 200 FPS cap, just like on Windows.
If I play a game and then return to the desktop, it seems to get rid of the mouse lag. Refresh rate stays at 165Hz. That's what I would like it to work, but the lag comes back after a while.
Also, Adaptive Sync seems to not work in some games for some reason.

Last edited by adxk (2023-12-28 15:52:35)

seth · 2023-12-28 20:12:52

Also, you mentioned that X11 disables VRR for KWin. Does that mean that VRR should be disabled while I'm on the desktop?

This only affects the kwin process, so the decorations and of course the compositor.

Arch Linux

#1 2023-12-26 21:45:29

LG gaming monitor and DisplayPort deep sleep shenanigans

#2 2023-12-26 22:13:14

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#3 2023-12-26 22:43:33

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#4 2023-12-27 08:18:42

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#5 2023-12-27 10:23:55

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#6 2023-12-27 15:00:49

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#7 2023-12-27 15:21:30

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#8 2023-12-27 15:34:47

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#9 2023-12-27 16:58:04

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#10 2023-12-27 21:41:44

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#11 2023-12-28 11:01:05

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

#12 2023-12-28 20:12:52

Re: LG gaming monitor and DisplayPort deep sleep shenanigans

Board footer