| Summary: | Effective desktop size is wrong for certain scale values | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | gudvinr+kde |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | adrian, kde, nate, notmart |
| Priority: | NOR | ||
| Version: | 5.27.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/commit/aa700a13d6392b023d3a1e66892a0d59edd792dd | Version Fixed In: | 5.27.2 |
|
Description
gudvinr+kde
2023-02-16 16:40:16 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. 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. 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. (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. (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. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3630 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 A possibly relevant merge request was started @ https://invent.kde.org/plasma/libkscreen/-/merge_requests/102 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 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). *** Bug 466311 has been marked as a duplicate of this bug. *** 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 A possibly relevant merge request was started @ https://invent.kde.org/plasma/libkscreen/-/merge_requests/110 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 |