STEPS TO REPRODUCE 1. Use Plasma 6.0.0 or 6.0.1 over Wayland with a Razer Deathadder V2 mouse attached 2. Start a FPS game (tested so far: gzdoom, dsda-doom, raze, dhewm3) 3. Begin or load a game so as to reach the main gameplay loop OBSERVED RESULT In a fresh session, there is a (seemingly 50/50) chance of the main gameplay loop being borderline unresponsive to mouse movements from the outset. The symptom is that, even with tremendously exaggerated physical movements of the mouse, the game engine reponds as if receiving minute amounts of seemingly random jitter. That is, no matter how hard or fast or move the mouse, and no matter in what direction, the player's view is affected only minutely, and in directions that seem little more than random. Needless to say, the game is rendered unplayable. The only solution is to exit the game and load it again, at which point the chances seem to become drastically higher that the game will behave as expected. The onset of this phenomenon coincided precisely with upgrading from Plasma 5.27.10 to 6.0.0. At the time, I upgraded to Plasma 6.0.0 by enabling the "extra-testing" repo in Arch Linux. Since then, 6.0.1 has been made stable for Arch and I upgraded to it by disabling the aforesaid repo and re-converging on stable packages. The release of 6.0.1 has not helped with my issue, however. EXPECTED RESULT My expectation is for mouse input to always be dealt with correctly, as was the case while using Plasma 5.27.10, and as seems to be the case in any other environment than Plasma. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux (Linux 6.7.8) KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION Presently, the Deathadder peripheral is connected to a USB 3.0 port. Dhewm3 implements a conventional mouse cursor for operating its UI, outside of the main gameplay loop. Mouse input is never impacted at that point, but only once the mouse is grabbed and gameplay begins. I assigned the bug to kwin not because I know that kwin is responsible but because I am not presently able to better judge where the issue might lie.
Further testing indicates that the issue is unrelated to whether the session has just begun. In a session that I just tried now, I was able to start dsda-doom 4 times and have it behave correctly, only to encounter the behaviour described by this bug the next 2 times.
When you weren't experiencing this in Plasma 5.27, was that using X11, or also Wayland? Reminds me of https://gitlab.freedesktop.org/wayland/wayland/-/issues/443. If you have another mouse--a lower resolution one--can you try that one to see if it also happens there?
Had a similar experience with multiple Steam games in a wayland session, but working when switching to X11. Games running with Proton: "Enshrouded" - Seems like mouse input just stays in the center of the screen, slightly wiggeling around "Cyberpunk 2077" - Same as Enshrouded "RIPOUT" - Behaves as if the mouse input would bump into the edge of the screen. Can only turn some degrees left/right until the input reaches the edge of the window Native Linux build: "Barony" - same as Enshrouded, mouse seems to be stuck in the center Mostly game menus which show a mouse cursor work just fine, like the main menu of the games, or when opening the inventory in Enshrouded. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux (Linux 6.7.8) KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 With the previous Plasma 5, I was also using wayland and had no issues with any of these games.
Hi, I experience the same issue Christoph mentioned with enshrouded on Helldiver 2, Killing Floor 2 makes the mouse go absolutely nuts, spinning around liek the sensitivity was set to a million DPI. When I restart my Session, and don't open any Application, I don't have this problem and games behave like normal. I can even tab out of the game and start all other Programs I neen without any issue.
This is most likely the same as bug 482476; could you check the same suggestion I made there?
(In reply to Nate Graham from comment #2) > When you weren't experiencing this in Plasma 5.27, was that using X11, or > also Wayland? > > Reminds me of https://gitlab.freedesktop.org/wayland/wayland/-/issues/443. > > If you have another mouse--a lower resolution one--can you try that one to > see if it also happens there? I'm experiencing the same issue and can answer your questions. This issue did not exist on Plasma 5.27 Wayland for me. I've done the test with a Logitech M500s (up to 4000 dpi) and a Logitech B100 (they don't list a dpi for it in their specs, but it's a typical 9$ cheapo mouse, so no high dpi). The issue exists with both devices. I've tested with Helldivers 2 and Cyberpunk running through Proton. Valheim (native Linux) does not have this issue.
(In reply to Nate Graham from comment #2) > When you weren't experiencing this in Plasma 5.27, was that using X11, or > also Wayland? As concerns 5.27, I clocked up a fair amount of time in both X11 and Wayland. The issue occurred in neither session type. I haven't spent much time in X11 since the Plasma 6.0 upgrade but have tried to reproduce this issue with it. I was not able to. All the indications are that X11 is fine in this regard. > Reminds me of https://gitlab.freedesktop.org/wayland/wayland/-/issues/443. > > If you have another mouse--a lower resolution one--can you try that one to > see if it also happens there? I think I have an old portable Microsoft one somewhere. I'll give it a go.
(In reply to Zamundaaa from comment #5) > This is most likely the same as bug 482476; could you check the same > suggestion I made there? Will do.
When I'm having this issue and open the kwin debug console (using krunner), the issue is gone and things work reliably afterwards (even after closing the debug console).
I ran dsda-doom while tracing POINTER_MOTION events with libinput debug-events, thrice moving the mouse clockwise in a broad circle, pausing for a short time in between. I did all of this twice, once with the bug in effect and once without. Unfortunately, there is no meaningful disparity between the two sets of readings, nor do they reveal anything that appears interesting. I shall attach the results anyway.
Created attachment 166773 [details] bug482629-pointer-motion-good.txt A sequence of POINTER_MOTION events, captured from a DeathAdder V2 with libinput(1) in the case that dsda-doom was responding normally.
Created attachment 166774 [details] bug482629-pointer-motion-bad.txt A sequence of POINTER_MOTION events, captured from a DeathAdder V2 with libinput(1) in the case that dsda-doom was responding abnormally.
I have another observation to make. Occasionally, I found that switching back to dsda-doom with Alt-Tab - away from the terminal in which I launched libinput - would yield a sudden burst of in-game movement, almost as if a sizeable batch of events had suddenly been drained and handled normally. Following that, the behaviour would again be as already described for this bug, with no solution but to quit the game and try running it again.
I forgot to say, regarding Comment 13, this is something that I have never seen happen before, whether it be while using Wayland with 5.27.10 or X11 with any version of Plasma.
(In reply to Sandro from comment #9) > When I'm having this issue and open the kwin debug console (using krunner), > the issue is gone and things work reliably afterwards (even after closing > the debug console). This is not the case for me, at least with the games that I am testing (none of which have involved wine).
As to Nate's request, I just tested with a Microsoft Compact Optical Mouse 500 v2.0 and had dsda-doom malfunction after the third try.
*** Bug 483036 has been marked as a duplicate of this bug. ***
I'm also facing this with many games (happened at least once with: Garry's Mod (native), Garry's Mod (proton), VotV, Tower Unite, Deep Rock Galactic, Risk of Rain 2, Outer Wilds, etc) Opening the debug console as per an earlier comment did not help. I've also tested with a low-dpi mouse (some ancient asus), and it seems that doesn't affect the outcome. This did not happen on 5.27 (Wayland - did not test x11)
The issue seems to be resolved after upgrading to 6.0.3.
Great! How about you, bugs@plushkava.net?
(In reply to Nate Graham from comment #20) > Great! How about you, bugs@plushkava.net? 6.0.3 is not yet available for Arch. Is there a particular commit which is believed to address this bug?
(In reply to bugs from comment #21) > (In reply to Nate Graham from comment #20) > > Great! How about you, bugs@plushkava.net? > > 6.0.3 is not yet available for Arch. Is there a particular commit which is > believed to address this bug? Check Bug 482476, commit: https://invent.kde.org/plasma/kwin/-/commit/0b2d8901ab086bf5119077911ba39f63b1bdecfe
I compiled kwin-6.0.2 with the changes introduced by commit 0b2d8901ab086bf5119077911ba39f63b1bdecfe. As far as I can tell, it fully addresses this bug.
That's surprising (there was no change in behavior from 5.27 to 6.0 in that area) but I won't complain if it's fixed :)