Extracted from NixOS/nixos-hardware#157

cc @gnidorah @colemickens can you give some feedback how this module would work on wayland? Right now I have only tested it on x11.

@Mic92 Doesn't work under sway, but sway has an own DPI settings. Perhaps @primeos could add more.

I don't think overriding X11/fontconfig default DPI is a good idea. Lots of things act awkwardly or break with dpi ≠ 96 and, e.g. sway and GNOME kind of expect X11/fontconfig settings to be unscaled for Wayland HiDPI. Similarly, hardcoding GDK_SCALE/_JAVA_OPTIONS is inappropriate as many people will want fractional or 3× scaling and in general you shouldn't set GDK_SCALE if you don't have to (it breaks per-monitor scaling factors among other things).

The console font latarcyrheb-sun32 is larger than ter-u28n (in fact it's the largest size the Linux console will support), and is already included in kbd (so avoids the terminus_font dependency). It's upscaled, though; I forget if Terminus ships with 16x32 fonts but spleen does.

Is there a reason to set boot.loader.systemd-boot.consoleMode? UEFI firmware will generally initialize at the native resolution of the panel, and the default is to keep it. It seems ArchWiki's recommendation is to set it to 1, which loader.conf(5) documents as meaning an 80x50 mode that is "not supported by all devices", but I don't think that's a good way to increase the font size: changing graphics mode during boot is slow and leads to flickering and bad LCD panel scaling, which is exactly the kind of thing fussy modern HiDPI laptop users don't like :) That said, I haven't tested it: if it just results in the UEFI firmware emulating a lower "text display resolution" on top of the native panel resolution then it could be a good solution.

(Basically the common theme here is that there's not a lot you can usefully statically set to get HiDPI configs working. But I think having a profile to get console/bootloader fonts readable is a good idea, especially if nixos-generate-config could autodetect HiDPI, and it gives the opportunity to add toolkit/desktop-environment-specific workarounds in the module where needed.)

I haven't found a good way to enable HiDPI without setting the -dpi flag (in SDDM+Plasma5). I don't understand why xserver can't detect my DPI from the EDID, I thought it was an Nvidia quirk, but perhaps it's intentional to preserve the 96 dpi. Xorg.log reports Max Image Size [cm]: horiz.: 34 vert.: 19 on Dell XPS 9570 with Nvidia proprietary driver.

That said, I think we should have a clear warning in the description that this is a collection of hacks, and not really an ideal way to set DPI. In addition to the issues @emilazy describes, I think this messes up external monitors. At least it will use 196 dpi regardless of individual DPIs.

That's because the X11 DPI setting is basically deprecated and the server just sets it to 96 no matter what, precisely because it wasn't a great solution for HiDPI. It can be useful as a hack for toolkits that don't support native HiDPI scaling, but those are increasingly rare these days, and it generally makes behaviour worse for the majority of applications using toolkits that do understand HiDPI.

If you're running without a desktop environment that manages the scaling settings for you, then your best bet is to set QT_AUTO_SCREEN_SCALE_FACTOR/QT_SCREEN_SCALE_FACTORS/QT_SCALE_FACTOR, GDK_SCALE, etc. and use various hacks for older toolkits (e.g. there are GTK+ 2 themes for HiDPI that just scale everything up by a fixed factor). The ArchWiki page has a lot of good information, and it might be worthwhile to expose a twiddle to turn this stuff on to a fixed scaling factor for people who want simple single-output HiDPI support on X11 without a desktop environment, but it should probably not be the recommended HiDPI configuration or coupled to making console fonts readable at boot, since it'll make things worth for both the common cases and the cases that actually have the potential for best HiDPI support (GNOME, KDE, Wayland incl. sway, ...).

Edit: Sorry, missed your mention of Plasma... not finding any clear-cut information online, but I think it's worth twiddling with the QT_* variables to see if it gets things working for you.

Edit: Sorry, missed your mention of Plasma... not finding any clear-cut information online, but I think it's worth twiddling with the QT_* variables to see if it gets things working for you.

So it looks like setting QT_FONT_DPI=196 and GDK_DPI_SCALE=1 are enough to get most apps working. Emacs still looks at xorg dpi though. I wish I didn't have to specify QT_FONT_DPI though, maybe this is a bug? Also I think this fails in sddm since all of the plasma5 stuff hasn't been run yet.

I don't think overriding X11/fontconfig default DPI is a good idea. Lots of things act awkwardly or break with dpi ≠ 96 and, e.g. sway and GNOME kind of expect X11/fontconfig settings to be unscaled for Wayland HiDPI. Similarly, hardcoding GDK_SCALE/_JAVA_OPTIONS is inappropriate as many people will want fractional or 3× scaling and in general you shouldn't set GDK_SCALE if you don't have to (it breaks per-monitor scaling factors among other things).

If they set a different scale by changing GDK_SCALE/_JAVA_OPTIONS it gets overriden, no? How to make it work without GDK_SCALE? gsettings does not work outside of gnome afaik. Does this mean, we have to enable the gnome-settings daemon to enable it?

The console font latarcyrheb-sun32 is larger than ter-u28n (in fact it's the largest size the Linux console will support), and is already included in kbd (so avoids the terminus_font dependency). It's upscaled, though; I forget if Terminus ships with 16x32 fonts but spleen does.

I used this font because it does not conflict with our nixos-generate-config.

Maybe someone else can take this over. I just picked some settings, that worked for me.

These settings are also used in the wiki: https://nixos.wiki/wiki/Xorg

Here is a subset of the changes: #87730
The linux console stuff seems uncontroversial.