Bug 483067

Summary: Fractional scaling causes unwanted mouse acceleration in games
Product: [Plasma] kwin Reporter: pete <hayyash>
Component: inputAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: berwick1999, hayyash, nate, walkonfire81, xaver.hugl
Priority: NOR Keywords: qt6
Version: 6.1.3   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 6.2.1
Sentry Crash Report:

Description pete 2024-03-10 03:55:46 UTC
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
Comment 1 Berwick 2024-08-02 19:05:31 UTC
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%.
Comment 2 Elie Dadde 2024-10-03 19:40:14 UTC
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 .
Comment 3 Zamundaaa 2024-10-04 15:45:00 UTC
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?
Comment 4 Elie Dadde 2024-10-04 15:56:29 UTC
(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 .
Comment 5 Elie Dadde 2024-10-04 16:05:03 UTC
(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 .
Comment 6 Berwick 2024-10-04 19:43:46 UTC
(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.
Comment 7 Bug Janitor Service 2024-10-04 22:12:07 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6564
Comment 8 Zamundaaa 2024-10-04 22:14:02 UTC
There's no acceleration, but the unaccelerated values were scaled. That MR makes it independent of the screen's scaling value.
Comment 9 Zamundaaa 2024-10-04 23:41:31 UTC
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
Comment 10 Berwick 2024-10-04 23:46:06 UTC
(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
Comment 11 pete 2024-10-04 23:49:22 UTC
(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!
Comment 12 Zamundaaa 2024-10-04 23:56:40 UTC
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
Comment 13 Elie Dadde 2024-10-05 09:39:07 UTC
(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 .
Comment 14 Elie Dadde 2024-10-05 10:02:02 UTC
(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 .
Comment 15 Berwick 2024-10-05 10:07:22 UTC
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?
Comment 16 Elie Dadde 2024-10-05 10:49:14 UTC
(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  .
Comment 17 Zamundaaa 2024-10-05 11:23:03 UTC
This bug report and the fix are not about any freezes. Your problem is something different.
Comment 18 Elie Dadde 2024-10-05 11:55:09 UTC
(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 .