Hi, Am Samstag, 30. Juni 2018, 11:08:26 CEST schrieb Felix Miata:
Fabian Vogt composed on 2018-06-29 15:33 (UTC+0200):
Some bugs got reported which indicated that there were some issues especially in mixed-DPI environments. While they generally work fine after some (extensive) manual configuration, the automatic configuration wasn't quite that good.
While the server with access to valid EDID does correctly use display dimensions to calculate DPI, automatic DPI _configuration_ by the _server_ this way has been disallowed for well over a decade: https://bugs.freedesktop.org/show_bug.cgi?id=23705
Allowing automatic calculation was requested over 6 years ago, but has not been acted upon: https://bugs.freedesktop.org/show_bug.cgi?id=41115
DisplaySize in xorg.conf, and intervention by xrandr, have been able to make semi-automatic DPI configuration possible by enforcing the display dimensions otherwise ignored by the server. Applications can choose not to honor server DPI, looking instead to the Xresource Xft.dpi.
Yes, that's how Qt does it currently: $QT_FONT_DPI -> Xft.dpi -> X screen DPI The patch changes it to: $QT_FONT_DPI -> Xft.dpi -> XRandR DPI -> X screen DPI
Xft.dpi is the method by which KDE3, Plasma, TDE and some other DEs force DPI, while Xft.dpi is the knob Gnome uses to "scale".
Which is not entirely wrong - it's the only way to make HiDPI-unaware applications (like xterm) usable on HiDPI monitors.
3 years ago GTK3 chose to force to 96 in the absence of Xft.dpi having been set explicitly. Consequences of Xft.dpi forcing to 96 created predictable problems. Request was made to revert, and denied: https://bugzilla.gnome.org/show_bug.cgi?id=757142 openSUSE (thanks to Fabian!) rejected the upstream denial and reverted: https://bugzilla.opensuse.org/show_bug.cgi?id=1022830
Fixing this will also improve the experience during the installation (no manual configuration possible) and on desktops which don't have a UI to configure it. ...
'Tis a mess.
With this patch hopefully only if the automatic detection fails.
...
Because of the considerations I've above stated I doubt the mess will be improved by it. IMO it will little but increase the complication. We can only hope otherwise. Time will tell. Maybe this is a (the?) problem Wayland is destined to solve.
Almost. It started off as a good attempt, as wl_output got a "scale" property. This is sent by the compositor to the clients, so it's entirely up to the compositor how to set that. There is no separate configuration for font scale, that's up to the clients/toolkits. The issue with this is that the "scale" property is only an integer, so does not allow fractional scaling. It also doesn't support separate DPI for horizontal and vertical dimensions. xdg_output fixes this, as it reports its size both in physical and logical pixels. It's now up to the toolkits to handle this information in a sane way. xdg_output is AFAIK not stable yet, so it will take some time to reach us. So currently scaling with Wayland is actually worse than with X11 :-/ Cheers, Fabian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org