To scale or not to scale... confused a bit

[digitaltrails]

@digitaltrails

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

% echo 'export QT_FONT_DPI=162' > /home/tumb1/.config/plasma-workspace/env/hidpi.sh

% cat /home/tumb1/.config/plasma-workspace/env/hidpi.sh
export QT_FONT_DPI=162

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.

I recently read the Qt documentation on “highdpi”: https://doc.qt.io/qt-6/highdpi.html, the salient parts being:

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.

echo 'export QT_USE_PHYSICAL_DPI=1' >> /home/testuser/.config/plasma-workspace/env/hidpi.sh

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.