[SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

realitaetsverlust · 2023-04-05 21:26:15

For quite a while now, I have the very annoying problem that moving my mouse feels very very unsmooth at times, especially when moving from one screen to the other. Looking into the xorg.log, I get a whole lot of those:

[  1460.464] (II) event2  - ASUSTeK ROG SPATHA X: SYN_DROPPED event - some input events have been lost.
[  1460.531] (II) event2  - ASUSTeK ROG SPATHA X: SYN_DROPPED event - some input events have been lost.
[  1462.214] (II) event2  - ASUSTeK ROG SPATHA X: SYN_DROPPED event - some input events have been lost.
[  1462.281] (II) event2  - ASUSTeK ROG SPATHA X: SYN_DROPPED event - some input events have been lost.
[  1463.215] (II) event2  - ASUSTeK ROG SPATHA X: SYN_DROPPED event - some input events have been lost.
[  1463.215] (II) event2  - ASUSTeK ROG SPATHA X: WARNING: log rate limit exceeded (5 msgs per 30s). Discarding future messages.

The dropped frames are especially visible when running glxgears:

137679 frames in 5.0 seconds = 27535.727 FPS // I keep my mouse still where it is
143031 frames in 5.0 seconds = 28606.137 FPS
49277 frames in 5.0 seconds = 9855.285 FPS // I move my mouse quickly between the two screens
60278 frames in 5.0 seconds = 12001.297 FPS
61448 frames in 5.0 seconds = 12251.857 FPS
132192 frames in 5.0 seconds = 26438.359 FPS // Still again
144997 frames in 5.0 seconds = 28999.322 FPS
66112 frames in 5.0 seconds = 13222.215 FPS // Move again
55601 frames in 5.0 seconds = 11120.153 FPS
125286 frames in 5.0 seconds = 25057.123 FPS // Still again

The problem is not the mouse, it works fine on another device. I also launched an openbox-session and tried it there, also tailed the xorg.log, no such behavior. It works perfectly fine. I even thought that the mouse is dying so I bought the exact same one again, but I still had the same problem. I also tried to use the mouse in wireless mode and wired mode - no difference in either case. The monitors are also both at 4k resolution and the same refresh rate. In my desperation, I even tried to disable vsync via .drirc, however, that didn't do anything either.

The thing is, the mouse used to work perfectly fine a few months ago before I upgraded my system from a 6800 XT to a 7900 XTX. I remember having massive problems with the upgrade due to incomplete firmware and drivers, maybe that broke something? It's worth noting that I DID reinstall the system in the end of january, but reused the home folder which was on a different partition. However, the mouse problems were already before that.

Does anyone have an idea how to further debug this problem?

Last edited by realitaetsverlust (2023-04-10 12:47:40)

seth · 2023-04-06 08:02:52

Do you run plasma on wayland or X11?
Since openbox isn't affected, it's either the display server or some client (kwin?) tracking the "active" output and responding badly.
Is there a spike in CPU usage by some process when switching the outputs?
Does running plasmashell under openbox expose the same behavior or does killing the process under KDE (ie. merely running kwin and some clients) "mitigate" it?

realitaetsverlust · 2023-04-06 12:32:34

Do you run plasma on wayland or X11?

X11

Is there a spike in CPU usage by some process when switching the outputs?

Indeed there is. There are two /usr/lib/Xorg processes which are both is spiking pretty hard when moving the mouse. They also seem to be the exact same as it seems since the parameters passed to it are identical, I'm not sure if that's normal. When I stop moving the mouse, everything goes back to normal.

Got a screenshot from that situation: https://i.imgur.com/1dqFGEs.png

Does running plasmashell under openbox expose the same behavior or does killing the process under KDE (ie. merely running kwin and some clients) "mitigate" it?

Nope, neither. Plasmashell doesn't seem to affect it at all. I also ran the Process-Check in Openbox and noticed that the CPU spikes equally hard just as it does under KDE, it's just barely noticeable, unlike with KDE.

Last edited by realitaetsverlust (2023-04-06 12:33:20)

seth · 2023-04-06 15:03:22

I don't use SDDM but afaiu it doesn't spawn a second server for the user session and those don't look like threads either.

Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

And also every xorg log in /var/log

realitaetsverlust · 2023-04-06 15:48:56

journalctl: http://0x0.st/HXqm.txt
Xorg.0.log: http://0x0.st/HXqT.0.log
Xorg.0.log.old: http://0x0.st/HXqA.log.old

seth · 2023-04-06 19:28:14

There's nothing outright suspicious - one SDDM, no indication of a second session and there's also only one GPU and one Xorg log (and the old one)
=> Try to remove xf86-vide-amdgpu (there're some issues reported in recent threads and it's the best guess I have atm)

realitaetsverlust · 2023-04-06 21:03:54

Removed it. Didn't change anything tho, sadly. I still have the exact same behavior as before.

seth · 2023-04-07 06:03:04

Since openbox works fine, plasmashell isn't the cause the most likely contender is kwin.
Does it happen when you suspend the compositor (SHIFT+Alt+F12)?

realitaetsverlust · 2023-04-07 10:28:50

Yes. Disabling the compositor has no effect.

seth · 2023-04-07 20:34:57

Just noticed your edit:

I also ran the Process-Check in Openbox and noticed that the CPU spikes equally hard just as it does under KDE

That's not supposed to happen.
What if you disable SDDM and start openbox or plasma w/ startx/xinit instead?

https://wiki.archlinux.org/title/Xinit#xinitrc
https://wiki.archlinux.org/title/KDE#From_the_console

realitaetsverlust · 2023-04-07 21:23:15

I do start openbox via xinit. It's basically just ` exec openbox-session`, and I execute ` startx` to launch openbox. However, I just disabled SDDM and ran plasma via xinit, but the behavior stays the same. I can now see the full paths of the processes tho. Not sure if that helps at all.

https://i.imgur.com/eXanIJt.png

Last edited by realitaetsverlust (2023-04-07 21:23:32)

seth · 2023-04-08 06:48:45

No. And the second Xorg thread is actually a userspace thread (htop, flat display, I guess)

So let's focus on the direct offender: ASUSTeK ROG SPATHA X shows up as pointer and keyboard and is a gam0rz™ mouse.
Replace that w/ a $5 mouse w/ 3 buttons and a wheel and see whether that causes the same effect.

Also remove the xorg configlet that sets the layout

[     6.813] (II) XINPUT: Adding extended input device "ASUS ROG SPATHA Keyboard" (type: KEYBOARD, id 16)
[     6.813] (**) Option "xkb_model" "pc105"
[     6.813] (**) Option "xkb_layout" "de"
[     6.813] (**) Option "xkb_variant" "nodeadkeys"
[     6.813] (**) Option "xkb_options" "compose:rwin"

and see whether the issue w/ the gam0rz™ mouse remains.
If not, match the product ("SONiX USB DEVICE"?, check "xinput -l")

If the above does at first not work, replace the apparent gam0rz™ keyboard w/ a $5 104 keys one as well.

realitaetsverlust · 2023-04-08 13:12:01

I removed the mouse and the keyboard and replaced them with some old logitech stuff. I also removed everything related to configs in /etc/X11/xorg.conf.d (I don't have any custom settings anywhere) The problem persists. I assume that the mouse shows up as keyboard because it has programmable buttons on the side that are mapped to several keys or scripts I'm using often.

I also tried the mouse and keyboard on my laptop and they work fine, even tho I don't have multiple monitors and I run i3-gaps, so probably not relevant. To check further, I even attached my devices to my girlfriends PC which runs zorin OS and has two screens and there is no such problem with the devices. It's also worth noting that I had both devices for over 2 years and the problems just started a few months ago.

Now that I think about it some more and consider hardware: Could this problem be related to the GPU? I bought the RX 7900 XTX in december last year and I remember having huge troubles getting it to run on arch because of linux-firmware and mesa not being updated in time to support it. It just worked when I came home from christmas by updating the system once and the problems started roughly around that time. Sadly I don't have another AMD GPU lying around to test it right now and my CPU does not have integrated graphics, but if it's a possibility, I might just buy an old and cheap one off ebay to test it.

Last edited by realitaetsverlust (2023-04-08 13:12:59)

seth · 2023-04-08 13:45:02

There were threads about AMD related issues w/ the HW cursor, might be worth a shot (also because I'm running out of ideas)
https://man.archlinux.org/man/extra/xor … .en#Option
https://man.archlinux.org/man/extra/xf8 … .en#Option

realitaetsverlust · 2023-04-08 16:47:28

seth wrote:

There were threads about AMD related issues w/ the HW cursor, might be worth a shot (also because I'm running out of ideas)
https://man.archlinux.org/man/extra/xor … .en#Option
https://man.archlinux.org/man/extra/xf8 … .en#Option

You might be out of ideas, but you had the right one. That was it.

I created a new config for the AMD card in /etc/X11/xorg.conf.d/20-amdgpu.conf and added this:

Section "OutputClass"
     Identifier "AMD"
     MatchDriver "amdgpu"
     Driver "amdgpu"
     Option "SWcursor" "on"
EndSection

Now, I STILL have a spike in cpu usage in Xorg and the process I'm "hovering" into, but I assume that's normal and it doesn't have any performance problems at all, at least not at first glance ... guess I'll see how it affects performance in certain applications, like games or godot.

The question is, can this be debugged and "fixed" by tinkering with my OS options or is that simply not fixable by me as a user and I basically have to hope someone patches it?

seth · 2023-04-08 19:54:43

Iff the modeseting driver is affected as well, it's probably in the kernel module.
The HW cursor is painted by the GPU directly into the framebuffer.

First thing would be to check whether the output crossing (w/ the HW cursor) leaves/left any traces in the system journal (org dmesg)
Also testing different kernels might show whetehr this is a regression (though since LTS is at 6.1, there's probably no kernel in the repo predating the main on of January)

We however also have something to ask google for - and to indicate in bug reports.

realitaetsverlust · 2023-04-10 11:38:28

Modesetting seems to have the same issues, yes. I'll test around some more and potentially open up a bugreport at the appropriate forums.

Thank you so much for your help, I would've never figured that out for myself! I truly appreciate it.

For some reason, I can't edit the title of my own thread - can't set it to solved sadly.

Last edited by realitaetsverlust (2023-04-10 11:39:30)

seth · 2023-04-10 12:40:01

The subject line is too long, you'll have to trim some parts to add [SOLVED]

https://www.reddit.com/r/kde/comments/1 … lasma_and/

Arch Linux

#1 2023-04-05 21:26:15

[SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#2 2023-04-06 08:02:52

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#3 2023-04-06 12:32:34

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#4 2023-04-06 15:03:22

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#5 2023-04-06 15:48:56

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#6 2023-04-06 19:28:14

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#7 2023-04-06 21:03:54

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#8 2023-04-07 06:03:04

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#9 2023-04-07 10:28:50

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#10 2023-04-07 20:34:57

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#11 2023-04-07 21:23:15

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#12 2023-04-08 06:48:45

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#13 2023-04-08 13:12:01

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#14 2023-04-08 13:45:02

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#15 2023-04-08 16:47:28

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#16 2023-04-08 19:54:43

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#17 2023-04-10 11:38:28

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

#18 2023-04-10 12:40:01

Re: [SOLVED] Mouse laggy and framedrops when moving between monitors @KDE

Board footer