My various settings in X to get programs working on my HiDPI display

May 27, 2020

Back when I got my HiDPI display (a 27" Dell P2715Q), I wrote an entry about what the core practical problems with HiDPI seemed to be on Linux and talked in general terms about what HiDPI related settings were available but I never wrote about what specific things I was setting and where. Today I'm going to remedy this, partly for my own future use for the hopeful future day when I need to duplicate this at work. Since I'm doing this two years after the fact, there will be an exciting element of software archaeology involved, because now I have to find all of those settings from the clues I left behind in earlier entries.

As mentioned in my old entry, the Dell P2715Q is a 163 DPI display. To make the X server itself know the correct DPI, I run it with a '-dpi 163' command line argument. I don't use XDM or any other graphical login manager; I start the X server from a text console with a nest of shell scripts, so I can supply custom arguments this way. I don't do anything with xrandr, which came up with plausible reported screen dimensions of 597mm x 336mm and didn't appear to need any changes.

I use xsettingsd as my XSettings daemon, and set two DPI related properties in .xsettingsd:

Gdk/UnscaledDPI 166912
Xft/DPI 166912

Both of these values are my 163 DPI multiplied by 1024. For Xft/DPI, this is documented in the Xsettings registry. I'm not sure if I found documentation for Gdk/UnscaledDPI or just assumed it would be in the same units as Xft/DPI.

There is also an X resource setting:

Xft.dpi: 163

As we can see, this is just the DPI.

Then I set some environment variables, which (in 2018) came from Arch's HiDPI page, the Gnome wiki, and the GTK3+ X page. First there is a setting to tell Qt apps to honor the screen DPI:


Then there is a pair of GTK settings to force GTK+ applications to scale their UI elements up to HiDPI but not scale the text, as explained in more depth in my original entry:

export GDK_SCALE=2
export GDK_DPI_SCALE=0.5

These three environment variables are only necessary for Qt and GTK+ applications, not basic X applications. Basic X applications seem to work fine with some combination of the Xft.dpi X resource and the XSettings system.

If you're running remote X applications from your HiDPI X session, as I am these days, they will automatically see your Xft.dpi X resource and your XSettings settings. They won't normally see your (my) specially set environment variables. Fortunately I mostly run basic X applications that only seem to use X resources and perhaps XSettings, and so basically just work the same as your local versions.

(At least after you fix any problems you have with X cursors on the remote machines.)

At the moment I'm not sure if setting the environment variables for remote X programs (for instance by logging in with 'ssh -X', setting them by hand, and then running the relevant program) works just the same as setting them locally. Some testing suggests that it probably is; while I see some visual differences, this is probably partly just because I haven't adjusted my remote programs that I'm testing with the way I have my regularly used local ones (after all, I normally use them on my work regular DPI displays and hopefully some day I'll be doing that again).

The final setting I make is in Firefox. As mentioned in passing in this entry, I manually set the about:config setting layout.css.devPixelsPerPx to 1.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. A devPixelsPerPx setting of 1.7 is 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.

Sidebar: X resources tweaks to specific applications

Xterm sizes the width of the scrollbar in pixels, which isn't ideal on a HiDPI display. It is normally 14 pixels, so I increased it to:

XTerm*VT100.scrollbar.width: 24

Urxvt needs the same tweak but it's called something different:

URxvt*thickness: 24

I think I also tried to scale up XTerm's menu fonts but I'm not sure it actually worked, and I seem to have the same X resource settings (with the same comments) in my work X resource file.

Comments on this page:

Yeah, 163 รท 1.7 = 95.88, which matches the traditional/default 96 dpi. Using 2.0 instead of 1.7 would make Firefox think it needed fewer pixels to reach a standard size. Which makes me wonder, with the recent trend of expanding UI elements for touch friendliness, what would happen with 2.0 scaling and a default text size of 19 px? Perfection, or broken layouts everywhere?

I'd test this out myself, but I don't have any HiDPI hardware.

Once upon a time, though, I had my monitor's physical dimensions set in Xorg.conf so that I could have the GIMP display in exact physical size. (I thought it was cool.) One day, things didn't come up right. X had failed to get modelines and safely assumed 640x480, but it still knew the monitor size. This resulted in ~47 dpi, and normally readable text being a few very blurry pixels tall. Kind of comforting that everything "worked", but also hilariously useless.

Written on 27 May 2020.
« My failure with Xpra (probably because what I want is almost impossible)
What I think OpenSSH 8.2+'s work toward deprecating 'ssh-rsa' means »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed May 27 00:43:43 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.