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: https://bugs.freedesktop.org/show_bug.cgi?id=23705 (don't force 96dpi) https://bugs.freedesktop.org/show_bug.cgi?id=41115 (add option to override) The problem is in xfsettingsd/displays.c: helper->mm_width = (helper->width / 96.0) * 25.4 + 0.5; helper->mm_height = (helper->height / 96.0) * 25.4 + 0.5; 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 :(
What is the status of this bug? Will that patch be merged?
Hi Paul, 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. 1. you can't opt-out from Xfce custom DPI settings 2. 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.: [v] Custom DPI settings ____x: [96]____y: [96] Thanks.
Paul, jakschu, Just to clarify, does Xfce override your DPI setting even when "Set custom DPI setting" is unchecked in the Appearance -> Font settings dialog?
(In reply to Steve Dodier-Lazaro from comment #2) > It removes code that works > allegedly for most users. As such it's unlikely for the patch to be accepted. Most users wouldn't notice this. I think they would just expect it to be handled sensibly ;) My patch stops XFCE from breaking settings that it shouldn't be interfering with. AFAICT, the DPI values from Xorg should be used - no need for Xfce to provide a GUI to override them.
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.
(In reply to Steve Dodier-Lazaro from comment #5) > GUIs are more convenient forms of customisation 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?
Paul, > 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: 1) 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. 2) 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.
(In reply to Steve Dodier-Lazaro from comment #5) > 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.
(In reply to Jarno Suni from comment #8) > I don't see a way to set different > DPI for horizontal and vertical dimension by it either. xrandr provides --fbmm to set actual or arbitrary display width and height dimensions.
Created attachment 9862 Respect physical dimensions of attached outputs insofar as reasonably practical
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 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.
*** Bug 14236 has been marked as a duplicate of this bug. ***
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)
xfce4-settings master, without your patch: screen #0: dimensions: 1920x1080 pixels (508x285 millimeters) resolution: 96x96 dots per inch With your patch: screen #0: dimensions: 1920x1080 pixels (293x162 millimeters) resolution: 166x169 dots per inch Output by xrand: eDP-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 293mm x 162mm It looks like your patch correctly detect the DPI for my screen ! (I don't understand why my screen was detected as 508x285 millimeters btw.)
(In reply to Skunnyk from comment #18) > (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 on gitlab as requested to help transition xfce to the wonderful world of (reasonably) accurate dpi settings. Thanks for your consideration of this.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/34. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev