Bug 389191 - xwayland auto-upscaling causes pixelation and should be optional
Summary: xwayland auto-upscaling causes pixelation and should be optional
Status: CLOSED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: git master
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL: https://gitlab.freedesktop.org/xorg/x...
Keywords:
: 389196 390049 404343 412088 440883 448136 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-19 05:00 UTC by Leonard Lausen
Modified: 2022-08-09 14:35 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.26


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leonard Lausen 2018-01-19 05:00:59 UTC
With a plasma wayland session and a multi-monitor (high and normal DPI) setup / scaling enabled, legacy xwayland applications are automatically scaled up, causing them to look bad on the HIDPI screen. This is especially grave if an application used predominantly during the day relies on xwayland.

These legacy applications often have their own settings to adapt to HIDPI screens. I argue in that case it is better to tune the xwayland applications by hand instead of relying on autoscaling, as only in this way a sharp output can be achieved.
While autoscaling is a great feature for many workflows that only seldomly use xwayland applications (thanks for developing it!), it should be optional and it should be possible to disable it.

Is there some run- or compile-time option to disable the xwayland autoscaling?
Comment 1 Leonard Lausen 2018-01-19 05:30:37 UTC
Possibly upscaling could be replaced by downscaling for the lower DPI screens.
Comment 2 Kai Uwe Broulik 2018-01-19 09:05:55 UTC
What I would ideally like to see is a checkbox in KPropertiesDialog to disable scaling on a per-application basis, like we already have with "run in terminal" and "run on discrete GPU" and then have KRun tell KWin not to scale windows of that application.
Comment 3 Kai Uwe Broulik 2018-01-19 10:14:51 UTC
*** Bug 389196 has been marked as a duplicate of this bug. ***
Comment 4 Martin Flöser 2018-01-19 19:36:04 UTC
(In reply to Kai Uwe Broulik from comment #2)
> What I would ideally like to see is a checkbox in KPropertiesDialog to
> disable scaling on a per-application basis, like we already have with "run
> in terminal" and "run on discrete GPU" and then have KRun tell KWin not to
> scale windows of that application.

on my blog someone suggested using window specific rules. That is a good idea IMHO. It could even allow to match all X windows.
Comment 5 Kai Uwe Broulik 2018-01-19 22:25:40 UTC
Good idea!
Comment 6 Kai Uwe Broulik 2018-02-08 11:50:04 UTC
*** Bug 390049 has been marked as a duplicate of this bug. ***
Comment 7 kiv.apple 2018-02-08 15:29:50 UTC
Is there a temporal workaround that allows to completely disable the scaling of XWayland applications without recompiling KWin?
Comment 8 Martin Flöser 2018-02-08 15:36:51 UTC
(In reply to kiv.apple from comment #7)
> Is there a temporal workaround that allows to completely disable the scaling
> of XWayland applications without recompiling KWin?

no
Comment 9 Roman Gilg 2018-04-30 23:16:11 UTC
Pls name a few test applications on Xwayland, which show these behavior. Which scale factor are you using?
Comment 10 Frederik Gladhorn 2018-05-01 15:44:11 UTC
Prime examples are Chromium and Firefox (I'm using 2x usually).
Comment 11 Leonard Lausen 2018-05-05 05:22:18 UTC
Another one is Emacs. Unlike Firefox and Chrome it likely won't support Wayland natively in the near future either.
Comment 12 Roman Gilg 2018-05-07 15:46:52 UTC
The addition of XDG Output Protocol could solve this issue: https://phabricator.kde.org/D12235
Comment 13 David Edmundson 2018-06-29 00:31:20 UTC
>The addition of XDG Output Protocol could solve this issue: https://phabricator.kde.org/D12235

It's unrelated.

Making it optional per client with one xwayland is simply not feasible. 
Making it optional inside xwayland is quite feasible, but not implemented. If that happened I would happily add relevant support in kwin.

Though the number of clients that are modern enough to have high DPI support and don't have a wayland implementation is a very small and decreasing minority.
Comment 14 Frederik Gladhorn 2018-06-29 07:00:38 UTC
Is there any mainstream browser that works with Wayland in HighDPI then? (sadly I cannot fully switch to Falkon for various reasons and not having a browser is for the time being what keeps me from using wayland)
Comment 15 Roman Gilg 2018-06-29 16:36:30 UTC
I run Chrome and Firefox on Wayland with 2x scaling. And there is no pixelation at all. I have not tinkered with any scaling options in the apps.
Comment 16 Eike Hein 2018-07-23 03:17:33 UTC
I'm not super happy with this being marked WONTFIX. It makes the Wayland session extremely unpleasant to use for the time being.
Comment 17 David Edmundson 2018-07-23 13:02:45 UTC
I'm genuinely curious as to whether your machine is worse than mine or whether it's subjective opinions on the same thing.
We should test at Akademy.

My stance remains, but for completeness, here's some links on the topic:

It's a topic we discussed when I went to Guadec. Here's Jonas and Daniel S's current notes.

https://wiki.gnome.org/Initiatives/Wayland/XWayland

It's more in depth as they're mostly talking about runtime supporting multiple options at once.

An option in xwayland to change would be much simpler.

One would need to:
 - set the wl_surface.scale to the wl_output.scale
 - set the X screen size appropriately to match the mode
 - do the relevant input redirection to our fake surface local co-ordinates

-----

There is an other option I tried playing with.

Chrome made a wayland proxy wrapper with xwayland support called sommelier. The interesting twist being that it converts Xwayland clients into wayland windows.

https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/vm_tools/sommelier/README.md 

I did some work to try and make it compile, but I got stuck on some virtwl nonsense which they use for SHM and gave up trying to remove that
Comment 18 Eike Hein 2019-01-12 17:50:31 UTC
> I'm genuinely curious as to whether your machine is worse than mine or whether it's subjective opinions on the same thing. We should test at Akademy.

I guess we didn't get around to this :). But I guess I don't really see how it couldn't be terrible. It's a 1x window being scaled naively to 2x with no smoothing or so, i.e. straight up pixel-doubling, which makes everything look like Minecraft. Do you remember the bug Gwenview had for a long time with hidpi where its content view was heavily pixelated? Same thing ...

I'm fine with pursuing the path of "get Firefox/Wayland working, and forget about XWayland" anyway, but I also can't begrudge anyone with a 4K screen not wanting to use Plasma/Wayland at the moment due to this. I think this problem will come up again with certain 2D games in the future however.
Comment 19 Mikola 2019-01-13 11:05:27 UTC
I have to reopen this, because bug still exist and causes very bad user experience. Screenshots of current situation can be found in https://bugs.kde.org/show_bug.cgi?id=389196
Comment 20 Martin Flöser 2019-01-13 15:49:11 UTC
I'm resetting the state. As explained in comment #17 this needs to resolved in XWayland. I'm fully with David on this. There is IMHO nothing KWin could do about it, though XWayland can.
Comment 21 Eike Hein 2019-01-13 15:52:41 UTC
I think there's some people working on it now: https://keithp.com/blogs/window-scaling/
Comment 22 Eike Hein 2019-01-13 15:53:12 UTC
Since pooling of information is a good idea, I'll also add this link with some relevant GUACEC notes David passed me: https://wiki.gnome.org/Initiatives/Wayland/XWayland
Comment 23 Mikola 2019-01-13 17:00:44 UTC
All the links above are not relevant to current bug, because they discuss ways of improving situation over what is available in X11 session. But at the moment situation in Wayland session is much worse than in X11 session.
Comment 24 kiv.apple 2019-01-13 17:09:40 UTC
I want to add my opinion:
1) Raster scaling of windows for current DPI is a feature of KWin. Many other Wayland compositors can't do it. As far as I understand, this is a non-standard feature, so you should not demand support in XWayland, the settings should be in KWin itself.
2) Gnome somehow managed to implement the correct scaling of some X.org applications (Google Chrome) when changing DPI (dragging to another display). They may have applied not very elegant solutions, but if it is "just work," then what's wrong with that? I think the most important thing is a good experience of users of your DE, and beautiful technical solutions are only in second place. In the harsh real world, they are not always possible within a reasonable time.
Comment 25 Eike Hein 2019-01-13 17:22:20 UTC
Please don't change the bug state set by developers.
Comment 26 David Edmundson 2019-01-13 22:27:51 UTC
>this is a non-standard feature

No. 

>Gnome

Also no. See their above link brainstorming solutions.
Comment 27 kiv.apple 2019-01-13 22:45:37 UTC
1) Raster window scaling is done by code in KWin, isn't it? Because I remember very well that it was in KDE that this feature appeared first. Of course, you can wait for the necessary functionality to be added to XWayland, and then wait a few more years for the common applications to start supporting it (but they will most likely migrate to Wayland during this time). Or you can quickly add the ability to disable-enable raster scaling for individual applications (and develop default behavior as XWayland evolves as you want). As a result, users will be able to comfortably use KDE on Wayland today, rather than wait for years.

2) GNOME have some sort of workaround especially for Google Chrome. It is running Xwayland, but when you more its window to another screen DPI is changed. The DPI of the mouse pointer remains the same as the monitor, where the window first appeared (that is, there is every reason to assume that GNOME sends some special message to Google Chrome and it itself changes the size of the window and the scaling factor). Given that most other applications support Wayland normally and problems only with popular browsers, this workaround is in fact decisive for many people who would like to use Wayland but cannot without a browser.
Comment 28 Martin Flöser 2019-01-14 05:18:42 UTC
Weston supported scaling ages prior to KWin.
Comment 29 David Edmundson 2019-01-14 08:57:09 UTC
> Or you can quickly add the ability to disable-enable raster scaling for individual applications

We literally cannot for individual xwayland clients.

Potentially we could do tonne of hacks to make and add an input transformations framework everywhere to put a toggle for all xwayland. 

But at that point it'll be just as quick to put the option in xwayland where it benefits every other project - which is my stance that I've already stated ages ago.


---

Gnome behaviour depends on gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" which will be the default soon putting it in line with kwin and everyone else.

>there is every reason to assume that GNOME sends some special message

No it doesn't.
Comment 30 Roman Gilg 2019-01-23 21:34:09 UTC
FYI I have written patches for KWin and XWayland with a solution attempt:

https://gitlab.freedesktop.org/xorg/xserver/merge_requests/111
https://phabricator.kde.org/D18486
Comment 31 David Edmundson 2019-02-14 14:36:45 UTC
*** Bug 404343 has been marked as a duplicate of this bug. ***
Comment 32 Nate Graham 2020-10-11 03:26:48 UTC
*** Bug 412088 has been marked as a duplicate of this bug. ***
Comment 33 Nate Graham 2021-08-12 16:07:31 UTC
*** Bug 440883 has been marked as a duplicate of this bug. ***
Comment 34 David Edmundson 2022-01-09 21:49:14 UTC
*** Bug 448136 has been marked as a duplicate of this bug. ***
Comment 35 Dāvis 2022-04-11 21:17:33 UTC
Why this bug report is closed? It's still broken...
If this is XWayland bug, then where's the link to upstream bug report?

I've noticed that setting Wayland scaling breaks badly some games running under XWayland with Wine.
I want to keep Wayland scaling (seems to be working fine at 150% for Wayland apps I use) but disable any scaling for XWayland because most apps work way better on X11 without any scaling than this broken scaling.

This particular issue I just encountered isn't related to blurriness but window shaking/resizing and wrong resolution. It's hard to describe in words so watch this video demonstration https://youtu.be/AS9H8QrV5Ig

Basically I've native Wayland resolution of 3440x1440 with 150% scaling and that causes XWayland to report incorrect resolution of 2288x960 which a lot of applications can't handle as they're used to standard resolutions so I think it would be very useful if we could force "regular" resolution to X11 clients.

Also are there any workarounds for this other than disabling scaling altogether?

by the way I'm using latest KWin git master and
$ Xwayland -version
The X.Org Foundation Xwayland Version 22.1.1 (12201001)
X Protocol Version 11, Revision 0

$ wayland-info
interface: 'wl_compositor',                              version:  4, name:  1
interface: 'zwp_tablet_manager_v2',                      version:  1, name:  2
interface: 'zwp_keyboard_shortcuts_inhibit_manager_v1',  version:  1, name:  3
interface: 'xdg_wm_base',                                version:  4, name:  5
interface: 'zwlr_layer_shell_v1',                        version:  3, name:  6
interface: 'zxdg_decoration_manager_v1',                 version:  1, name:  7
interface: 'wp_viewporter',                              version:  1, name:  8
interface: 'wl_shm',                                     version:  1, name:  9
        formats: 'XB48'(0x38344258) 'AB48'(0x38344241) 'XB30'(0x30334258) 'AB30'(0x30334241) 'XR30'(0x30335258) 'AR30'(0x30335241) XRGB8888 ARGB8888
interface: 'wl_seat',                                    version:  7, name: 10
        name: 
        capabilities: pointer keyboard touch
        keyboard repeat rate: 25
        keyboard repeat delay: 660
interface: 'zwp_pointer_gestures_v1',                    version:  3, name: 11
interface: 'zwp_pointer_constraints_v1',                 version:  1, name: 12
interface: 'zwp_relative_pointer_manager_v1',            version:  1, name: 13
interface: 'wl_data_device_manager',                     version:  3, name: 14
interface: 'zwlr_data_control_manager_v1',               version:  2, name: 15
interface: 'zwp_primary_selection_device_manager_v1',    version:  1, name: 16
interface: 'org_kde_kwin_idle',                          version:  1, name: 17
interface: 'zwp_idle_inhibit_manager_v1',                version:  1, name: 18
interface: 'org_kde_plasma_shell',                       version:  6, name: 19
interface: 'org_kde_kwin_appmenu_manager',               version:  1, name: 20
interface: 'org_kde_kwin_server_decoration_palette_manager', version:  1, name: 21
interface: 'org_kde_plasma_virtual_desktop_management',  version:  2, name: 23
interface: 'org_kde_kwin_shadow_manager',                version:  2, name: 25
interface: 'org_kde_kwin_dpms_manager',                  version:  1, name: 26
interface: 'org_kde_kwin_server_decoration_manager',     version:  1, name: 27
interface: 'kde_output_management_v2',                   version:  2, name: 28
interface: 'kde_primary_output_v1',                      version:  1, name: 29
interface: 'zxdg_output_manager_v1',                     version:  3, name: 30
        xdg_output_v1
                output: 43
                name: 'DP-1'
                description: 'Acer Technologies X34 GS/277881511'
                logical_x: 0, logical_y: 0
                logical_width: 2293, logical_height: 960
interface: 'wl_subcompositor',                           version:  1, name: 31
interface: 'zxdg_exporter_v2',                           version:  1, name: 32
interface: 'zxdg_importer_v2',                           version:  1, name: 33
interface: 'xdg_activation_v1',                          version:  1, name: 36
interface: 'wp_drm_lease_device_v1',                     version:  1, name: 37
interface: 'wl_drm',                                     version:  2, name: 40
interface: 'zwp_linux_dmabuf_v1',                        version:  4, name: 41
...
interface: 'kde_output_device_v2',                       version:  2, name: 42
interface: 'wl_output',                                  version:  3, name: 43
        x: 0, y: 0, scale: 2,
        physical_width: 800 mm, physical_height: 350 mm,
        make: 'Acer Technologies', model: 'X34 GS/277881511',
        subpixel_orientation: unknown, output_transform: normal,
        mode:
                width: 3440 px, height: 1440 px, refresh: 179.999 Hz,
                flags: current
interface: 'zwp_text_input_manager_v2',                  version:  1, name: 44
interface: 'zwp_text_input_manager_v3',                  version:  1, name: 45
interface: 'org_kde_kwin_contrast_manager',              version:  2, name: 46
interface: 'org_kde_kwin_blur_manager',                  version:  1, name: 47
interface: 'org_kde_kwin_slide_manager',                 version:  1, name: 48


$ xrandr
Screen 0: minimum 16 x 16, current 2293 x 960, maximum 32767 x 32767
XWAYLAND0 connected primary 2288x960+0+0 (normal left inverted right x axis y axis) 800mm x 350mm
   2288x960     179.95*+
   1280x960     179.87
   1152x864     179.78
   1024x768     179.84
   800x600      179.71
   640x480      179.43
   320x240      178.06
   1440x900     179.84
   1280x800     179.74
   720x480      179.35
   640x400      179.55
   320x200      176.99
   1600x900     179.77
   1368x768     179.92
   1280x720     179.72
   1024x576     179.77
   864x486      179.75
   720x400      179.53
   640x350      179.74
Comment 36 Nate Graham 2022-04-11 21:21:22 UTC
(In reply to Dāvis from comment #35)
> Why this bug report is closed? It's still broken...
Please see https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean

> If this is XWayland bug, then where's the link to upstream bug report?
In the URL field.

The issue is currently being worked on by multiple people and organizations at multiple levels of the graphics stack. Not to worry, it'll get fixed.
Comment 37 Dāvis 2022-04-11 21:40:55 UTC
(In reply to Nate Graham from comment #36)
> (In reply to Dāvis from comment #35)
> > Why this bug report is closed? It's still broken...
> Please see
> https://community.kde.org/Get_Involved/
> Issue_Reporting#Understand_what_the_resolution_statuses_mean
> 

There's actually nothing written about "CLOSED UPSTREAM" state :P and also I would say it's bad idea to close issue if it's not resolved so it can be easier findable as people might think it doesn't apply to them and open new issues. Also I would say upstream needs to see how many people are impacted so everyone should be pointed there.

> > If this is XWayland bug, then where's the link to upstream bug report?
> In the URL field.

That's a MR for potential fix, not bug report itself but sure.

Also this affects many applications, here's issue for mpv https://github.com/mpv-player/mpv/issues/9443
Comment 38 Nate Graham 2022-08-09 14:35:01 UTC
This is fixed in Plasma 5.26! \o/