Bug 465850 - Effective desktop size is wrong for certain scale values
Summary: Effective desktop size is wrong for certain scale values
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.27.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 466311 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-02-16 16:40 UTC by gudvinr+kde
Modified: 2023-02-28 23:05 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.27.2
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description gudvinr+kde 2023-02-16 16:40:16 UTC
SUMMARY

My real display size is 2560x1440.
I use 115% scale, which (in theory) should give "virtual" screen size 2226x1252 or maybe 2227x1253 depending on how rounding is performed.
Desktop size reported by kwin debug console is 2229x1254, which is neither.

That leads to inconsistencies, for example I have an issue where MPV, which supports fractional scaling (at least in 0.35.1), scales itself to 1252 if I set window geometry to 1440.

STEPS TO REPRODUCE
1. Set display scale to 115%
2. Run mpv --no-keepaspect-window --geometry=WxH, where W is native display width and H is some arbitrary value

OBSERVED RESULT
Virtual desktop size doesn't match scale used by real apps or any meaningful value you could get by multiplying screen dimensions

EXPECTED RESULT
Predictable desktop size that fits windows that use same fractional scale

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 5.27.0
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.12-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Graphics Processor: AMD Radeon RX Vega M GL Graphics
Comment 1 gudvinr+kde 2023-02-17 10:32:18 UTC
Forgot to mention that it is rotated 90°, so width choice of 1440 for mpv is not arbitrary, it's just so it takes whole screen width. And that is how I notice inconsistencies because there is 2px gap at the right.
Comment 2 gudvinr+kde 2023-02-17 23:34:26 UTC
So, info centre says that Scale for this screen is 1.14844 which doesn't really make a lot of sense.
If value of 1.15 stored as IEEE754 float, you'll get either 1.14999997615814208984375 for float32 or 1.149999999999999911182158029987476766109466552734375. Neither of which round to 1.14844.

But at least it is obvious now where those weird sizes come from.
Comment 3 David Edmundson 2023-02-19 13:23:15 UTC
It's stored via wl_fixed.

wl_fixed_to_double( wl_fixed_from_double(1.15) gives 1.14844

I thought we had a path to snap this back to a more likely number, but maybe it never landed.
Comment 4 gudvinr+kde 2023-02-19 14:24:15 UTC
(In reply to David Edmundson from comment #3)
> It's stored via wl_fixed.
> 
> wl_fixed_to_double( wl_fixed_from_double(1.15) gives 1.14844
> 
> I thought we had a path to snap this back to a more likely number, but maybe
> it never landed.

MPV says it gets 1.15 for my second monitor:
[1119065.482] wp_fractional_scale_v1@28.preferred_scale(180)
[vo/gpu/wayland] Obtained preferred scale, 1.500000, from the compositor.
[1119065.489] wp_fractional_scale_v1@28.preferred_scale(138)
[vo/gpu/wayland] Obtained preferred scale, 1.150000, from the compositor.

I guess if it had 1.14844, there will be no issues with gaps no matter what effective size is.
Comment 5 gudvinr+kde 2023-02-19 14:33:06 UTC
(In reply to gudvinr+kde from comment #4)
> I guess if it had 1.14844, there will be no issues with gaps no matter what
> effective size is.

Okay, I read docs for wp_fractional_scale_v1 and it uses numerator with denominator of 120. That's where 138 comes from because 138/120 is 1.15.

There is no way to send 1.14844 through this protocol. It is probably a good thing because floating point numbers aren't great for representing exact values anyway.
Comment 6 Bug Janitor Service 2023-02-19 22:23:01 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3630
Comment 7 David Edmundson 2023-02-20 10:02:18 UTC
Git commit ada8e40792baf952a6893e217dded7785d251e6d by David Edmundson.
Committed on 20/02/2023 at 10:02.
Pushed by davidedmundson into branch 'master'.

outputchangeset: Round passed scale

Converting to wl_fixed is lossy. Especially for non-round values like 1.15.

This causes various visual glitches and off sizes.

Given we're using units of 120ths for the fractional scale protocol it makes sense
to fix the passed values for anything else over the wayland protocol.

Testing done:
ran a 1920 screen at 1.15 scale, got a logical size of 1670 which matches what it should be

M  +6    -1    src/wayland/outputmanagement_v2_interface.cpp

https://invent.kde.org/plasma/kwin/commit/ada8e40792baf952a6893e217dded7785d251e6d
Comment 8 Bug Janitor Service 2023-02-20 10:04:49 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libkscreen/-/merge_requests/102
Comment 9 Vlad Zahorodnii 2023-02-20 12:33:41 UTC
Git commit aa700a13d6392b023d3a1e66892a0d59edd792dd by Vlad Zahorodnii, on behalf of David Edmundson.
Committed on 20/02/2023 at 12:23.
Pushed by vladz into branch 'Plasma/5.27'.

outputchangeset: Round passed scale

wl_fixed is lossy even for values that are representable as perfect doubles, like 1.15

This causes various visual glitches and off sizes.

Given we're using units of 120ths for the fractional scale protocol it makes sense
to fix the passed values for anything else over the wayland protocol.


(cherry picked from commit 3082133117c4360d4ac9bc7500f4d2338f86e8d0)

M  +6    -1    src/wayland/outputmanagement_v2_interface.cpp

https://invent.kde.org/plasma/kwin/commit/aa700a13d6392b023d3a1e66892a0d59edd792dd
Comment 10 gudvinr+kde 2023-02-22 09:13:52 UTC
Can confirm that desktop size is 2226x1252 now and there are no issues with different scaling for client apps as well (at least in mpv that I had problem with before).
Comment 11 Nate Graham 2023-02-24 20:01:24 UTC
*** Bug 466311 has been marked as a duplicate of this bug. ***
Comment 12 David Edmundson 2023-02-28 22:45:52 UTC
Git commit 3b7b173ada8152df9160506ab14c396ca230c1d9 by David Edmundson.
Committed on 28/02/2023 at 22:44.
Pushed by davidedmundson into branch 'master'.

backends/wayland: Round passed scale

Converting to wl_fixed is lossy. Especially for non-round values like
1.15.

This causes various visual glitches and off sizes.
Given we're using units of 120ths for the fractional scale protocol it
makes sense to fix the passed values for anything else over the wayland
protocol.

M  +6    -1    backends/kwayland/waylandoutputdevice.cpp

https://invent.kde.org/plasma/libkscreen/commit/3b7b173ada8152df9160506ab14c396ca230c1d9
Comment 13 Bug Janitor Service 2023-02-28 23:02:48 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libkscreen/-/merge_requests/110
Comment 14 David Edmundson 2023-02-28 23:05:01 UTC
Git commit 43481ac90728ade84643dc83da108462e9951830 by David Edmundson.
Committed on 28/02/2023 at 23:02.
Pushed by davidedmundson into branch 'Plasma/5.27'.

backends/wayland: Round passed scale

Converting to wl_fixed is lossy. Especially for non-round values like
1.15.

This causes various visual glitches and off sizes.
Given we're using units of 120ths for the fractional scale protocol it
makes sense to fix the passed values for anything else over the wayland
protocol.


(cherry picked from commit 3b7b173ada8152df9160506ab14c396ca230c1d9)

M  +6    -1    backends/kwayland/waylandoutputdevice.cpp

https://invent.kde.org/plasma/libkscreen/commit/43481ac90728ade84643dc83da108462e9951830