I’ve been using a 4K monitor in X11 by setting the KDE font DPI - which has worked quite well for the past few years (after a few adjustments to the panel size, konsole font, and so on).
Looking toward a move to Wayland, I noted that setting the font DPI has been removed. I just briefly experimented with scaling on Wayland in KDE 6. It’s a bit confusing.
I set the scaling to 150%. Gimp seemed to still show images non-scaled, which is fine, I don’t want images I’m editing to be scaled. But showfoto and google-chrome appeared to scale the images, so if I looked at an image at 100%, I think it was showing 150%, which is definitely not desirable.
It seems to me I shouldn’t scale. But that seems contrary to what a lot of folk seem to be doing. Plus if I don’t scale, the absence of the old font-dpi setting means I have to manually adjust all fonts, which might presumably have effects on viewing versus printing documents.
So am I seeing this right, if I scale, everything including photos are scaled (in some apps, but not in others), and if I don’t scale I have to manually tweak all the fonts.
(Apologies in advance if I failed to find some comprehensive FAQ/Howto on the topic.)
After some searching I can see one option I have is to force Wayland to behave like X11 by setting scaling to 100% and setting the environment variable QT_FONT_DPI to the actual DPI of my display.
This can be done for a specific user by creating /home/tumb1/.config/plasma-workspace/env/hidpi.sh
The only item this doesn’t seem to work on is window-titles, but they can be customised under Settings → Text and Fonts to be something large like 16 pt - which then looks OK.
Thanks, not being familiar with using Wayland, I had not considered that some applications might be running under XWayland. Something to be aware of in future.
For my own photographic hobby “work”, anything that doesn’t scale photo’s is correct, so I’d be doing myself a disservice to report that as a bug.
It’s great to have options. I have already decided to delay switching to Wayland until window placement save/restore at logout/login is added (timeframe for which is unknown). X11 works fine in the meantime. I will continue to kick the tires on Wayland to ensure I can easily transition at some point.
Tumbleweed.
After giving the mater some thought, I think 4k unscaled is what is best for my photo hobby work. So I just need to make that workable for other needs, for example, another hobby is coding.
I have already discovered that, under KDE-Wayland, QT_FONT_DPI can create a workable equivalent to what I do in X11, which is great.
I have to acknowledge that using QT_FONT_DPI for hacking kwin is not recommended or supported, but I can live-with that (I’m already doing other unsupported things, such as disabling kscreen2 to prevent hot-plugging VDUs from moving windows around). I guess KDE may evolve in a direction that makes this unworkable, but I suppose there would be other options:
Maybe I could try to create a 100%4k theme.
Maybe 4K monitors large enough to neither require scaling nor QT_FONT_DPI will become cheaply available.
Scaling in Wayland, is about scaling the UI, while keeping the full resolution for the content, here it would be photos. You can see it in action in dolphin information panel preview for instance with a scaling factor, the image rendered will stay the same at equivalent size.
I guess that’s the theory, but I suppose it’s up to each application developer to implement. Getting 100% scaling (no scaling) is easy, it most likely works out of the box. But deciding whether to display content actual or scaled size probably depends on context and it also requires the developer to get it right.
I scaled a Wayland display, and then opened the same PNG in several different applications. Only Gwenview displayed the PNG with no scaling. Oddly showfoto actually showed a scaled down image for 100% (bug?). Popular photo editing tools seemed scaling-unaware and just displayed scaled up images.
So it seems that if I want consistency for this PNG across all applications, it’s best not to scale.
If GUI text is too small, as described in my own solution above, I can set QT_FONT_DPI (and live with an unofficial/not-supported approach - which is fine, this is Linux).
Context is another issue, if I’m working on a photo I probably don’t want scaling, but if I’m working on an icon maybe I do.
Not having used scaled-displays, I would admit it’s possible I’m misinterpreting something. I can see that when coding (python/C/…), scaling displays is quite workable, I could see me using scaling in that scenario. I suppose I’m using HiDPI for more pixels, whereas others may be buying it for less-jaggy retina-display looking graphics.
With GIMP 3.0 on GTK3 there is user interface improvements including the likes of native Wayland support and properly supporting HiDPI displays.
That’s the chicken and egg issue: do apps adapt if users don’t use Wayland yet? Do users use Wayland if apps don’t support it?
Give it a few months and only under-maintained apps won’t have support for this.
With more users using Wayland, they will report issues to apps…
That’s always been this way for platform innovation, slow diffusion of new tech…
Still it might not be easy for those apps, still not requiring rewriting the whole app, so this will need some time.
This fractional scaling is about having maximum resolution rendering of fonts and images while scaling the UI for screen. Best of both worlds.
For icons, you’d want zooming. Then it the application UI size to choose how big it wants to be.
OK, so it’s just a matter of time. I’ll continue to kick the tires on Wayland from time to time. In the meantime I have X11. Perhaps I can even contemplate a move to Wayland by using QT_FONT_DPI to carry me through until all the applications catch up.
Good to hear.
Thanks for taking the time to outline the objects and plan for the way forward and the reason for the current discrepancies.
QT_FONT_DPI Sets a global DPI. This is a legacy environment variable provided for backwards compatibility.
QT_USE_PHYSICAL_DPI Makes Qt use physical DPI instead of logical DPI. Using logical DPI is normally the best option; this environment variable can be set in cases where logical DPI is not available and the physical DPI is known to be correct.
The upshot being QT_USE_PHYSICAL_DPI may also be used to force the use of the physical DPI. This has the advantage over QT_FONT_DPI that it doesn’t require hard wiring the physical DPI value.
I tested QT_USE_PHYSICAL_DPI, on a relogin it does result in bringing all image viewers, browsers, and image editors into agreement on 100% being 100% at native DPI. Documents viewers when set to 100% also preview at actual print size, and plan dimensions seem to be in the ballpark as well. The need to alter the window title in Settings → Text and Fonts is still required.
Because it automatically uses native DPI without any hardwiring, this is probably the best (interim) solution for those facing this issue.
