SUMMARY *** In all sorts of video games (mostly over proton and steam) i experience weird behavior with the mouse. I launched several games in either fullscreen mode or borderless window mode. The cursor in menus, like main menu etc. behaves normal and as expected, but when i am in control of the camera, either third person or first person camera, it always points up and all mouse inputs make it spin very fast. After a reboot it sometimes returns back to normal, but i can't say for 100% what causes the bug. Unfortunately the applications do not crash, so i cant provide any dumps. I use Nobara Linux, which just updated to Plasma 6.0.0 I someone needs more information i will be happy to provide it as fast as possible! *** STEPS TO REPRODUCE 1. Boot Computer 2. Launch Steam 3. Launch a game on Steam via Proton 4. Get into the situation, where you are in control of the camera 5. Move mouse OBSERVED RESULT Camera is pointing towards the sky and mouse movement makes it spin rapidly EXPECTED RESULT Camera should follow mouse movement SOFTWARE/OS VERSIONS Linux/KDE Plasma: Nobara Linux 39 (KDE Plasma) x86_64 KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION I use Discord and LibreWolf as Flatpak and i usually use these apps everytime. Maybe it has something to do with it but i don't know.
Nobara community members found out, that if you open system settings app and click around in it while in game and then tabbing back in resolves the issue, until it randomly comes back again
Do you have other pointer input devices connected? Are you on wayland or X11? > it always points up and all mouse inputs make it spin very fast. I see this when I try to use my drawing tablet in absolute mode, instead of relative mode. So my hunch is that something similar might be happening here.
I am on wayland. Also I have a drawing tablet connected, which is my second screen. I found out other ppl have the same issue but they have no drawing tablet attached to their computer
I can confirm issue persists after update to 6.0.1
I'm getting the same bug since updating plasma to 6.0, what's weird is that restarting the game (fully closing it and launching it again, new window) doesn't fix the issue, I have to spam-click my left mouse button to un-lock it when it goes into `spinning` mode. Happens on x11 and wayland, no matter if the game is windowed or borderless. On top of that, when moving the camera it, more commonly, just `snaps` for a second pointing the camera extremely up/downwards, and rarely just `locks` into this weird spinning motion.
If it happens on Xorg as well, then it can't be a KWin bug, as KWin is not involved in input handling there. The bug might be in more low level input handling in libinput or the kernel, or in some library games use. To find out more information, open the kwin debug console on Wayland (just search for "kwin debug console" in KRunner), and go to the "input events" tab. When you observe the issue, does the "Delta (not accelerated)" field look reasonable?
Also can confirm same behaviour as reported by OP after upgrading to Plasma 6. (In reply to Zamundaaa from comment #6) > To find out more information, open the kwin debug console on Wayland (just > search for "kwin debug console" in KRunner), and go to the "input events" > tab. When you observe the issue, does the "Delta (not accelerated)" field > look reasonable? What is the expected behaviour/values here? I'm asking because even in unlaunched game state (just using desktop, moving mouse), the values changes with very high frequency when moving the mouse cursor. It's also difficult to check for reliable output since when having `Input Events` open, the game stutters so much, it's hard to even move the camera around to check if the issue appears. Also, while having `Input Events` tab open, dragging an moving scrollbar in the output window of the debug console crashes the whole kde environment including all running applications. But I guess that's a different issue. --- On a sidenote since I'm not sure if it helps debugging: on a custom wine version `wine-wayland` ( https://github.com/varmd/wine-wayland/ ) this issue does not seem to happen at all - although that wine version opens a different can of worms which makes the game unplayable - so I cannot use the version unfortunately.
After playing around, trying to reproduce the issue it looks like I can reproduce the issue of spinning camera at least on my system reliably: NOK: camera in game spins very fast 1. start an application having their own title bar/border decoration - eg. chromium (rightclick on title bar and have "Use system title bar and borders" unchecked) 2. start game 3. change window focus (alt+tab or clicking on it in eg. dual monitor layout on second screen) to above mentioned application (chromium) 4. move application (chromium) around 5. bring focus back to game Result: issue with erratic camera movement appears OK: Camera does not spin wildly Same steps as above EXCEPT right-click on border of application (chromium) and make sure "Use system title bar and borders" is CHECKED (aka force app to use KDEs title bar). Result: OK - camera in game moves fine even if external application (chromium) is being moved around
(In reply to tee from comment #7) > What is the expected behaviour/values here? > I'm asking because even in unlaunched game state (just using desktop, moving > mouse), the values changes with very high frequency when moving the mouse > cursor. When you slowly move the mouse to the right, it should be x/0, with x being pretty small, like 1-5 or so. The y axis should be zero at least most of the time. Same with up/down, just with the values flipped. > It's also difficult to check for reliable output since when having `Input > Events` open, the game stutters so much, it's hard to even move the camera > around to check if the issue appears. Yeah, the debug console doesn't perform too well with high DPI mice. You can alternatively run > sudo libinput debug-events | grep POINTER_MOTION in a terminal
(In reply to Zamundaaa from comment #9) > When you slowly move the mouse to the right, it should be x/0, with x being > pretty small, like 1-5 or so. The y axis should be zero at least most of the > time. Same with up/down, just with the values flipped. > > Yeah, the debug console doesn't perform too well with high DPI mice. You can > alternatively run > > sudo libinput debug-events | grep POINTER_MOTION > in a terminal Thank you! Using the method above to reproduce the issue, both OK and NOK state of mouse events look the same to me. OK: https://privatebin.net/?b4d65ce254ec0032#6eRpMe8Ah54ZbFQ6PpQMX8cd7gKdgshtUMkFZ7J6VSfx NOK: https://privatebin.net/?0eef3595331c08c2#CsD8GzbhLBU6K73B9C27Z94wvQJWpnx3hBYwLndWGUUV Note, I excluded the part of mouse output where I moved the cursor from and to the game window. The output should roughly represent: - LMB hold - move mouse left and right - LMB release
And because a video often helps for debugging, here's a screen recording with new Spectacle :) https://jumpshare.com/s/Q2X9gaOI1FZkxx1MYUWN
(In reply to tee from comment #11) > And because a video often helps for debugging, here's a screen recording > with new Spectacle :) > https://jumpshare.com/s/Q2X9gaOI1FZkxx1MYUWN Yes, this is exactly what I'm experiencing! I did NOT have this issue with previous version of KDE (5.x idk what came before). If I posted this bug under the wrong category I am sorry. Please tell me how to file it then. This is the first issue I'm posting.
(In reply to aosoba11 from comment #12) > I did NOT have this issue with previous version of KDE (5.x idk what came > before). Yes, looks like a Plasma 6 issue. Running the application in LXQT environment using Openbox but everything else untouched (drivers, wine version, game client version, mouse, etc.) works fine. No camera going crazy or (more annoyingly) random camera "reset" when rmb or lmb clicking.
Looks to me like a cursor confinement issue with Wine/XWayland (no idea why it occurs only [?] with Plasma >=6.0). I (6.0.1) often can't continue mouse look movement in some axis direction when the cursor seems to be hitting the screen borders. At least this is the cursor position when I alt + tab out of a game. Workaround is to switch tty once via ctr + alt + Fx.
Created attachment 166937 [details] output of 'libinput debug-events | grep POINTER_MOTION' in OK state
Created attachment 166938 [details] output of 'libinput debug-events | grep POINTER_MOTION' in BROKEN state
Update expired link to webm hosting provider for demonstrating bug: https://imgur.com/a/QEiIunQ
(In reply to tee from comment #17) > Update expired link to webm hosting provider for demonstrating bug: Why not simply attach it to this bug? It's only 950 KiB. You can choose "application/octet-stream" as the MIME type or - perhaps better - write "video/mp4" or "video/webm" into the "enter manually field", depending on what it is (imgur serves it as mp4).
Created attachment 166941 [details] video showcasing the bug reported
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5422
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 458233 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 458233 (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
The issue seems to have been fixed as of at least 2024-03-31 kwin 6.0.3 I'm not able to reproduce the issue using methods above. Also, it appears this fixed the camera randomly resetting/jumping.
Great! aosoba11@yahoo.de, can you confirm that?
Seems it fixed the issue for me too! 6.0.3
*** Bug 482632 has been marked as a duplicate of this bug. ***
I'm still encountering this bug with kwin 6.0.3.1 in both `Mass Effect Legendary Edition` and `Doom Eternal`, but not in `Portal RTX`. Operating System: Arch Linux KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.7.0 Kernel Version: 6.7.12-zen4-xanmod1-1 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X3D 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon Graphics (onboard, primary) Graphics Processor: NVIDIA RTX 4090 (secondary through prime) Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7E12 System Version: 1.0
(In reply to Jens Ramke from comment #28) > I'm still encountering this bug with kwin 6.0.3.1 in both `Mass Effect > Legendary Edition` and `Doom Eternal`, but not in `Portal RTX`. > > Operating System: Arch Linux > KDE Plasma Version: 6.0.3 > KDE Frameworks Version: 6.0.0 > Qt Version: 6.7.0 > Kernel Version: 6.7.12-zen4-xanmod1-1 (64-bit) > Graphics Platform: Wayland > Processors: 32 × AMD Ryzen 9 7950X3D 16-Core Processor > Memory: 62.0 GiB of RAM > Graphics Processor: AMD Radeon Graphics (onboard, primary) > Graphics Processor: NVIDIA RTX 4090 (secondary through prime) > Manufacturer: Micro-Star International Co., Ltd. > Product Name: MS-7E12 > System Version: 1.0 It seems be be fixed with version 6.1.