The trials and tribulations of UI scaling on Linux

A little over a month ago I wrote about an issue I was having in Linux, where playing a video would cause processor usage to skyrocket, and hence, increase the heat output considerably, causing the fans in my laptop to spin up loudly. This behaviour was Linux-specific, as it didn’t happen when using the same laptop in Windows.

I experienced the problem on KDE Neon and the latest KDE release and on Linux Mint running Cinnamon. After publication of the article, and at the suggestion of lakerssuperman2, I tried the latest release of Ubuntu running GNOME, but there, too, I experienced the problem. Many other readers were quite helpful in trying to get the problem fixed – or at least diagnosed – but I wasn’t getting anywhere.

Until just-me pointed something out:

I have the same laptop. I watch YouTube daily and don’t remember the fans ever kicking in for that.

[…]

But I just noticed that you have the 4K screen (my model has the FHD screen – by choice) – so that might explain the difference.

This turned out to be an interesting avenue of investigation. I had considered the resolution of my display as a possible culprit before, but disregarded it since I couldn’t imagine the difference between 1080p and 4K having any meaningful impact. After some fiddling with my settings, however, I concluded that while the resolution indeed was not the problem – something related to it was: user interface scaling.

As soon as I turned off 200% scaling and set it to 100% – making the user interface near-unusably small in the process – the problem disappeared entirely. Finally, after years of fighting this problem, I seemed to have nailed the cause, with the help of the OSNews readership (thank you!). I couldn’t believe it looked like it was something as simple as UI scaling.

Of course, running 4K at 100% scaling on a 13″ display is not exactly ideal, so I set to experiment with different combinations of resolutions and scaling factors to pinpoint if certain combinations were more or less problematic than others. Running a quick command to enable fractional scaling (gsettings set org.gnome.mutter experimental-features "['x11-randr-fractional-scaling']") to give me access to 125%, 150%, and 175% scaling factors, I discovered that setting the factor to anything but 100% would cause the problem.

I eventually settled on a decent middle ground of 2048×1152 at 100% scaling, with the UI fonts set to 11. Of course, this doesn’t make optimal use of a 4K display, but things look great and crisp, correctly sized, and completely usable. But most importantly, temperatures and processor usage is now effectively on par with Windows.

This means that there is an issue somewhere with how scaling seems to be implemented in either X.org, the Intel driver, the Mutter/Kwin window managers, or any combination thereof. Since both Mutter and Kwin seem to have the problem, my gut feeling is that there’s an issue somewhere in the Intel driver or in how the driver interacts with X.org (as a side note, I tried running Ubuntu with Wayland and GNOME, but performance as a whole seemed problematic there).

Ever since, I’ve been running Linux on my XPS 13 without any issues, the fans never even turn on, temperatures remain well within expected values, and I have no more issues playing videos. Thanks to you, OSNews readers, I’ve been able to solve – or at least, circumvent – an issue that has been frustrating me for a long, long time.

28 Comments

  1. 2019-12-30 4:13 pm
  2. 2019-12-30 4:14 pm
    • 2019-12-30 5:01 pm
    • 2019-12-31 4:46 am
      • 2019-12-31 8:12 am
      • 2020-01-02 5:13 pm
  3. 2019-12-30 5:42 pm
    • 2020-01-02 3:57 pm
  4. 2019-12-31 12:27 am
    • 2019-12-31 1:35 am
      • 2019-12-31 3:02 am
        • 2019-12-31 3:57 am
          • 2020-01-03 10:43 am
  5. 2019-12-31 6:14 am
    • 2019-12-31 8:13 am
    • 2020-01-01 12:57 pm
  6. 2019-12-31 6:39 am
  7. 2019-12-31 4:05 pm
    • 2020-01-01 12:39 am
      • 2020-01-01 11:46 am
        • 2020-01-02 8:16 am
          • 2020-01-02 8:40 am
        • 2020-01-02 9:03 am
        • 2020-01-02 4:04 pm
          • 2020-01-03 8:27 am
      • 2020-01-01 12:01 pm
        • 2020-01-02 6:20 am
  8. 2020-01-02 8:46 am