You are not logged in.
I've recently reinstalled Arch onto a new drive, and since then I've been getting a slight lag or frame drops whenever I move my cursor between my screens. When looking at `htop` I do notice a slight jump in CPU usage from xorg when I quickly move my cursor back and forth between screens.
I've tried adding `Option "SWcursor" "on"` to my xorg conf, but that resulted in the cursor glitching out severely, by just displaying wrong (flickering, corrupted cursor)
Any help in trying to figure out the source of this issue would be appreciated. Thanks.
Specs:
CPU: Ryzen 5800X
GPU: Radeon 7900XT
Mouse: Logitech G502 HERO
Relevant Packages:
Xorg 1.21.1.9
KDE Plasma 5.27.9
Linux-Zen 6.6.1
Logs/Configs:
journalctl -b
dmesg
/var/log/Xorg.0.log
glxinfo -B
/etc/X11/xorg.conf.d/20-amdgpu.conf
Last edited by TheTrueColonel (2023-11-21 20:51:14)
Offline
This is probably down to kwin/plasmashell updating something when you enter the other desktop window.
Does it happen when you suspend the compositor (shift+alt+f12)
Where exactly do you get the (visible) "frame drops" when this happens?
Offline
What happens if you disable the variablerefresh config? What happens if you remove xf86-video-amdgpu and test the built-in modesetting driver?
FWIW multi-monitor support can quickly get iffy on xorg, and I've been using a wayland session for well over a year now on an amdgpu setup so this might be something to test as well.
Online
This is probably down to kwin/plasmashell updating something when you enter the other desktop window.
Does it happen when you suspend the compositor (shift+alt+f12)
Where exactly do you get the (visible) "frame drops" when this happens?
Yeah, it still happens when I suspend the compositor. It's kinda hard to tell if it's causing the entire display to kinda hitch, or if it's something with the cursor itself, since it's very brief but when moving the mouse between displays, there's a visible hitching which is much more noticeable if I'm dragging a window between the two.
What happens if you disable the variablerefresh config? What happens if you remove xf86-video-amdgpu and test the built-in modesetting driver?
FWIW multi-monitor support can quickly get iffy on xorg, and I've been using a wayland session for well over a year now on an amdgpu setup so this might be something to test as well.
I've tried disabling/removing both of those separately and together, and the issue is still there, and I'm not sure if a bug like this would be worth migrating display servers. I've seen a lot of software I use have either some limited compatibility, or full incompatibility with Wayland.
Offline
Can you capture it on camera?
(Use a tripod, otherwise the answer is "no" before you try)
Offline
Can you capture it on camera?
(Use a tripod, otherwise the answer is "no" before you try)
I don't have a tripod or any other stable way to record my screen with a camera, but I was able to use OBS to record at 120fps to show the hitching I'm seeing. Would you like me to link to the raw file, and if so, what's the preferred file host?
Offline
Yes & depends on the filesize, but you could abuse youtube, use a google drive or https://wetransfer.com/ pretty much regardless.
But if it shows up in OBS it's rendered this way and not just a scanout issue.
Fyi, you can makeshift a phone-tripod out of two books: -\_
(The only issue is the not-so-steady human hand)
Offline
Yes & depends on the filesize, but you could abuse youtube, use a google drive or https://wetransfer.com/ pretty much regardless.
But if it shows up in OBS it's rendered this way and not just a scanout issue.Fyi, you can makeshift a phone-tripod out of two books: -\_
(The only issue is the not-so-steady human hand)
Offline
Isn't public.
Offline
Isn't public.
I updated the permissions, my bad.
Offline
The window tracks the cursor, that's not actually tied to the output change, it just becomes notably at that point (likely because the sideload causing more delay)
I'd blame vsync and the compositor, but you've ruled that out.
Probably then
[ 15.821] (==) AMDGPU(0): TearFree property default: autoWhat happens if you remove xf86-video-amdgpu and test the built-in modesetting driver?
Otherwise disabling https://man.archlinux.org/man/extra/xf8 … n#Option~6 or enabling https://man.archlinux.org/man/extra/xf8 … n#Option~8 might help.
Not sure whether amdgpu has triple buffering support.
Offline
Unfortunately, neither of those options seemed to change anything.
Offline
You're now using the modesetting driver?
Edit: and please re-check the uncomposited behavior.
Also monitor the CPU usage while dragging the window - might be a pure KWin eventhandling.
Finally test the behavior w/ an openbox session.
Last edited by seth (2023-11-17 07:40:46)
Offline
Yes, I'm using the modesetting driver.
Still has the issue without the compositor.
If I don't move the mouse between monitors, almost no CPU usage, if I go between monitors, there's a noticeable jump in CPU usage.
In pure Openbox, the issue does not exist, KDE/openbox and Plasma (X11) sessions both have the issue.
I'm thinking this may be a KDE/xorg issue?
Offline
In pure Openbox, the issue does not exist, KDE/openbox and Plasma (X11) sessions both have the issue.
For the CPU spike i'm pertty sure it's the plasmashell window that causes that - does plasma/openbox also permanently lag the window behind the cursor (it's notable in your video when you play it frame by frame, the cursor does not maintain its relative position to the window)
Offline
I may not be fully understanding what you're meaning, but both an X11 only and a KDE/Openbox session will have both displays freeze completely until it catches up again. I didn't have any animations playing in my video to show that, but I can take another if needed.
I also ran glxgears to see what it'd report while I rapidly moved my mouse between displays. Here's the results I saw.
Plasma (X11)
837 frames in 5.0 seconds = 167.279 FPS
826 frames in 5.0 seconds = 165.081 FPS
742 frames in 5.0 seconds = 148.290 FPS
760 frames in 5.0 seconds = 151.703 FPS
689 frames in 5.0 seconds = 137.701 FPS
689 frames in 5.0 seconds = 137.312 FPS
KDE/Openbox
884 frames in 5.0 seconds = 176.749 FPS
826 frames in 5.0 seconds = 165.077 FPS
772 frames in 5.0 seconds = 154.286 FPS
757 frames in 5.0 seconds = 151.290 FPS
765 frames in 5.0 seconds = 151.922 FPSOffline
Not "between displays", the window is constantly lagging behind the cursor, even while stying on the same output.
Offline
Okay, yeah I see what you mean now. And yeah, recorded another video on KDE/Openbox and the windows do lag behind the cursor.
Offline
Also in a pure openbox session?
Offline
Yes, it does as well.
Offline
Would be sth. in the server. I'd say "tearfree" but that'S (for now and still) not a thing w/ the modesetting driver.
I guess it's also just a minor problem compared to the freeze on output crossing.
Since it happens w/ plasma/openbox you could briefly test whether it's the plasmashell process (by killing it, the desktop and panel should™ disappear) and then try to narrow it down to specific dekstop widget-thingies.
If it's *not* the desktop, the next contender would probably be the kscreen daemon ("kcmshell5 kded" or "kcmshell5 kded5" will hopefully allow you to deactivate that)
Offline
I've tried killing the plasmashell and disabling the kscreen daemon and the issue still persists.
Offline
Ok so it's related to the plasma session, but not the WM, plasmashell or the kscreen daemon…
What is the vertical window between the outputs you're crossing in the video? Some plasmapanel, conky, …?
Offline
The video was positioned using OBS to capture part of both my displays so the stuttering was more easily visible, as the cursor moved between them. The only things visible in the video are Firefox, Discord, and Konsole.
Offline
Is the presence of discord/any browser, any window beneath the moving window or present on either desktop relevant?
Offline