I'd like to give a fresh description of this bug. I think I can do so more concisely, as it affects gnome-shell. I was in two minds about whether to report it as a new bug, but honestly feared if I did so it would just be marked a duplicate of this one and ignored. :-)

Also to update for current versions:

gnome-shell: 3.26.0-0ubuntu1

Under Xorg only (not Wayland), the *text* elements of gnome-shell do not reflect the scale setting chosen in Settings->Devices->Displays (set to 200% to reproduce), but instead just show the text at the size specified in gnome-shell.css as if the scale was set to 100%.

The non-text elements of the gnome-shell UI are scaled correctly for the chosen scale factor, so the size of icons and other elements, and the placement of them, across the full screen is correct. Only the text size is wrong.

Workaround 1: Using gsettings org.gnome.desktop.interface text-scaling-factor to match the selected desktop scale, eg: setting it to 2.00, corrects the error in gnome-shell, it then looks fine. But this is useless as a workaround as it also scales up all text on the desktop that was already scaled correctly.

Workaround 2: If the shell theme in use has a gnome-shell.css file, edit it to set the stage font-size to double its original. eg: for Arc theme, as I use, change it from 9pt to 18pt. Obviously you need to change this whenever you change your desktop scale setting and force the theme to be reloaded.

Note: This bug affects the default shell theme too, but as far as I can see, that doesn't have a comparable gnome-shell.css file to fix, so I don't know how to work around it with that. (I expect it is possible, I just don't know where.)

Requested fix: in Xorg (it already works in Wayland), font size should be multiplied by desktop scaling factor. This is a regression because it used to work when desktop scaling was controlled by gsettings org.gnome.desktop.interface scaling-factor. I think especially seeing as fractional scaling didn't make it into gnome 3.26, except in experimental (and somewhat broken, I did try it) form, it's not unreasonable to expect non-fractional scaling factors to continue to work as they did in 3.24, even if controlled from a different setting. :-)

Slightly wider note on HiDPI:

Forcing wayland on my nvidia system seemed to work for a while, but actually became more unstable over time as more updates came in, until as of writing, both nouveau and nvidia proprietary drivers fail catastrophically under kernel 4.13, apparently crashing in the DRM supporting code, making the system completely unusable. (I had to ssh in to recover.)

Well, kms isn't supported under nvidia yet, so I was asking for trouble trying to force it to work, so this isn't a bug report about that. We know it's broken. Hence me going back to trying to use Xorg. On my non-nVidia machine I'm happy with Wayland, but I'm sure I'm not the only nvidia user out there with a HiDPI monitor who's about to see their systems become completely unusable under Linux. That's a lot of users who, right now, can't step up to Wayland, and there's probably more that have other rational reasons for needing to stick with Xorg right now.

And the vexing thing is, it's so *close* to working pretty well under Xorg. I've needed to do just three workarounds to get the system back to being completely usable, even with two monitors of different sizes.

The first is the one described above, to fix gnome-shell's text size.

The second is to explicitly set gsettings org.gnome.desktop.interface scaling-factor to 2 as well, as some apps, including some gnome apps like Nautilus, are still obeying that and not the new scale setting in the control center. I'm sure those apps will come around to the new setting eventually but they probably should get a separate bug report.

(And will someone *please* tell me where that new setting is? I could really do with being able to set and read it via a script. Presumably it's a gsettings value somewhere? But I can't find it.)

The third is to use Xrandr to provide something like fractional scaling in exactly the manner that macOS does it (so I really don't feel that it's slumming it, and if it's cheating, rather than "properly" doing fractional scaling, I'm happy with the cheat to have something that works *now*). This lets me, for instance, match a 27" 1440p monitor to a 27" 4K monitor both showing desktops of the same size, with scale set in displays prefs to 200%:

To get a "Looks like 1080p" on a 1440p monitor, equivalent to 133.33...% scaling:

xrandr --output DP-2 --scale-from 3840x2160 --auto --panning 3840x2160

That then pairs nicely with my 4K monitor at 200% and native resolution.

Or to get a "Looks like 1440p" on a 4K monitor, equivalent to 150% scaling:

xrandr --output DP-4 --scale-from 5120x2880 --auto --panning 5120x2880

(Actually on nvidia I can set this via the nvidia-settings app, but it's just doing xrandr as above, so it's not an nvidia-specific method.)

It would be great if this behaviour could be put behind the Displays user interface, because the underlying display system can already do it. As I said, this *is* how it works in macOS (obviously not actually using xrandr...): "Retina" modes are all 200%, but so-called fractional scaling modes are scaled down from larger desktop areas. The "Looks like 2560x1440" is, you can see if you take a screenshot, a full 5K desktop area. Their user interface even warns that it's not as optimal as the default scaling mode, but they let you do it and it works fine, and on a fast GPU you don't really notice or care it's not optimal. And xorg can do it *right now* (I'm using it this minute) using xrandr and a fixed scaling factor of 200%.