SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Launch Final Fantasy XIV on Plasma (Wayland) 2. Move character and camera around for a while while holding the right mouse button OBSERVED RESULT Rarely (usually once per session at least) the camera will suddenly snap into a new position directly above your character, looking down. I think this is the cursor going to the top left EXPECTED RESULT Camera should not suddenly snap to a new unintended position. SOFTWARE/OS VERSIONS Linux: 5.19.3 (available in About System) KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 ADDITIONAL INFORMATION I have experienced this myself, and so has this person: https://www.reddit.com/r/linux_gaming/comments/osjtln/help_with_ffxiv_on_wayland_issue_explained_in/ And this person, but with Sway: https://www.gamingonlinux.com/forum/topic/5140/ However, it does not occur with Gamescope, the use of which is the workaround. https://github.com/Plagman/gamescope I wonder if Sway and KWin both share something in common that causes the same issue? What does Gamescope do differently?
Does this happen with other games or apps?
Created attachment 151683 [details] attachment-24166-0.html I haven't seen this behavior elsewhere, only with this game and only with Wayland, not with X On August 29, 2022 10:04:50 AM CDT, Vlad Zahorodnii <bugzilla_noreply@kde.org> wrote: >https://bugs.kde.org/show_bug.cgi?id=458233 > >--- Comment #1 from Vlad Zahorodnii <vlad.zahorodnii@kde.org> --- >Does this happen with other games or apps? > >-- >You are receiving this mail because: >You reported the bug.
This sounds like bug 444510. If you change the mouse sensitivity, does the problem go away?
Checking those settings, I appear to have two mice connected, even though there's only one... "USB-HID Keyboard Mouse" and "Razer Razer Naga X" ("Razer Razer Naga Keyboard" is also there but that's just for the 12 side buttons.) I had USB-HID set to Flat, and the Naga X set to Adaptive. I don't know if these are two different "devices" for the same mouse, but I tried setting them both to Flat, and then both to Adaptive. Also tested at different pointer speed values but that didn't make a difference. Could it be that having two mouse devices in there could be part of my issue?
There being two mice reported is a bit weird but probably nothing to worry about. If setting the profile to adaptive makes no difference we're likely looking at a different bug though.
This may be an issue with the Razer Naga Mouse, or is it just coincidence? I'm using a Razer Naga 2014.
(In reply to dynamis00 from comment #6) > This may be an issue with the Razer Naga Mouse, or is it just coincidence? > I'm using a Razer Naga 2014. Perhaps coincidentally I haven't seen this happen for at least a few weeks, though I haven't been playing as much lately. dynamis00, that is a possibility, as this user is using a Razer mouse (didn't specify it was a Naga) https://www.gamingonlinux.com/forum/topic/5140/ Unfortunately, none of the people on the reddit post I linked at the top mention what model/brand of mouse they're using.
(In reply to Chris Young from comment #7) > (In reply to dynamis00 from comment #6) > > This may be an issue with the Razer Naga Mouse, or is it just coincidence? > > I'm using a Razer Naga 2014. > > Perhaps coincidentally I haven't seen this happen for at least a few weeks, > though I haven't been playing as much lately. dynamis00, that is a > possibility, as this user is using a Razer mouse (didn't specify it was a > Naga) > > https://www.gamingonlinux.com/forum/topic/5140/ > > Unfortunately, none of the people on the reddit post I linked at the top > mention what model/brand of mouse they're using. I just tested with a Steelseries mouse and was able to yield the same results so it's not mouse specific. While researching someone mentioned that it was possible that multi monitor setup could be the cause... so I tried disabling the monitor, but still no luck.
(In reply to dynamis00 from comment #8) > (In reply to Chris Young from comment #7) > > (In reply to dynamis00 from comment #6) > > > This may be an issue with the Razer Naga Mouse, or is it just coincidence? > > > I'm using a Razer Naga 2014. > > > > Perhaps coincidentally I haven't seen this happen for at least a few weeks, > > though I haven't been playing as much lately. dynamis00, that is a > > possibility, as this user is using a Razer mouse (didn't specify it was a > > Naga) > > > > https://www.gamingonlinux.com/forum/topic/5140/ > > > > Unfortunately, none of the people on the reddit post I linked at the top > > mention what model/brand of mouse they're using. > > I just tested with a Steelseries mouse and was able to yield the same > results so it's not mouse specific. While researching someone mentioned that > it was possible that multi monitor setup could be the cause... so I tried > disabling the monitor, but still no luck. I was reluctant on using Gamescope because I wanted to keep VRR functionality. However, Gamescope 3.11.48 added VRR and it's working for me as a workaround.
Figured out how to use gamescope with XIVLauncher. Here's my launch options for the XIVLauncher.Core shortcut I added to Steam. XL_SECRET_PROVIDER=FILE gamescope -w 2560 -h 1440 -f -- %command% --parent-expose-pids --parent-share-pids --parent-pid=1
Corrected the title as it doesn't matter if a mouse button is held, just that it's controlling the camera. I recently had this happen while playing Half-Life 2. I still haven't seen it happen to a visible cursor.
Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.0.12-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 5700 XT Manufacturer: ASUS Its not just games. Its been driving me crazy the last few days but its when certain elements gets moused over. The pointer "teleports" a bit when for example switching from nothing to over a link or to a text field. It was not this prior. Whats really bizarre is that I attempted just now to record it but when looking at the recording it does not do what it does on the screen and the pointer seems fine in the recording but when I was doing it, it was not fine. Only way to then record is doing a shitty recording from my phone which Im not sure would even be visible and even less helpful. (And yes logging in to KDE x11 and there is no such issue for me, only in wayland since a few days ago)
After submitting my comment I saw that the date for this issue is older so maybe my issue is not related. Although Im not sure and not even sure what to file it under (cant seem to find any bugreport that matches better than this one) .
I started using Plasma again to test if this still happens. It does. However, Gamescope (which stopped working for me back in December) is working again for me, so I won't have to use GNOME.
just chiming in, that just recently i have been getting the same issue. started around june 21st/22nd. im on arch linux, with kde wayland. i cant reproduce the error well, but i happens several times per play session, that the camera will just randomly snap to a different direction while controlling the camera manually with the mouse buttons.
Demonstrative video: https://www.youtube.com/watch?v=06WeBHs3_QE I can confirm this. In Apex, if I exit out of the inventory with the mouse on specific locations, my view will snap to my feet. Linux: Arch Linux kernel 6.4.3.arch1.r1189903.be3ef67f38e1 KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10
I must add that gamescope does not help in my case
I must add that this happens in FFXIV, apex, and CSGO.
(In reply to Leonardo Cardoso Barreto from comment #18) > I must add that this happens in FFXIV, apex, and CSGO. All games running wayland does this now. Gamescope is a workaround, but the newest version makes this happens again, downgrade to 3.11.51
can confirm aswell that this happens to me also on kde plasma 5.27.7 under wayland on apex in the exact same situation when tabbing out of the menu or looting death boxes. hopefully this gets fixed as i like wayland and want to use it as my main instead of x11 also im able to push my cursor out of the fullscreen window if i flick my mouse hard enough
(In reply to Pollux from comment #20) > can confirm aswell that this happens to me also on kde plasma 5.27.7 under > wayland on apex in the exact same situation when tabbing out of the menu or > looting death boxes. hopefully this gets fixed as i like wayland and want to > use it as my main instead of x11 > also im able to push my cursor out of the fullscreen window if i flick my > mouse hard enough installing a older version of gamescope fixes the issue so ill deal with this until kde devs figure out a fix
If you reliably see the issue with newer gamescope but not with older gamescope, could you do a git bisect between the two versions to find out when exactly the problem appeared? If we know which change causes it (in gamescope or elsewhere) then we might be able to find the root cause of the problem itself
(In reply to Zamundaaa from comment #22) > If you reliably see the issue with newer gamescope but not with older > gamescope, could you do a git bisect between the two versions to find out > when exactly the problem appeared? If we know which change causes it (in > gamescope or elsewhere) then we might be able to find the root cause of the > problem itself since some version of gamescope, it doesnt capture mouse like it does in the older versions, so i guess thats why it stopped working, before gamescope kinda 'handled the mouse on its own', but now it kind of just takes the parent WM's mouse. why the issue started in the first place in wayland is still a mystery to me
With Gamescope 3.11.52, I was able to use it as a workaround. https://github.com/ValveSoftware/gamescope/releases/tag/3.11.51 With Gamescope 3.12, it no longer worked as a workaround. https://github.com/ValveSoftware/gamescope/releases/tag/3.12.0 I didn't try any of the betas between them.
(In reply to Pollux from comment #20) > can confirm aswell that this happens to me also on kde plasma 5.27.7 under > wayland on apex in the exact same situation when tabbing out of the menu or > looting death boxes. hopefully this gets fixed as i like wayland and want to > use it as my main instead of x11 > also im able to push my cursor out of the fullscreen window if i flick my > mouse hard enough +1 for me! Exactly same issue here (related bug): https://bugs.kde.org/show_bug.cgi?id=452188#c10 Recorded a video to showcase it. Happens in Fullscreen/Borderless/Windowed mode. Mouse jumping causes a spin-out to the looking at the floor. Super annoying & NOT THE MOUSE. It's KWIN/wayland related.
I suspect that's the same bug, and that my issue is a duplicate of that, as that was posted a few months earlier and it seems like the same thing is happening
I'll just add Counter Strike 2 to the pile of games where this is reproducible.
For FFXIV, setting the mouse cursor to the software cursor appears to fix the problem for me.
(In reply to Torabi from comment #28) > For FFXIV, setting the mouse cursor to the software cursor appears to fix > the problem for me. If you have the window unfocused, and then click on it, does the camera view snap to point at the top of your character's head, like it does for me?
(In reply to Yao Mitachi from comment #29) > (In reply to Torabi from comment #28) > > For FFXIV, setting the mouse cursor to the software cursor appears to fix > > the problem for me. > > If you have the window unfocused, and then click on it, does the camera view > snap to point at the top of your character's head, like it does for me? Yeah that happens to me aswell when playing games like overwatch, apex, cs2 etc
Just tested with the dev version of Plasma 6.0. The camera flipped a couple times. Not easy to reproduce, didn't get captured yet. However, I did get one thing captured: the performance had a sudden massive drop after a while in game. Unfortunately the footage is zoomed-in because I forgot to check the preview in OBS and resize it. I'll try to get a better capture soon. https://youtu.be/YEAlfRLNPfU
(In reply to Yao Mitachi from comment #31) > Just tested with the dev version of Plasma 6.0. The camera flipped a couple > times. Not easy to reproduce, didn't get captured yet. However, I did get > one thing captured: the performance had a sudden massive drop after a while > in game. Unfortunately the footage is zoomed-in because I forgot to check > the preview in OBS and resize it. I'll try to get a better capture soon. > https://youtu.be/YEAlfRLNPfU I was able to reproduce it every time by right clicking and left clicking fast. Like if I’m moving my camera and left clicking at the same time. It’s not simultaneous presses, but alternating really quickly.
dynamis00, if you're on Plasma 5, it may be that Plasma 6 has reduced the repeatability of this issue as I can't get it to happen no matter how I mash the left and right mouse buttons. I've got Replay Buffer set up now so the next time something happens I can get a capture.
(In reply to Yao Mitachi from comment #33) > dynamis00, if you're on Plasma 5, it may be that Plasma 6 has reduced the > repeatability of this issue as I can't get it to happen no matter how I mash > the left and right mouse buttons. I've got Replay Buffer set up now so the > next time something happens I can get a capture. Thats good to hear :)
https://youtu.be/ofARnpI6284 Captured three instances of the camera snap: 0:13, 0:28, 1:10. To reproduce this, I clicked on the screen to the right (a 1080p monitor rotated 90 degrees to the right) and then clicked on the FFXIV window. Doesn't happen every time, you can see several other attempts in the capture.
i'm wondering how much it would cost to fix this bug as no one has been assigned to fix it yet
See https://discuss.kde.org/c/development/sponsored-work/31 if you'd like to go down that path.
(In reply to Nate Graham from comment #37) > See https://discuss.kde.org/c/development/sponsored-work/31 if you'd like to > go down that path. Done. I can chip in $50. https://discuss.kde.org/t/bug-fix-cursor-issue-camera-snapping-into-downward-facing-position-in-some-games/7384
id like to report that the snapping no longer happens under plasma 6 beta 1 and the cursor can longer escape the window either if you try and flick your mouse super hard on apex legends
I don't think you should mark this issue resolved until it hits stable.
(In reply to Antti Savolainen from comment #40) > I don't think you should mark this issue resolved until it hits stable. agreed as the mouse snap issue still happens but its less frequent and it cant be triggered as much.
Wouldn't recommend changing the status of a bug that multiple people are experiencing until someone else can replicate your results. I can still cause the mouse snap just as reliably on beta 1 by clicking onto a window on a different screen, and then clicking back onto the game. I haven't experienced the random snap during normal gameplay (without clicking away from the game) for a while on Plasma 5. Plasma 6 is the same.
Tested further. With the System Configuration > Mouse Settings is set to either "Hardware Cursor" option, this occurs: * If the mouse is already moving, then LMB is pressed+held, the camera snaps to above the character. * If the mouse is NOT moving, then LMB is pressed+held, then the mouse is moved, the issue does not occur. So with very careful mouse usage, this issue can be avoided in Hardware Cursor mode. However this is not practical. As Torabi mentioned, the best workarounds for now are to use Software Cursor (easy) or Gamescope with Hardware Cursor (more technical, potential for lower input latency, potential for other issues)
I also have this problem, I've tested Final Fantasy XIV with lutris and ge-wine-8.x, someone mentioned downgrading wine and that's what i did, i tried with lutris-fshack-7.2 and the problem is gone. Tried with the "Software Cursor", and while it removes the problem, it introduces additional lag which is showstopper for me.
(In reply to Fun from comment #44) > I also have this problem, I've tested Final Fantasy XIV with lutris and > ge-wine-8.x, someone mentioned downgrading wine and that's what i did, i > tried with lutris-fshack-7.2 and the problem is gone. The Steam version might be different, I tried Proton-GE 7.2 and there was no difference. Also I can't get the vanilla launcher to work right now, Steam keeps saying there's a missing executable but ffxivboot.exe is right there. So I'm using XIVLauncher.
Hi, I get same issue on Apex legends using Wayland on multi monitor system. Kernel 6.6.8 Plasma 5.27.10 Frameworks 5.113.0 QT 5.15.11 When showing inventory (TAB) and moving quickly the mouse, if I leave inventory (TAB again), camera spin to the bottom. This happens when I move the mouse while leaving inventory. If I don´t touch the mouse for a short period before leaving inventory, issue does not happen. I tried unsuccessfully several tweaks: - different versions of proton including 7, 8, experimental and various versions of GE, - using Gamescope. - unplug a screen - different kernel versions 6.6, 6.5, 6.1
(In reply to mrkiu from comment #46) > Hi, > > I get same issue on Apex legends using Wayland on multi monitor system. > Kernel 6.6.8 > Plasma 5.27.10 > Frameworks 5.113.0 > QT 5.15.11 > > When showing inventory (TAB) and moving quickly the mouse, if I leave > inventory (TAB again), camera spin to the bottom. This happens when I move > the mouse while leaving inventory. If I don´t touch the mouse for a short > period before leaving inventory, issue does not happen. > > I tried unsuccessfully several tweaks: > - different versions of proton including 7, 8, experimental and various > versions of GE, > - using Gamescope. > - unplug a screen > - different kernel versions 6.6, 6.5, 6.1 On plasma 6 beta 2 i cant make it happen under proton 8.0 but now i can push the cursor out of fullscreen, borderless or window mode. I honestly would wait for native wayland for wine then i think these will be fixed as they could be xwayland problems
Having now tested FFXIV with Wine 9.0 and the Wayland driver enabled, I can confirm this solves the issue. It was an XWayland(+Wine?) specific issue after all. OK to close as resolved, or should that wait until a registry edit isn't required for Wayland support in Wine? (And the cursor properly hides when holding down LMB or RMB?)
Wait for the updates to roll out and so that we have a few confirmations that it's fixed.
Thanks for following up! We can close now. Other remaining bugs should get the own new bug reports.
I tried Proton 9.0, but the bug still occurs in Hunt: Showdown. Symptoms include: when I open the map in Hunt: Showdown and then move the mouse while closing it, the mouse position gets messed up, causing the character to look into the sky or floor.
(In reply to stellarharbour from comment #51) > I tried Proton 9.0, but the bug still occurs in Hunt: Showdown. Symptoms > include: when I open the map in Hunt: Showdown and then move the mouse while > closing it, the mouse position gets messed up, causing the character to look > into the sky or floor. First, did you enabled wayland in proton 9 or are you using xwayland? Second, is it a plasma 6 or plasma 5? I tried plasma 6 with wine and xwayland and don't have any issues anymore.
> First, did you enabled wayland in proton 9 or are you using xwayland? Proton 9 builds don't have wayland baked in. > I tried plasma 6 with wine and xwayland and don't have any issues anymore. I can still reliably reproduce this issue. Having dual monitor setup makes it easier. I'm using nested gamescope with "--force-grab-cursor" to work around this issue for now. It's not great as it can do neither VRR nor enable tearing but it's enough.
I updated to KDE 6 and can submit that issue still persists with Hunt: Showdown, doesn't matter Experimental, Beta (9.0) or stable Proton
(In reply to Ataberk Özen from comment #53) > Proton 9 builds don't have wayland baked in. true, i don't use proton but i know that even wine 9.x builds don't come with wayland enabled by default since it's still experimental > I can still reliably reproduce this issue. Having dual monitor setup makes > it easier. > I'm using nested gamescope with "--force-grab-cursor" to work around this > issue for now. It's not great as it can do neither VRR nor enable tearing > but it's enough. I spoke to soon, there are still issues with xwayland and plasma 6 but much less than plasma 5, i could also reliably reproduce it on plasma 5 but not on plasma 6. Now i'm testing on wine 9.3 with wayland enabled and so far no issues, anyone else tried latest wine with native wayland?
I think latest 6.0.1 point update fixed this issue as I'm no longer able to reproduce this on my system. Can anyone else confirm this is the case? #452188 should be fixed now as well but I haven't tested it with Apex Legends.
on arch here, with plasma 6.0.1 issue still happening for me, on multimonitor setup, on ffxiv through wine (xwayland, i've read reports that using the experimental pure-wayland wine doesnt have this issue)
I tested Apex Legends on the latest Arch Linux build and I wasn't able to reproduce the issue once.
Plasma 6.0.1, Nobara 39 Still happening on Final Fantasy XIV with multiple monitors
FFXIV players, take note: You HAVE to use Wine-Wayland if you want to solve this issue for FFXIV.
Also, Proton 9 is not built with Wine-Wayland support.
The mouse warping is happening with Xcom WotC on the tactical and strategic screens. Move the mouse in one direction and it snaps to odd areas, sometimes in the reverse direction from the physical move. Plasma 6.01 /Wayland latest KDE on Arch Logitech 705 mouse.
I was able to reproduce this issue with the default XIVLauncher settings on two distinct KDE 6.0.1 installations using Arch Linux (Framework 6.0.0/Qt 6.6.2/Kernel 6.7.9-zen1-1-zen (64-bit)/Wayland). Also: This bug might be a duplicate of bug 477887 and bug 452188.
PLEASE -- BEFORE COMMENTING ON THIS BUG: Test in Wine 9 with the Wayland driver enabled. This feature solves the issue for FFXIV at a minimum, might solve similar issues in other games, and should soon leave the "experimental" phase. https://github.com/rankynbass/unofficial-wine-xiv-git/releases/tag/v9.3 https://www.collabora.com/news-and-blog/news-and-events/wine-on-wayland-a-year-in-review-and-a-look-ahead.html And yeah, I've previously commented on those two bug reports, but now I've added them to "See Also".
*** Bug 477887 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5422
(In reply to Yao Mitachi from comment #64) > PLEASE -- BEFORE COMMENTING ON THIS BUG: > > Test in Wine 9 with the Wayland driver enabled. This feature solves the > issue for FFXIV at a minimum, might solve similar issues in other games, and > should soon leave the "experimental" phase. > > https://github.com/rankynbass/unofficial-wine-xiv-git/releases/tag/v9.3 > > https://www.collabora.com/news-and-blog/news-and-events/wine-on-wayland-a- > year-in-review-and-a-look-ahead.html > > And yeah, I've previously commented on those two bug reports, but now I've > added them to "See Also". Test our games with XIV wine? For Steam games?
The latest updates on Arch (6.02-3) seems to have cleared up this warping mouse issue. (At least for what I'm doing with Proton games in Steam.)
Mouse input in XIVLauncher / Final Fantasy XIV is back to normal operation on Arch Linux with kwin 6.0.2-3. My installation uses the XWayland based default settings.
can counter-confirm that for myself on arch linux with 6.0.2-3 kwin, issue with mouse jumping, and camera moving towards the bottom of the screen is still present
Countering my previous comment. After today's updates (Latest Arch/Plasma/etc.,), the mouse issues have returned. The change in elevation in the tactical screen of Xcom WotC via mouse wheel causes the mouse to jerk across the map in strange ways. Mouse moves then cause the screen to drag, sometimes in the opposite direction as the mouse move. It is also happening in Xcom EW on the tactical screen.
(In reply to stellarharbour from comment #67) > Test our games with XIV wine? For Steam games? Yes. For FFXIV, you can use XIVLauncher, either the main goatcorp version or the fork by rankynbass. They both let you choose which Wine version. For ANY Steam game, you can use a different compatibility tool. SteamTinkerLaunch, for example. Or Proton-GE, though I don't know if any of them are built with Wayland enabled
* Did you disable KDE actions for screen corners? * Try to disable many Desktop Effects, if the issue is gone?
(In reply to Arazil from comment #69) > Mouse input in XIVLauncher / Final Fantasy XIV is back to normal operation > on Arch Linux with kwin 6.0.2-3. My installation uses the XWayland based > default settings. I retract the above statement. Upon additional testing, I was able to reproduce the XIVLauncher / Final Fantasy XIV input bug again under Arch Linux and kwin-6.0.2-3. This attempt was using the default XIVLauncher settings.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5475
Git commit 630ba5fab4b02c2b496553c79d4a315da9271b53 by Xaver Hugl. Committed on 19/03/2024 at 19:13. Pushed by zamundaaa into branch 'master'. pointer input: handle warp events differently from absolute motion events As Wayland doesn't have a warp event yet, before this commit, warps were dealt with like normal absolute motion events. This trips up games though, which don't deal with actual absolute motion events well. As a solution to that, until an actual warp event is a thing, we send a motion event with a position + a relative motion event with no motion Related: bug 482476 M +1 -1 autotests/libinput/input_event_test.cpp M +5 -1 src/input.cpp M +2 -1 src/input_event.cpp M +7 -1 src/input_event.h M +18 -12 src/pointer_input.cpp M +6 -1 src/pointer_input.h https://invent.kde.org/plasma/kwin/-/commit/630ba5fab4b02c2b496553c79d4a315da9271b53
Git commit 0b2d8901ab086bf5119077911ba39f63b1bdecfe by Xaver Hugl. Committed on 19/03/2024 at 19:31. Pushed by zamundaaa into branch 'Plasma/6.0'. pointer input: handle warp events differently from absolute motion events As Wayland doesn't have a warp event yet, before this commit, warps were dealt with like normal absolute motion events. This trips up games though, which don't deal with actual absolute motion events well. As a solution to that, until an actual warp event is a thing, we send a motion event with a position + a relative motion event with no motion Related: bug 482476 (cherry picked from commit 630ba5fab4b02c2b496553c79d4a315da9271b53) M +1 -1 autotests/libinput/input_event_test.cpp M +5 -1 src/input.cpp M +2 -1 src/input_event.cpp M +7 -1 src/input_event.h M +18 -12 src/pointer_input.cpp M +6 -1 src/pointer_input.h https://invent.kde.org/plasma/kwin/-/commit/0b2d8901ab086bf5119077911ba39f63b1bdecfe
*** Bug 474774 has been marked as a duplicate of this bug. ***
on current arch linux now, with `6.0.3.1-1`, i could no longer replicate the issue while playing, previously i was able to produce the bug when moving the camera aggressively enough after a couple minutes, so it's fixed for me now