Ubuntu Works With GNOME To Improve HiDPI Support On Linux Desktop

An anonymous reader shares an article: Canonical is playing host to a 'fractional scaling hackfest' in its Taipei offices this week. Both GNOME developers and Ubuntu developers are in attendance, ready to wrestle with the aim: improve GNOME HiDPI support. Ubuntu's Unity desktop (I'm told, anyhow) plays fairly nice with high DPI monitors because the shell supports fractional scaling (though most apps, I believe, do not). Furthermore, users can tweak some high DPI settings to better suit their display(s). GNOME Shell also supports HiDPI monitors, but has, until now, been a little less flexible about it. "Currently, we only allow to scale windows by integral factors (typically 2). This proves somewhat limiting as there are many systems that are just in between the dpi ranges that are good for scale factor 2, or unscaled," the hackfest page explains.

Re:

[thsths]

That is mostly because it just does not work on tablets. Neither the hardware drivers nor the GUI is suitable for tablets.

I tried a number of Ubuntu flavours, and none of them handle HiDPI in a reasonable way. Some are worse than others, of course, so there is hope.

Good!

[exomondo]

It's good news that they are moving to address things like this that are standard in other operating systems and to hopefully standardize on a way of doing it so we don't end up with everybody coming up with their own incompatible way of doing it. The issue will really come down to application support though, with so many different application frameworks on Linux they all need to support it, do so in the same way as GNOME and also then make sure that applications are written to support it. Application suppo

Re:

[Parker Lewis]

Unity already works fine with HiDPI, but Gnome 3 not so much. As the later will be the default DE, Canonical is working together with them. Apps are mixed, depending on the framework and version.

Re:

[lucm]

I use Fedora and it works perfectly well with HiDPI. Had for a long time. The only thing that doesn't work well with it is LibreOffice, but of course a lot of things don't work well when it comes to LibreOffice.

Re:

[lucm]

I dual boot Windows 10 on that same machine for work. There is no difference in font scaling or otherwise.

Fedora is one of the easiest distros to run on modern hardware, probably because they ship with a bleeding-edge kernel. If you can't get it to work, the problem is not the laptop nor Fedora.

Re:

[Ed Avis]

I've found Fedora a bit unstable on a 4k display. It looks good enough if you set the 2x scaling (although Libreoffice requires some additional mucking around with X server dpi settings, and I think Firefox needs its own config tweak too). However, with Noveau drivers and an NVS 510 card, the machine would hang after a while, particularly when using Firefox. In the end I had to go back to 1920x1080 resolution to make the system stable. That's just one anecdote, but it shows there is some work to be done

Re:

[dbIII]

It will be a long time for it to become commonly available

It is commonly available - it just wasn't in Gnome3.
Enlightenment had it many years ago and pretty well everything else did it not long after.

Re:

[exomondo]

How does Enlightenment handle HiDPI UI scaling with GTK applications for example?

Re:

[dbIII]

It has it's own toolkit for it's own applications instead of using broken Gnome3 applications.
For other stuff there's qt, gtk2 and many other things.

Seriously guys, I remember reading about this stuff on a mailing list around 2000 FFS! A lot of people were paying attention to it before the Gnome3 people even started programming!

Re:

[exomondo]

Yes this is what I mean, there's no standard way. Everybody comes up with their own way, so if you look at Fedora you can only do integer scaling even though libraries like EFL support floating point scaling for example. Is there a specification for a standard way that all these different windowing kits and libraries handle dpi unaware, dpi system aware and multi-screen dpi aware? Otherwise everybody just goes off and does their own thing and you end up with systems that people expect to work together that

Re:

[dbIII]

Here is a bit of a summary:
https://wiki.archlinux.org/ind... [archlinux.org]

Re:

[dbIII]

Yes this is what I mean, there's no standard way

Oh yes there is.
Applications such as chrome get the value for X instead of having hard coded sizes like gnome3 does. (https://wiki.archlinux.org/index.php/HiDPI#X_Server)

Typo: Value from X not "for X"

[dbIII]

Applications can get the DPI settings directly from X.
It's what that value is for FFS.

Re:

[exomondo]

Applications can get the DPI settings directly from X. It's what that value is for FFS.

DPI is only one part of it, the important other part is scaling. Do all display servers, WMs and frameworks have a common way in which DPI and scaling should be interpreted for dpi-unaware and dpi-aware applications as well as how this is dealt with in multi-monitor setups?

IMO the way Windows handles DPI and scaling in multi-monitor setups is pretty crappy.

Re:

[dbIII]

dpi-unaware and dpi-aware applications

With the greatest possible respect, what excuse is there for a graphical application designed to be used by anyone other than the original programmer to be dpi-unaware on any platform that can have more than one screen size or resolution?

Re:

[exomondo]

I don't know and I don't really care, the reality is many of them exist and are in use widely.

Re:

[tepples]

The excuse is the failure of "anyone other than the original programmer" to have donated money to "the original programmer" earmarked toward improving support for oddball pixel densities.

Re:

[mrchaotica]

That would be great, except for all the broken shit like GTK 3 that throws out the EDID-reported value and just blindly uses 96 DPI instead!

(I just installed Debian Stretch on a PC with a 27" 4k monitor, and I'm a kinda pissed off about this issue right now.)

Re:Give up, Linux losers

[postmortem]

Except Windows has its own set of problems with DPI scaling. They were resolved mostly with windows 10, but still old apps that are not "DPI aware" look terrible.

Re: Give up, Linux losers

[thebullshitpatrol]

I don't know, last time i tried running 4k on windows (9mo ago?) EVERYTHING looked like ass. Especially control panel, for some odd reason. It was super blurry.

OSX is about 20x better.

Re:

[drinkypoo]

OSX is about 20x better.

it really goddamned ought to be, considering that NeXTStep was resolution-independent.

Re:

[Trogre]

This is a joke, right?

Fonts on Mac OS look like crap even at high DPI, the icons are usually inflated way beyond what they should be and don't get me started on any legacy applications you might want to run on that HDPI display.

I'll keep using XFCE thanks.

Re:

[Trogre]

Nice try. I have to support it on a regular basis.

Re:

[Ed Avis]

Yes, Windows 10 (and this has changed a little bit with the latest version of Windows 10) tends to let older programs think they are running on a low-res screen and then scale up the resulting bitmap. This works OK, if a bit blocky, for a 2x scaling factor, but will probably be terrible for non-integer scaling. Sometimes the older program actually works fine with scaled text, if only Windows would let it. (Different font sizes and scalings have been there since Windows 3.0 at least, so all programs *ough

Re:

[AmiMoJo]

Give Windows some credit here. If you set scaling to 200% even non-DPI aware apps look at least as good as they do on low DPI monitors because they get perfect pixel doubling. That's actually better than most scalers manage to do - both AMD and Nvidia's, and the scalers built in to most displays, use blurry bi-linear scaling that looks crap.

Re:

[thsths]

I agree that Windows had too many unsuccessful attempts at HiDPI. The problem goes back to high resolution (VGA+) monitors under Windows 3.1.

However, Windows 10 has finally delivered a reasonable solution. Yes, some legacy apps look blurry, but that is a problem with the app, not with Windows.

Linux on the other hand used to be excellent for HiDPI, certainly back in the days of Windows 3.1. But it has since lost that ability under many toolkits.

"Little less flexible" my ass

[Lisandro]

GTK is still unable to properly scale bitmap icons, which means that some UI elements stay tiny while windows and fonts scale properly.

Re:

[SMOKEING]

Standard GTK themes had SVG icons since, like, 2005.

Re:

[tepples]

To which projects still not using SVG icons have you donated money earmarked toward redrawing icons in SVG since, like, 2005?

Dual monitor, 4K and 1080p

[MeNeXT]

Nice to hear that they are working on simplifying this.

After setting 2:1 scaling in Gnome I found that my 1080p monitor was almost useless and while my 4K looked great everything was too large. So I used xrandr to set things to a more comfortable level by scaling the 1080p monitor by 2x2 and the 4K by 1.6x1.6 with the following xrandr commands which run at start up.

xrandr --output DP-0 --pos 0x0 --scale 1.6x1.6
xrandr --output HDMI-0 --mode 1920x1080 --pos 6144x0 --scale 2x2

I'm using Fedora 25 but this should work for other Linux versions too. The tricky part is finding the right setting for your comfort level. So far I haven't found any issues with it. You can customize the resolution for each user if you cared.

Re:

[Trogre]

Yeah, maybe /. isn't for you.

Reddit is ---> that way.

Re:

[nullchar]

Was not aware we could set custom scaling ratios with xrandr, and keep playing with them based on varying hardware.

Only helpful post in this thread, thanks!

Re:

[MeNeXT]

The issue is that you first need to set
$ gsettings set org.gnome.desktop.interface scaling-factor 2

then check xrandr for your card/monitor support..

Here is what it looks like when set;
$ xrandr
Screen 0: minimum 8 x 8, current 9984 x 3456, maximum 32767 x 32767
DVI-D-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected primary 6144x3456+0+0 (normal left inverted right x axis y axis) 607mm x 345mm
3840x2160 60.00*+ 30.00
2560x1440 59.95

Re:

[AmiMoJo]

The best solution is to get a monitor with a physical size and resolution that is suited to 2x scaling.

The old standard for computer displays was 96 DPI. A 24" monitor at 1080p is around that, so to get perfect 2x scaling you really want a 24" 4k monitor. All these larger 27" and 32" 4k monitors are just awkward for scaling, unless you plan is to sit really far back from them.

If you want an actual 27" monitor, you need 5k. Those monitors are really expensive but starting to come down.

Re:

[MeNeXT]

All these larger 27" and 32" 4k monitors are just awkward for scaling, unless you plan is to sit really far back from them.

If you want an actual 27" monitor, you need 5k. Those monitors are really expensive but starting to come down.

My 28" 4K monitor with a gnome scaling factor of 2 and xrandr scale factor of 1.5x1.5 or 1.6x1.6 gives identical results as my iMac 5K setup. Since Gnome factors all screens the same you need to scale regular displays at 2x2 in xrandr for dual monitor support. Again my dual monitor Fedora setup looks identical to my iMac dual monitor setup.

It is very workable as a desktop. Some applications may need fine tuning. On Fedora 25 I've had a very satisfying experience so far. I've been running it for at least 2 w

Is resolution independance a distant dream?

[caseih]

Is a display system that is resolution independent still a distant dream? Seems like this HiDPI stuff is just a hack, though I'll agree it's not the worst hack I've ever seen.

Years ago we thought eventually we'd have desktop where everything was displayed in actual units like centimetres or points, and since everything was to be scalable, you could zoom it anyway you want and it would remain nice and sharp. Although we have scalable fonts that HiDPI relies on, seems like we gave up on vector graphics for drawing with (too slow?), and now we just bitmap scale the whole GUI (except the fonts). Is there no better way?

GNOME had this

[Zan Lynx]

They had this in 2005. It was called DPI. It scaled really well. Then some IDIOTS decided it should be force set to 92.

Re:GNOME had this

[jbernardo]

This was broken on purpose on gtk+ by a gnome developer called Matthias Clasen.

You can see a description of this in this reddit discussion, and the bug and the amazing answers by Mr. Clasen are here.

It did not only break gnome support of HiDPI, but also broke any app using gtk+, like Firefox or libreoffice..

Re:GNOME had this

[jbernardo]

Doh, it seems that the URLs didn't survive the submit, so here they are again:

- reddit comments on gtk+ breaking HiDPI - https://www.reddit.com/r/linux/comments/6cf1dq/what_was_the_most_baffling_problem_in_linux_youve/dhuhuk4/ [reddit.com]

-bugzilla report - https://bugzilla.gnome.org/show_bug.cgi?id=757142 [gnome.org]

Re: GNOME had this

[Lisandro]

That entire discussion is just baffling. Did anyone ever explain the rationale behind the decision to hardcode a DPI setting instead of getting it from X?

Re: GNOME had this

[jbernardo]

The only explanation is in the commit - https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f [gnome.org]

Instead of testing to see if the DPI values were non-zero, the developer just decided to force 96 DPI fully ignoring the detected values.

I won't comment on the developer's abilities, I think that commit speaks for itself

.

Re:

[Anonymous Coward]

dpi_double = 96.0;

Anyone doing that in place of code that already asks x for the correct valves is a bad actor. Magic numbers are bad. m'kay.

To "won't fix" when it's pointed out as a regression.... maybe breaking x support ahead of a shift to wayland?

Re:

[bill_mcgonigle]

To "won't fix" when it's pointed out as a regression.... maybe breaking x support ahead of a shift to wayland?

Oh, well that's a much better accusation of nefarious motivation than being paid off by Microsoft.

Re:

[AmiMoJo]

Did anyone ever explain the rationale behind the decision to hardcode a DPI setting instead of getting it from X?

Or why the submitted patch to undo the regression wasn't accepted.

Re:

[amorsen]

The "force 96" code looks like it only activates if X doesn't know the DPI. This seems like a quite sensible proposal: If X doesn't know the DPI, then fix X.

Re:

[tepples]

This seems like a quite sensible proposal: If X doesn't know the DPI, then fix X.

With the implication being that if the chipset makers obstruct X from knowing the DPI, fix the chipset makers. Good luck with that.

Re:

[amorsen]

If the Gnome code can calculate the DPI from the screen dimensions and the resolution, then so can X. Put the workaround where it belongs, in the X code where it only needs to be maintained once, rather than in each toolkit.

What is the DPI of a projector?

[tepples]

True, the actual density depends on the screen dimensions and pixel count. But an uncooperative chipset maker can hide the screen dimensions from X.

In addition, effective density depends on the viewing distance. If the monitor is twice as far away, it takes twice as many pixels in each direction to make the same size image on the viewer's retina, giving it twice the effective density. This is why CSS defines the px unit as 1/2688 of the viewing distance, which represents a 96 dpi display at 28 inches, round

Re:

[amorsen]

Yes, plain-old-DPI is a fairly useless metric. But the whole premise is that Gnome should do magic when DPI isn't set in the X-server, invoking incantations until the right DPI suddenly appears in the wisps of smoke. Consensus on Slashdot is that the Gnome team are a bunch of ridiculous bastards for not being willing to do that.

Whereas that seems like the entirely correct solution to me -- if there has to be magic spells involved, put them in the X server, not in each toolkit. And if the magic incantations

Banging one's head repeatedly should be painful.

[sombragris]

Banging one's head repeatedly against the wall should be painful. And yet Canonical insists on doing it. When the decision was made to abandon Unity, they chose the inferior solution among the GNU/Linux desktops. Plasma 5 (KDE) is HiDPI-ready. But no, they stubbornly chose GNOME and now they have to throw resources and manpower to hack at the GNOME codebase to fix something that was already fixed in Plasma.

They should have gone with Plasma which is IMHO much better.

OK, I get that it's their project and thei