Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Saturday 2 April 2016

GNOME High-DPI Issues

Most sources advise using gnome-tweak-tool to set "Window Scaling" to 2 (or whatever). This alone doesn't work adequately for me; when I make my external 4K monitor primary, gnome-settings-daemon decides to set Xft.dpi to 96 because it thinks my monitor DPI is too low for scaling, even though I have set window scaling to 2. Arguably this is a gnome-settings-daemon bug. The result is that most apps look fine but some, including gnome-shell, care about Xft.dpi and don't scale. I fixed the problem by manually setting 

gsettings set org.gnome.desktop.interface scaling-factor 2
and now everything's working reasonably well. Some apps still don't support proper scaling (e.g. Eclipse) but at least they're usable when they weren't before. Still, on the Web we really did this right: make all apps work at high-DPI out of the box, scaling up individual bitmaps when necessary and rendering at high resolution automatically when we can (e.g. text), and letting DPI-aware apps opt into higher-resolution bitmaps.

My Dell XPS15 with 4K screen, and an external Dell 4K monitor, look sweet. The main problem remaining is that you can't drive a 4K monitor at 60Hz over HDMI, and this laptop doesn't have DisplayPort built in; I need a Thunderbolt3-to-DisplayPort connector which is supposed to exist but you can hardly find anywhere yet. Downside of bleeding edge tech.

Google Photos does the Right Thing by scaling images on the server to the specific window size. So you can upload original-size photos and it'll automatically pull down a massive image when you're viewing fullscreen on a 4K monitor. Now I can really tell the difference between my camera and a good camera.

Enabling touch events in Firefox and launching with MOZ_USE_XINPUT2=1 gives me touch event support in my laptop (both for Web apps and async scrolling); nice.

Forcing UI scale factors to be an integer is a mistake. In Gecko we can scale Web content by non-integer amounts and it almost never fails (or at least the same failure would have occurred with an integer scale), so I'm pretty sure there's no reason regular desktop toolkits can't do the same.

Comments

glandium
I assume this means you have the shiny new XPS 15 skylake. How well does the hardware work with Linux? I've heard horror stories about the BIOS and wifi...
Robert
Wifi worked out of the box for me with the 4.3 kernel (as shipped with Fedora 23). You have to disable Intel's RAID in the BIOS. Annoying but easy. Fedora's installer didn't set up EFI booting properly so I had to do that manually. It's Optimus so graphics is a bit of a mess. I've tried to simplify things as much as possible by using the integrated GPU only. I've had the occasional system freeze, seemingly graphics-related, but I've only just managed to completely turn off the discrete GPU (nouveau module not loaded), so we'll see how that goes. Other traditionally flaky features --- audio, webcam, hotkeys --- worked out of the box. My main problem now is that the Ctrl key is on the far left. I could probably get used to it except I plan to switch to my Thinkpad frequently. I'm experimenting with remapping CapsLock to Ctrl to see if that works for me.
Robert
Oh and I haven't really tried suspend/resume yet.
Garrett
You could also remap the Fn and Control on your Thinkpad and get used to that — it's what I do (and have done for quite a while). At least on the X230, it's a setting in the BIOS.
Emmanuele
GNOME disables scaling factors when external displays mostly because of X11; from the compositor's perspective it's all a big X Screen object, and we can only have one scaling factor setting. Wayland should fix that, because we can have multiple surfaces, one per scanout, with different resolutions and scaling factors. In general, the reason why we don't have non-integral scaling factors for toolkit surface is really a mix of legacy, missing features, and simplicity. While we could conceivably use non-integer factors for some surfaces, we only allow integer ones for windowing system surfaces. A window with fractional pixels is nonsensical — and the underlying windowing system API maps to integers anyway. Graphical assets also work best when we provide them with integer scaling factors, but we could down-scale them with decent results. We should be able to do what OSX does, and provide 1x - 1.5x - 2.x scaling factors once we use Wayland, as the 1.5x scaling factor requires the compositor to do input transformations in between, something that X cannot do. For text, though, you should already be able to set a different, non-integer scaling factor; it's part of the accessibility suite, but you can change it from gnome-tweak-tool.
Robert
I don't see code that explicitly disables scaling with external displays. Even if there is such code, it's not appropriate for my case because I want the same scaling factor for both displays.
Vincent Bernat
X11 has the concept of screens and each one can have different properties. It enables stuff like XSETTINGS to serve per-screen values. The unfortunate things is that currently, XRANDR only has one global DPI setting. Nonetheless, toolkits like GDK are able to provide a per-screen scale factor (but in the case of GDK, it's an int).
Owais Lone
Any idea how Unity pulled it off? It has had very granular scaling controls that too per monitor for at least 3 years now.