It seems we can go round in circles indefinitely. 100% is 100%. 150% will always give you grief, when used as a starting point, irrespective of your ongoing calculations. I wish you luck.
1 Like
Hope it helps! After I re-read through the blog post that I sent earlier, “HiDPI Linux Hassles”, I noticed something that lines up with your reported observations above. This section specifically:
If your DPI is high enough and your display has enough pixels, it seems to be common for programs and toolkits to automatically engage a scaling mode. This example from Fedora’s Anaconda seems to be typical; it doubles things if, well, let me quote from the comment:
Check if this monitor is high DPI, using heuristics from
gnome-settings-dpi. If the monitor has aheight >= 1200 pixelsand aresolution > 192 dpiin bothxandydirections, apply a scaling factor of2so that anaconda isn’t all tiny[.]Now my life gets awkward. The honest DPI setting for the Dell P2715Q is
163DPI, which is under the192DPI that will trigger automatic scaling. However, the Dell definitely needs scaling; unscaled UI elements are far too small. One option is to lie about the display DPI; however, this distorts all font sizing, including in programs and toolkits that don’t expose any good way of adjusting the font size by hand (at least, not outside of their desktop environment).(This heuristic is also not guaranteed to work in all toolkits and for all programs.)
So, it seems that your display with native DPI of 183 falls into the same category (height >= 1200px, but DPI < 192), as that user’s display (the Dell P2715Q). In this case, the auto-scaling factor heuristic mentioned for anaconda would not apply because your display’s native DPI is less than the “HiDPI” heuristic threshold of 192:
( height >= 1200px ) == ( 1440px >= 1200px ) == true( DPI > 192 ) == ( 183dpi > 192dpi ) == false
It’s unclear whether this heuristic is applied across all GTK apps, and no mention of KDE nor QT is made, other than the user saying that QT automatic scaling doesn’t seem to work for them.
The suggested workaround for GTK is to try fiddling with GDK*_SCALE environment variables to try and forcibly address the UI widget + font scaling issues. This isn’t ideal, and seems like quite a hack, but maybe it’s one of the only ways to force applications to scale properly given the mess that is HiDPI in Xorg. However, it’s not that inconsistent with the general theme of hackiness & historical baggage that comes along with Xorg. 
… but I digress…
This part of the article mentions a set of environment variables to set for GTK apps, and also mentions the “fonts too big” problem that you may have experienced above.
Fortunately there are often ways to manually tell things to scale their UI up, as covered in the Arch Wiki entry on HiDPI. What you want to do depends on the toolkit, and it also depends on whether various magic bits of the toolkit work right (the QT automatic scaling doesn’t seem to work for me, for example). Another gotcha is how this interacts with the DPI settings, as illustrated by GDK 3. If you want ordinary, non-toolkit applications that use XFT fonts to scale their fonts correctly, you must set the X DPI to a suitable high value (whether honest or otherwise). This will also scale fonts in GDK 3 applications, but it won’t scale GDK 3 UI elements (unless your DPI is above the magic threshold). If you want to explicitly scale GDK 3 UI elements, you must force scaling:
export GDK_SCALE=2However, this scales everything in GDK 3 applications, including their fonts, which are already properly scaled because of the X DPI; the result is a decent sized UI but giant fonts. In order to return fonts back to where they started, you must tell GDK 3 to un-scale the text again:
export GDK_DPI_SCALE=0.5(Fiddling with XSettings might work around this.)
I haven’t had to resort to trying this out, because I don’t have a HiDPI monitor and also now use Wayland + Sway. So, I can’t provide any endorsement or further guidance on whether this will work or not.
EDIT: Some further info regarding KDE + HiDPI
While I’d suggest starting with 100% scaling first, if only to get the relative sizing of fonts + UI elements properly tuned for your display’s DPI… That’s only the first step when dealing with High DPI displays.
For HiDPI, expect that at 100% scaling things should look small at first before you adjust font size + scaling.
It’s been recommended by most HiDPI users, and at least one prominent KDE developer to use a scaling factor of 2 (200%). That last link also shows how to use the “Force Fonts DPI” setting in KDE circa July 2016 (probably it was on Plasma version 5.7 or 5.8). Things have probably changed since then, as a lot of development was done for HiDPI support from 5.4 and up. Here’s another KDE user who suggests 200% scaling for the HiDPI Retina display (220 DPI for Retina MacBook). They also suggest setting the environment variable:
PLASMA_USE_QT_SCALING=1
Yet, beware of the effects of this when using multiple displays with different resolutions & DPIs
One last thing: If you’re using any non-integer scaling ratio (e.g. 1.5:1 = 150%, 1.75:1 = 175%), also be aware that you may see issues with blurriness on X11 (and even Xwayland). This is called “fractional scaling”, and involves oversampling & scaling down. On Wayland, the fractional-scale-v1 protocol landed in staging, so depending on client support the experience with fractional scaling factors will be much better.
Hope this helps!
1 Like
It was for this very reason I suggested experimenting with Wayland due to there being two distinct scaling modes as opposed X11. I’m uncertain of results from that as the OP failed to elaborate much beyond ‘it didn’t work’.
1 Like
Under Wayland, “system(Wayland) scaling” produced bad result of some applications being blurred(like Firefox) with similar gigantic look. And UI and fonts in other applications being to big the same as with X11.
X11 scaling option under Wayland session make everything the same as in X11 session.
So basically no change regardless of chosen options.
Unfortunate. Still, there must be a solution; it’s just a question of discovery.
Just curious if while firefox is running you could check the output of:
xlsclients
(If it’s not installed, you can install this tool via: xorg-xlsclients package)
If firefox is shown in the output, it’s running under Xwayland. If not, it’s running as native Wayland session and yet we’re experiencing some issue with fractional scaling. 
EDIT: If it turns out that firefox is still running under Xwayland, then try: export MOZ_ENABLE_WAYLAND=1 ; firefox
I recall this was an artifact of one of the modes; probably some kind of compromise is inevitable.
Under Wayland session a set scale factor to 100% and only increase DPI in font settings, this produce somehow bearable results but still strange, font sizes the sames as in X11, and looks like they are bigger than they should be.
I manage to run Firefox natively on Wayland with Wayland scaling.
Results the same as with X11.
If I use (144 < DPI < 167) Firefox scales normally and gracefully sizes increases for each additional DPI point (and Display DPI detector - find out DPI of your monitor shows DPI = 144). When I set (167 < DPI) everything snaps to gigantic sizes and web DPI detector shows 192DPI
Here is screenshots of 167DPI and 168DPI settings.
If I don’t touch DPI settings in Appearance->Font section, and use Scaling settings at 190% in Display section instead, Firefox acts the same way. But other UI get broken as well.
Yes, however the OP seems insistent on their 150%. 
I do not understand what you are trying to say… I just mentioned 150% in Screen settings as a regime that looks Okeish.
I think I am pretty precisely document which settings under which conditions produce the relevant results. I am not trying different DPI settings with scale different from 100%.
When I touching scale settings, I let KDE to set DPI in X11 mode, and in Wayland mode as well (in Wayland DPI checkbox in Font settings must be not checked in order to scaling work properly, while in X11 mode KDE check it up and sets DPI it thinks right).
Increasing fonts sizes with wrong DPI have no use for me at all. I know how to make UI looks good. I want to use right DPI. The goal is to set DPI to 183 and keep UI sizes from exploding.
I was responding to a previous post. I’m hopeful that you’ll find a resolution soon though. In an ideal world, this really shouldn’t be as difficult.
1 Like
Hello UI seller, I going to set native DPI, and I need your strongest scaling 
1 Like
Those results are quite interesting
It seems that Firefox may be using its own heuristic based on DPI and displaying differently based on DPI > 167 as you’re observing.
In the article, “HiDPIMyXSettings”, the author notes having to adjust an about:config setting to get Firefox’s fonts to appear at a preferable size. Maybe adjusting this setting could help? (Author suggests: layout.css.devPixelsPerPx = 1.7)
The final setting I make is in Firefox. As mentioned in passing in this entry, I manually set the
about:configsettinglayout.css.devPixelsPerPxto1.7, which is down from what would be the default of ‘2’ based on my overall settings. I found that if I left Firefox alone with these other settings, its font sizes looked too big to me. AdevPixelsPerPxsetting of1.7is about right for what the Arch Wiki Firefox Tweaks page suggests should be correct here, and it looks good to me which is what I care about most.
Following the linked ArchWiki section: Firefox/Tweaks: Configure the DPI value, and using DPI 183: 183/96 = 1.90625
So for your DPI, maybe try: 1.9
Let’s just port everything to Electron instead, and let web standards sort it out!
Note, not a serious consideration; or is it? 
About Firefox, I set browser.display.os-zoom-behavior to 0
And then I can use layout.css.devPixelsPerPx to control Firefox scaling independently from system settings. In such regime Firefox scales gracefully.
1.9 scale gives smaller UI than with default Firefox behavior, but still really large.
Ok, so I digged down to FreeType library, and tried to experiment with it through python bindings. And I found some strange behavior but it needed some confirmation.
And at this moment I realized that I am standing in the bathroom only wearing pants and strangling a pigeon.
After this. I setup lover resolution for display and realized that for modern UIs small screens does not exist anymore. They all gigantic by design.
It’s probably not the first time that software complexity has led to such things… 
Reminds me if this masterpiece of an analogy I found while digging into Xkb and keyboard mapping:
Oh yes. I’ve been through there on my trip around the image. The giant vaulted Klein bottles covered with mosaics of other, different, Klein bottles … the rows of gargoyles on the roof, each holding a sign reading ``See Previous Gargoyle’’ … the little food stands around the base, where they sell you food stand vouchers, redeemable for food stand vouchers at all food stands except this one … the hall of the penitents … the giant Romanesque stained glass windows, built out of thousands of tiny LooksLike blocks, lit from behind by the radiance of the great Aka …
Truly one of the architectural wonders of our age. I’ve been there alright. And I bought postcards.
Steve Taylor, talking about software completely unrelated to XKB
2 Likes
Are you, … 100% sure? 
I am not! But I cannot find someone with actual 96DPI screen to confirm
For a some time already
For a some time already, it feels like people with actual knowledge of how something works disappeared from internet… Maybe they moved to better place, but I unable to find it. Only some small specialized communities still work for me, like Racket language discord for example. But even there I feel lack of information, for example on specialized communities like PyTorch, or some project on GitHub (popular or not), usually only one or two persons who respond in meaningful way or respond at all, usually one.
And I often find myself in situation where I encounter obvious problem and cannot find anyone else who complains about it, and I report a bug or something and developer tries to fix it, but why no one else see this before? Like I am in desert or something. I do not understand…
And I see more and more separation between user communities and developers all over the internet. Maybe corporate influence working here. Because of this there is broken feedback loop, developers living in their bubble and do not care about actual software usage, and users in their own bubble where they have no means to learn about how software works and influence something, so they just learning how to poke black box with a stick and make some workarounds.