X11 hidpi scaling available for testing on Disco

Certainly if there are other reasons why you need to stay on Xorg, and why you need fractional scaling, then the above PPA is a good option.

I just feel that it’s only ever going to be functionally correct and performantly acceptable in Wayland sessions. That’s because all the reasons for people not using Wayland are more likely to be fixed before we could (or would) fix Xorg and all the Xorg drivers to suit our needs here.

There’s a third option too, which you can use in Xorg sessions right now without any PPA or code changes. Say you want a scale of 1.25, then you can do that as scale 200% + Xrandr scaling:

  1. In Settings, choose display scale 100%. Apply.
  2. Open a terminal and Xrandr scale the output (DP-2 in my case):
    xrandr --output DP-2 --scale 1.6x1.6
  3. In Settings, choose display scale 200%. Apply.

Unfortunately that sequence of events it’s remembered on logout. But it does at least show what’s possible and achieves visually the same result as using the PPA, also with similar performance and image quality problems.

Also, you don’t need to stay on Unity. A fourth option is that you can use Unity-style scaling in Gnome Shell already:
Gnome Tweaks > Fonts > Scaling Factor = …

I don’t want to sound negative. I do :heart: the fractional scaling work that Marco’s landed so far. And he asked for my feedback on this topic today, so here it is.

We could release the work in the PPA to Ubuntu in theory without any regressions to any current features. We would lose nothing since features are only being added (with the usual risk factors). If we were to do so however, then I think it would be worth documenting what the image quality and performance implications might be for fractional scaling in Xorg sessions.

1 Like

The only reason I must use unity 7 is it’s ONLY DE can handle mutimonitor fractional scaling.

I know it’s not perfect and It’s just tweaking font scaling factor and some Compiz scaling BUT at least it’s tolerable.

My laptop has a WQHD Display, 1X scaling too small, 2X scaling too large but 1.5x is okay.

I’m using my laptop at work with 1.5x scaling on buildin display . But when I back home, I plugin my laptop with dual 1080P monitors and close the lid. so 1X scaling is okay for this time.

I know I can change gnome font Scaling Factor to 1.5 and change title font a bit larger to make everything readale on my WQHD but It won’t change automatically when I docking my laptop to 1080P monitor.

Unity 7 can handle this quite well, It can change scaling automatically when I changed monitor. Actually I dont’t need something like “MIxed DPI with mutimonitor”, I only want it to change font Scaling Factor and gnome shell title bar size overall with my docking or undocking.

Wayland with fractional scaling seems work very well for me, but lagging of mouse movement and blurry of X11 app keep me away.

Whatever, Great works for your guys, respect!

@plumerlis,

Wayland with fractional scaling seems work very well for me, but lagging of mouse movement and blurry of X11 app keep me away.

We likely have a fix on the way for laggy mouse movement. But we would need you to log a bug about it to help identify which bug it is you are experiencing.

As for blurry X11 legacy apps, that I think is more of a feature and not a bug. The only alternatives for such apps that don’t support scaling themselves is to not stretch them at all or more generally to pick the nearest integer scale. It sounds like that should be an option to give people…

1 Like

I edited the description/steps, I had copied the wrong gsettings command, you can reset if with

  • gsettings reset org.gnome.mutter.x11 fractional-scale-mode

Thanks @seb128 for your post, now some considerations.

So here the (default) approach is was more or less something that is done by some tooling, and in general was very common between users, it’s just that we wanted to integrate this properly in the desktop to make it usable without deeper knowledge, and integrating it in GNOME.

The idea is

  • Scale all the UI elements UP to the maximum scale level and the whole view down to reach the wanted scaling value

So what we do is:

  • For each monitor, we compute the best scaling value (below an example with 4 monitors)
    [ 1.25 ] [ 1.75 ] [ 1.0 ] [ 2.0 ]
  • We take the maximum scaling value, and we ceil it, then we make sure X11 informs the toolkits to scale up to this maximum level.
    [ toolkit UI scaling set to 2 ]
  • We scale each output so that toolkit_scaling * xrandr_scaling == monitor_scaling
    Actual xrandr scaling values for such setup:
    [ 0.625 ] [ 0.875 ] [ 0.5 ] [ 1.0 ]

I had some discussion about this at latest GUADEC, since X11 still is something we all care about, and there was interest on having this feature by us, system76 but not only. So I started playing around.

Now, I was completely aware of the performance constrains and while indeed as @vanvugt said this has some technical problems, due to X11 limitations, since we can’t do (and all the other past attempts failed) input redirection in X11 (and so reuse what I’ve been contributing to have under wayland with scaled framebuffers).
However, although the limitations (that indeed are more present whith multiple monitors), I was quite surprised to see how this leads to a well usable session,

That said, this is the best we can do, with the current technologies, in order to have some good quality fractional scaling under X11 setups and with multi-monitor support.

Now, tearing thing… I’ve been experiencing it only recently while it seems @azzar1 has not in all the setups. So, this might be also something drivers could improve.
And I think pushing this in a more visible situation, could make driver authors to improve fixing this, if we can’t do anything more ourselves (and I would appreciate if @vanvugt could see if we can do anything mutter-side to improve it).

This looks like a bug in the app which doesn’t honor the integer scaling set as X11 dpi value, so this should be really fixed by them.


@plumerlis as per the wayland scaling considerations, more of the things are known and planned for later work, but please let’s keep the discussion out from this topic, since we focus on X11 only here.

Status update on tearing:

  • Found it is caused by using Xrandr because no compositor can (yet) flip an image to the kernel that’s a different resolution from the monitor.
  • Found that the present extension is already asking the modesetting driver to sync to vblank. Just that the modesetting driver’s preferred vsync method is inaccurate in Xrandr scaled configurations. It’s the right vsync frequency but out of phase after the time glamor takes to render to the scaled-down buffer using single buffering. Hence tearing. So the root cause of the problem is that it’s using single buffered scanouts when scaling. It should be double buffered.
  • Also found that the i915 kernel driver doesn’t yet adequately support the KMS DRM “scaling mode” property, which would allow us to move scaling into the kernel and avoid having to do it manually with GL and would avoid tearing.
  • Tested the big branch upstream which adds the TearFree option. Unfortunately it’s incomplete and enabling TearFree also breaks scaling. Plus it increases latency even when unscaled.
1 Like

In testing I found that with scaling enabled the half-screen tiling doesnt work any more.
I can understand why this might be, but just wanted to put it out there.
Not a release blocker IMO.

Edit: I found that this is only the case where I have two screens enabled. With a single screen, scaled to 125%, window snapping works again.

Also touchscreens are messed up. Touching the laptop screen shows the touch events being sent to the external screen. e.g. touch and drag shows the rubber band selector on the external screen.

Edit: seems like this is a general disco problem.

Hi Will, just curious as to how a person could confirm this? I’m running a touch screen without an external monitor, but everything seems to work. Or is this only an issue when having an external monitor hooked up?

Hi there, just a little feedback. I’m currently running this with Ubuntu Budgie. Overall the functionality seems to be quite good. I haven’t noticed anything blurry, Etc. However the one thing I’m running into, is that my window manager is consuming a good portion of my CPU and kicking my fans in quite a bit. I literally just finished reloading my machine, so I’m going to see if I can reproduce again. I’m just trying to narrow down if it is an actual bug, or just my specific system. The part I’m hoping, as it’s not specific to only Ubuntu Budgie.

Thank you in advance for your time.

PS - without enabling gsettings, the machine operates as per normal. (So far).

The increased CPU/GPU usage is expected, which is what I was trying to describe in my first comment near the top…

  • GPU memory usage is higher due to virtual framebuffers being larger than the physical screen resolution.
  • GPU fill rate will be lower if Xorg or the driver has to recomposite every frame. This hurts general performance and power usage.

but also

  • the GPU has to draw (and copy) a lot more pixels per frame using Xrandr scaling.

If you can’t afford the extra CPU/GPU/power usage then you should try using Wayland sessions instead (where I think fractional scaling is more efficient), or just avoid fractional scaling for now.

Hello,

Windows gamers have been using something called “Super Resolution”. Can we use it to have HiDPI?

I would like to tell the graphics driver to present my display as 1.5 its resolution, and then use a x2 scaling. The GPU should be able to handle the downscaling as it do for games in windows. I know it may differ from GPU vendors, but it could be a work around.

1 Like

This is something that is done for wayland (read details here), but in X11 this can’be te done because of missing input redirection.

We use something like this also in X11 but taking advantage of the glamour X11 driver.

I really would like to directly go to wayland, but unfortunatelly I can’t. I use my computers for work and there are some applications with known issues on wayland, like Xilinx Vivado for example.

I am still using Ubuntu 16.04, because HiDPI works quite well with unity and compiz. It is the only good think about compiz, it the most unstable environment I have ever used. After 2 hours of work the GUI is quite slow and compiz has memory leaks everywhere.

Is the glamour X11 solution implemented through xrandr?
I tried one time to solve the HiDPI with xrandr but it had too much tearing for a real use.

Curious how fractional scaling relates to usage of Gdk: the output of

Gdk.Display.get_default().get_primary_monitor().get_scale_factor()

is of type int, which seems not to go with fractional scaling.

First thanks to @3v1n0 for making this possible in X11.

I’m trying to move away from MacOS for Web Development to Pop!_OS but I have a multimonitor setup with an old 27" Asus PB278Q that supports natively a WQHD (2560x1440) resolution and a newer 27’’ LG 27UD58-B that supports natively a 4K resolution of 3840x2160.

I tried using Wayland with fractional scaling but as mentioned by @plumerlis Firefox, Chrome & Pycharm look blurred in the 4K monitor when I choose anything different to 100% (too small) or 200% (too big).

Then I went back to the default setting in Pop!_OS 19.04 that’s X11 and enabled fractional scaling with the switch described in this post, that worked much better with no blurring.

To match both monitors to they have a similar scaling I need to set my primary monitor (27’’ LG 27UD58-B) to 150% that combined with a text-scaling-factor=1.25 worked really well but in the second monitor although it’s not scaled I only can see something like 2/3 of the desktop the rest is black.

I’m really clueless on how to fix this and this seems to be the only configuration that can work well, Firefox, Chrome & Pycharm are looking awesomely sharp, so I would like to keep it as it is but will the second monitor showing over the whole display extension.

This is how is looks like:

This is the output of xrandr

pop-os@pop-os:~/Documents$ xrandr -q
Screen 0: minimum 320 x 200, current 8192 x 2880, maximum 8192 x 8192
DP-1 connected primary 5120x2880+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
   3840x2160     60.00*+  60.00    50.00    59.94    30.00    30.00    30.00    25.00    25.00    24.00    24.00    29.97    23.98  
   2560x1440     59.95  
   1920x1080     60.00    60.00    59.94    30.00    24.00    29.97    23.98  
   1920x1080i    60.00    59.94  
   1600x900      60.00  
   1280x1024     60.02  
   1280x800      59.91  
   1152x864      59.97  
   1280x720      60.00    60.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x480       60.00    60.00    59.94    59.94  
   640x480       60.00    59.94    59.94  
DP-2 connected 5120x2880+5120+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440     59.95*+
   1920x1080     60.00    60.00    50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00    60.00    50.00    50.00    59.94  
   1440x576      50.00    50.00  
   1024x768      75.03    70.07    60.00  
   1440x480      60.00    60.00    59.94    59.94  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00    50.00    50.00  
   720x480       60.00    60.00    59.94    59.94    59.94  
   640x480       75.00    66.67    60.00    59.94    59.94  
   720x400       70.08  
HDMI-1 disconnected (normal left inverted right x axis y axis)
1 Like

Did you manage to fix this?

The same problem started happening to me this week on ubuntu 19.04.

I created an issue for gnome: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1897