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?
Possibly upscaling could be replaced by downscaling for the lower DPI screens.
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.
*** Bug 389196 has been marked as a duplicate of this bug. ***
(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.
Good idea!
*** Bug 390049 has been marked as a duplicate of this bug. ***
Is there a temporal workaround that allows to completely disable the scaling of XWayland applications without recompiling KWin?
(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
Pls name a few test applications on Xwayland, which show these behavior. Which scale factor are you using?
Prime examples are Chromium and Firefox (I'm using 2x usually).
Another one is Emacs. Unlike Firefox and Chrome it likely won't support Wayland natively in the near future either.
The addition of XDG Output Protocol could solve this issue: https://phabricator.kde.org/D12235
>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.
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)
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.
I'm not super happy with this being marked WONTFIX. It makes the Wayland session extremely unpleasant to use for the time being.
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
> 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.
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
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.
I think there's some people working on it now: https://keithp.com/blogs/window-scaling/
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
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.
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.
Please don't change the bug state set by developers.
>this is a non-standard feature No. >Gnome Also no. See their above link brainstorming solutions.
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.
Weston supported scaling ages prior to KWin.
> 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.
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
*** Bug 404343 has been marked as a duplicate of this bug. ***
*** Bug 412088 has been marked as a duplicate of this bug. ***
*** Bug 440883 has been marked as a duplicate of this bug. ***
*** Bug 448136 has been marked as a duplicate of this bug. ***
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
(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.
(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
This is fixed in Plasma 5.26! \o/