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. Set monitor scaling to 125%. Turn off pointer acceleration in plasma settings. 2. Load CS2 or another FPS game 3. Test for mouse acceleration. I used this method: https://www.youtube.com/watch?v=5Cy8G2ElLOk OBSERVED RESULT pointer does not return to starting location with different mouse movement speeds. Significant mouse acceleration is present unless monitor is set to 100% scaling. EXPECTED RESULT pointer should not exhibit acceleration when using scaling. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION
I've still found bug to be present in KDE Plasma version 6.1.3. Mouse acceleration is set to Flat and is not present across the desktop environment but acceleration can be felt in games when Fractional scaling is in use. Using a 4k monitor at 175% scaling, mouse acceleration can be felt in native linux games as well as games running through proton. The only game I don't see acceleration present with fractional scaling is Minecraft. Setting the scaling to 100% does resolve the acceleration issues but they return if ever turning the scaling to 125% or 175%. I've not tested 200% or 150%.
i can confirm that i always thought that was kwin issue , i have another bug reported about the mouse freeze in some games , gnome and x11(kde) don't suffer from that , it has to be something with kwin , set scaling to 100% fixes the issue indeed .
What do you have the scaling setting for legacy applications set to? "Apply scaling themselves", or "scaled by the system"? Does changing it make a difference?
(In reply to Zamundaaa from comment #3) > What do you have the scaling setting for legacy applications set to? "Apply > scaling themselves", or "scaled by the system"? Does changing it make a > difference? Apply scaling themselves , on my system .
(In reply to Elie Dadde from comment #4) > (In reply to Zamundaaa from comment #3) > > What do you have the scaling setting for legacy applications set to? "Apply > > scaling themselves", or "scaled by the system"? Does changing it make a > > difference? > > Apply scaling themselves , on my system . Changing it do make a difference but u can't play at 4K Anymore games resolution goes down to 2k .
(In reply to Zamundaaa from comment #3) > What do you have the scaling setting for legacy applications set to? "Apply > scaling themselves", or "scaled by the system"? Does changing it make a > difference? Apply scaling themselves results in unwanted mouse acceleration. Scaled by the system results has no mouse acceleration (which is good), but has a lower possible max resolution for the game which is tied to your scaling value.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6564
There's no acceleration, but the unaccelerated values were scaled. That MR makes it independent of the screen's scaling value.
Git commit 47f800c12786d4b04a2e812785784d41e39bbfbc by Xaver Hugl. Committed on 04/10/2024 at 22:11. Pushed by zamundaaa into branch 'master'. wayland/relativepointer: don't scale non-accelerated pointer values Normally, pointer values are in logical units, which get implicitly scaled with the scale of the screen, so scaling them when scaling Xwayland makes sense. If the pointer moves too fast for the user with that scaling, they will simply use the libinput pointer acceleration setting to reduce that speed in a manner that's uniform for all their screens. However, unaccelerated values are not affected by that setting, and thus they should also not be affected by the screen's scale. This commit removes that scaling for Xwayland, which matches SDL's usage of the value in Wayland native mode and brings it in line with user expectations. M +2 -2 src/wayland/relativepointer_v1.cpp https://invent.kde.org/plasma/kwin/-/commit/47f800c12786d4b04a2e812785784d41e39bbfbc
(In reply to Zamundaaa from comment #9) That is incredible, such a fast fix. I can't wait to check out these changes. Thank you for your work Zamundaaa
(In reply to Zamundaaa from comment #9) > Git commit 47f800c12786d4b04a2e812785784d41e39bbfbc by Xaver Hugl. > Committed on 04/10/2024 at 22:11. > Pushed by zamundaaa into branch 'master'. > > wayland/relativepointer: don't scale non-accelerated pointer values > > Normally, pointer values are in logical units, which get implicitly scaled > with the scale of > the screen, so scaling them when scaling Xwayland makes sense. If the > pointer moves too fast > for the user with that scaling, they will simply use the libinput pointer > acceleration setting > to reduce that speed in a manner that's uniform for all their screens. > However, unaccelerated values are not affected by that setting, and thus > they should also not > be affected by the screen's scale. This commit removes that scaling for > Xwayland, which matches > SDL's usage of the value in Wayland native mode and brings it in line with > user expectations. > > M +2 -2 src/wayland/relativepointer_v1.cpp > > https://invent.kde.org/plasma/kwin/-/commit/ > 47f800c12786d4b04a2e812785784d41e39bbfbc Thank you so much Zamundaaa! I hadn't thought of trying system scaling until reading your post, but CS2 crashed my whole system when I tried it. Not sure if kwin or amdgpu but whatever. Really glad to see fixed!
Git commit 6d633e4bd19a32390eb0da26a50e881eb7fbb36d by Xaver Hugl. Committed on 04/10/2024 at 23:41. Pushed by zamundaaa into branch 'Plasma/6.2'. wayland/relativepointer: don't scale non-accelerated pointer values Normally, pointer values are in logical units, which get implicitly scaled with the scale of the screen, so scaling them when scaling Xwayland makes sense. If the pointer moves too fast for the user with that scaling, they will simply use the libinput pointer acceleration setting to reduce that speed in a manner that's uniform for all their screens. However, unaccelerated values are not affected by that setting, and thus they should also not be affected by the screen's scale. This commit removes that scaling for Xwayland, which matches SDL's usage of the value in Wayland native mode and brings it in line with user expectations. (cherry picked from commit 47f800c12786d4b04a2e812785784d41e39bbfbc) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +2 -2 src/wayland/relativepointer_v1.cpp https://invent.kde.org/plasma/kwin/-/commit/6d633e4bd19a32390eb0da26a50e881eb7fbb36d
(In reply to Zamundaaa from comment #12) > Git commit 6d633e4bd19a32390eb0da26a50e881eb7fbb36d by Xaver Hugl. > Committed on 04/10/2024 at 23:41. > Pushed by zamundaaa into branch 'Plasma/6.2'. > > wayland/relativepointer: don't scale non-accelerated pointer values > > Normally, pointer values are in logical units, which get implicitly scaled > with the scale of > the screen, so scaling them when scaling Xwayland makes sense. If the > pointer moves too fast > for the user with that scaling, they will simply use the libinput pointer > acceleration setting > to reduce that speed in a manner that's uniform for all their screens. > However, unaccelerated values are not affected by that setting, and thus > they should also not > be affected by the screen's scale. This commit removes that scaling for > Xwayland, which matches > SDL's usage of the value in Wayland native mode and brings it in line with > user expectations. > > > (cherry picked from commit 47f800c12786d4b04a2e812785784d41e39bbfbc) > > Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> > > M +2 -2 src/wayland/relativepointer_v1.cpp > > https://invent.kde.org/plasma/kwin/-/commit/ > 6d633e4bd19a32390eb0da26a50e881eb7fbb36d update on the issue , this didn't fix the behavior inside some games , scaling on 4k mouse still causes mouses acceleration freeze .
(In reply to Elie Dadde from comment #13) > (In reply to Zamundaaa from comment #12) > > Git commit 6d633e4bd19a32390eb0da26a50e881eb7fbb36d by Xaver Hugl. > > Committed on 04/10/2024 at 23:41. > > Pushed by zamundaaa into branch 'Plasma/6.2'. > > > > wayland/relativepointer: don't scale non-accelerated pointer values > > > > Normally, pointer values are in logical units, which get implicitly scaled > > with the scale of > > the screen, so scaling them when scaling Xwayland makes sense. If the > > pointer moves too fast > > for the user with that scaling, they will simply use the libinput pointer > > acceleration setting > > to reduce that speed in a manner that's uniform for all their screens. > > However, unaccelerated values are not affected by that setting, and thus > > they should also not > > be affected by the screen's scale. This commit removes that scaling for > > Xwayland, which matches > > SDL's usage of the value in Wayland native mode and brings it in line with > > user expectations. > > > > > > (cherry picked from commit 47f800c12786d4b04a2e812785784d41e39bbfbc) > > > > Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> > > > > M +2 -2 src/wayland/relativepointer_v1.cpp > > > > https://invent.kde.org/plasma/kwin/-/commit/ > > 6d633e4bd19a32390eb0da26a50e881eb7fbb36d > > update on the issue , this didn't fix the pointer behavior inside some games , > scaling still causes mouse acceleration issues .
Is there a link to the ticket about the mouse freezing? I've net experienced that, just the unexpected acceleration. I've not tested the new changes to Kwin yet as I'm not great at building it myself. If the mouse freezing is separate to the acceleration, we can move the conversation to that ticket?
(In reply to Berwick from comment #15) > Is there a link to the ticket about the mouse freezing? I've net experienced > that, just the unexpected acceleration. I've not tested the new changes to > Kwin yet as I'm not great at building it myself. > > If the mouse freezing is separate to the acceleration, we can move the > conversation to that ticket? i did open the ticket ,however i didn't keep track of it , both issues seems related though , as 100% scaling do fix the mouse freezing , and i did build kwin with zamunda's changes , didn't really have any improving .
This bug report and the fix are not about any freezes. Your problem is something different.
(In reply to Zamundaaa from comment #17) > This bug report and the fix are not about any freezes. Your problem is > something different. put the scaling at 100% , fixes the mouse freeze , somehow it should be related .