Created attachment 5315
Stops xfce4-settings from changing DPI
Hi, xfce4-settings is overriding the DPI from my Nvidia card.
$ grep -i dpi /var/log/Xorg.0.log
[ 34403.988] (--) NVIDIA(0): DPI set to (131, 119); computed from "UseEdidDpi" X config
This is a 1920x1080 laptop monitor. With the enclosed patch (against xfce4-settings git as of 20140112), I get the expected:
$ xdpyinfo | grep reso
resolution: 131x119 dots per inch
Without the enclosed patch, I get 96x96. This is just a standard, single screen with a single XFCE panel, nothing complicated, and no reason to override, kinda similar to these controversial xorg-server bugs:
I think that something like the above code, should only be run, if the current DPI is confidently known to be invalid.
Also, let's not forget, DPI is two numbers, x and y, which can be different (especially with widescreen monitors). XFCE's "Appearance - Fonts" tab quaintly assumes they are both equal, as one number :(
Thanks for your report. I see two issues here. Both issues affect a minority of users, I suspect, as I rarely hear complaints on the DPI settings. But, I don't have data to prove that.
you can't opt-out from Xfce custom DPI settings
Xfce wrongly reports one DPI setting instead of two
Right now the patch doesn't really solve either. It removes code that works allegedly for most users. As such it's unlikely for the patch to be accepted.
I suggest you wait for Nick or Olivier to comment on how issue 1 should be handled. I'm not sure myself.
As for issue 2, could you please start with a patch that calculates two separate DPI coordinates, stores them in two separate keys (maybe /Xft/DPI/x and /Xft/DPI/y), and a GUI for changing both keys, e.g.:
GUIs are more convenient forms of customisation than Xorg config files. Following your reasoning, we also have no need for font settings or display resolution settings for instance.
Could you please write a patch that does not break Xfce's default behaviour? A sensible option would be to add a hidden Xfconf key that tells Xfsettingsd not to try and calcuate a DPI, and that hides the corresponding GUI.
A better option would be a patch that provides a GUI allowing the modification of both X and Y, and that properly calculates the default DPI based on Xorg's current settings.
This is not about customisation, it's about getting the facts straight about the monitor.
Could you please write a patch that does not break Xfce's default behaviour?
What is Xfce's default behaviour supposed to be? It should be to use the specs of the monitor, rather than blindly assume the old-fashioned 96DPI, correct?
What is Xfce's default behaviour supposed to be? It should be to use the specs of the monitor, rather than blindly assume the old-fashioned 96DPI, correct?
Correct.
Now, in order to both store the "default" value (which may change since your monitors may change), and the custom values chosen by users (who like me changed it), we need to store an affective value somewhere. Whenever you run our settings daemon, that value is the Xfconf key your patch removes: /Xft/DPI. /Xfce/LastCustomDPI is just for the UI.
Problem is you can't just remove it, because it might have purposefully been set (by an EOM, a sysadmin, a user) by other means than the UI or via the UI, and it might even be used by some apps.
HOWEVER, you could:
fix the calculation so we return the proper DPI in /Xft/DPIx and /Xft/DPIy or something like that that does not break existing code and scripts from us and others.
or, add a key that tells xfsettingsd to use the DPI value advertised by X. If it exists.
Also take into account that custom DPI should be set per-monitor and we currently have a single global value for all monitors. So we already need to improve our GUI... If you're willing to help out with this, it might be worth considering discussing how to do per-monitor DPI on the mailing list.
In my experience the Appearance dialog's "Custom DPI setting" does not change DPI or output of xdpyinfo. The setting changes effective size of most text and some UI elements; it affects even to some text that font size setting in the same dialog does not affect to. I think a better name for the setting (as such) would be Text Scaling Factor, and default value for it could be 1 (or 100%).
On the other hand xrandr --dpi $somevalue changes the DPI setting (and consequently the output of xdpyinfo), but I don't see a way to set different DPI for horizontal and vertical dimension by it either. And xrandr --dpi $somevalue does not change anything in display at least right after changing the setting. It just adjusts the computational physical dimensions of display.
GUIs are more convenient forms of customisation than Xorg config files.
True on single user computers, but not necessarily so when:
1-The computer is not a a single user computer, or
2-The user variously switches among diverse DEs, or
3-The company or network admin needs to establish and maintain control over a fleet of computers
Reliable global configuration control needs to remain both possible and practical.
See https://bugzilla.gnome.org/show_bug.cgi?id=757142 for a possible impediment to satisfactorily resolving this. "[REGRESSION][BISECTED] Recent change breaks HiDPI setup based on calculated or forced DPI" in unconditionally forcing Xft.dpi to 96 unless it has already been set, affecting apps built using the GTK3 toolkit along with GTK libs > 3.16.
This bug remains in xfce4-settings, and I believe that in the recent era of much smaller pixel-pitch displays, it has increased in severity significantly from "minor," corroborated by the mid-2018 duplicate issue #14236.
I spent a significant amount of time attempting to debug why my X server was reporting incorrect physical dimensions on my screen consisting of one monitor (the builtin one on my laptop) when xrandr reported the correct physical dimensions. It was a significant issue for me because various applications built on different toolkits were producing significantly different font sizes, some of them unreadably tiny, but if I after startup forced the server to report the correct dimensions, following that more or less all apps (with a couple minor exceptions of things that I think of as "very old-fashioned") would produce reasonable font sizes.
I could not figure out how in the world the X server was getting the wrong dimensions, and so in desperation I tried another desktop environment, expecting to see the same incorrect information, but lo, right upon startup the information was correct. After that it was not difficult to determine that if I suppressed the invocation of xfsettingsd in xfce4-session startup, then I could start xfce and the display dimensions would be correct as well, which in turn led to my finding this bug report.
I attach a patch (which I have also filed as pull request #6 (closed) at https://github.com/xfce-mirror/xfce4-settings/pull/6) which I believe resolves both of the items identified in the discussion of the issue. It treats horizontal and vertical pixel pitches separately, and it respects all of the physical information supplied by xrandr insofar as it can reasonably easily do so. In particular, if there is a single physical output for which xrandr does report physical dimensions, those dimensions will end up being used as the dimensions of the screen.
I suspect that adopting something along the lines of this patch will significantly increase the number of cases of xfce working reasonably well "out of the box" on small-pixel-pitch displays.
Thank you for your patch. I tried it on a test instance, and I can't see any difference (that's a good point, at least it does not break basic setup ;)), but I neven been annoyed by xfce' DPI detection so I can't validate :/
About ' "Custom DPI setting" does not change DPI or output of xdpyinfo. The setting changes effective size of most text and some UI element [..] and not DPI", maybe we should rephrase it ?
Skunnyk, thank you so much for your quick response. Note that this bug/patch has literally nothing to do with the "Custom DPI setting" checkbox. xfsettingsd is altering the nominal physical dimensions of the virtual screen regardless of whether that box is checked or not (and before it every looks at that setting). I am agnostic as to that checkbox. I find I get better results (i.e. more uniformly the sizes I want) with that box unchecked and the physical dimensions on the virtual screen reasonable than with that box checked (in my setup, that's more prone to "double scaling"), but I think this is largely irrelevant to the question of xfce tinkering with physical dimensions. If there's anything else I can do to facilitate ironing out this bug, please just let me know. Your efforts are very much appreciated.
Also, I just got word about the switch to gitlab.xfce,org. I am now "gwhitney" on that gitlab instance. I would be happy to fork and provide this patch as a pull request there if it would help and if someone gives me the privileges to do so. (Right now I can't fork and so as far as I know I can't make a pull request without a fork.)
Your account on gitlab has been enabled, you can fork, create a branch, then do a merge request.
I haven't really tested your patch yet (and I don't have hidpi hardware for now)
(I don't understand why my screen was detected as 508x285 millimeters btw.)
It intentionally lies. It did not "detect" 508x285. 508x285 is required to produce 96x96 DPI/PPI on a 1920x1080 display.
If you examine Xorg.n.log, you should find sections resembling the following (taken from using a nominal '31.5"' 1920x1080 native display, which is ~70cm wide by ~39cm tall):
...
[ 419.346] (II) modeset(0): Supported detailed timing:
[ 419.346] (II) modeset(0): clock: 148.5 MHz Image Size: 700 x 390 mm
[ 419.346] (II) modeset(0): h_active: 1920 h_sync: 2008 h_sync_end 2052 h_blank_end 2200 h_border: 0
[ 419.346] (II) modeset(0): v_active: 1080 v_sync: 1085 v_sync_end 1090 v_blanking: 1125 v_border: 0
[ 419.346] (II) modeset(0): Ranges: V min: 50 V max: 77 Hz, H min: 31 H max: 70 kHz, PixClock max 155 MHz
[ 419.346] (II) modeset(0): Serial No:...
[ 419.346] (II) modeset(0): Monitor name: VO32LFHDTV10A
...
[ 419.425] (II) modeset(0): Using exact sizes for initial modes
[ 419.425] (II) modeset(0): Output HDMI-1 using initial mode 1920x1080 +0+0
[ 419.425] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[ 419.425] (==) modeset(0): DPI set to (96, 96)
...
[ 419.694] (II) modeset(0): Setting screen physical size to 508 x 285
...
X and Wayland, absent configuration override, use the EDID provided dimensions to apply a logical DPI of 96x96, 508mm wide by 285mm tall for 1920x1080 resolution, instead of using those dimensions to provide a logical DPI equal to the physical DPI calculated via reported physical size and utilized screen resolution. It's illogical except to the powers that establish so-called web "standards", and those that implement (or not) those dictates in web browsers. It's an affirmative choice to support poorly styled (and mostly obsolete) web sites to the detriment of stylists that competently construct, software that competently constructs, and stylists and software that need to provide some semblance of accurately sized display screen depictions.
I completely concur with Felix Miata's description of the DPI situation above, and add only that the Gnome desktop does not perpetuate the fictional 96x96 dpi (haven't checked Plasma, but I bet it doesn't either). Have created the merge request !6 (merged) on gitlab as requested to help transition xfce to the wonderful world of (reasonably) accurate dpi settings. Thanks for your consideration of this.
With MR !6 (merged) reverted, this issue should be reopened. I have just freshly installed openSUSE Tumbleweed on a laptop with a hi-dpi display, and I added openSUSE's X11:xfce:rat respository which tracks gitlab closely and updated all of xfce4, and I have confirmed that it is using commit 604160fc for xfce4-settings (etc.) and sure enough running right out of the box:
> xdpyinfo | grep -C 1 dimensionsscreen #0: dimensions: 3840x2400 pixels (1016x635 millimeters) resolution: 96x96 dots per inch
However, the screen is actually 344mm x 215mm and the pixel density is actually 283x283 dpi. (And yes, everything on the screen is miniscule.) As always, I would be very happy to help fix this for 4.18 (as the discussion in #190 (closed), which I will post to, indicates was the milestone for resolving this.)