X11 hidpi scaling available for testing on Disco

Desktop
1

EDIT: This has now landed in Disco. You do not need to add the PPA anymore. You can simply set the gsettings key and restart your session.

Good evening desktopers,

Thanks to Marco, not only GNOME in Disco has non-int UI scaling for wayland [1], but now there is a beta version for X11 sessions available for testing.

$ gsettings set org.gnome.mutter experimental-features “[‘x11-randr-fractional-scaling’]”

Note: if you copy & paste that line, make sure it’s using the correct sort of quotes

Restart your session, and you should have values like 125% in gnome-control-center/display.

(Note that sometime the setting UI don’t have the ‘apply’ button enabled, one of the reason is that after changing a value the monitors get placed in a way which make them not be aligned on a common edge which is an invalid config, replacing them is enough to workaround the issue in those cases)

The next steps for Ubuntu are

Hopefully the work gets review/merged upstream next cycle and then we can enable it without experimental option.
Oh, and if you enjoy the feature all the kudos go to the awesome Marco Trevinho! :wink:

[1] https://blog.3v1n0.net/informatica/linux/gnome-shell-fractional-scaling-in-wayland-landed/

9 Likes
2

I’ve tried. It works for me but there seems still some room for improvement.

1, Some QT APP still looks so tiny. (Like VLC)
2, screen tearing when dragging windows.

1 Like
3

Unfortunately those seem to be a consequence of using Xrandr transforms. It’s not a problem with the great high DPI work Marco’s done all over mutter for Wayland, but it is a problem with using Xrandr. You can see exactly the same two problems on any X desktop without using the PPA. For example on my machine the monitor is known as DP-2 so I can run this in a Xorg session:

xrandr --output DP-2 --scale 1.25x1.25

and it has the same problems of windows shrinking and the screen tearing.

In theory you can work around those by:

  1. Modifying all common toolkits/apps to honour fractional scaling at the right time; and
  2. Modifying Xorg and/or common graphics drivers, or maybe even mutter, to do an explicit wait for vblank when scaling (like with glXWaitVideoSyncSGI or glXWaitForMscOML).

However even if such workarounds existed it would probably still be a bad idea for performance to use Xrandr, because:

  • 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.
  • Xrandr scaling yields subpixel rendering, which makes rendering fractional scales a little blurry compared to integer scales.
  • If you did modify Xorg or mutter to do an explicit wait for vblank with fractional scaling then there’s a chance that could lead to another frame higher latency than we already have (which is already too high).
  • If you did modify mutter to do an explicit wait for vblank then that’s still not going to be perfect. We did that in Compiz up until 2012 and it did still tear a little near the top of the screen. To absolutely avoid tearing you need the final kernel page flip synchronized to the monitor’s vblank (frequency and phase). If Xrandr is abstracting that last step to support fractional scaling then we can’t control it properly in mutter, it would need to be done in Xorg and/or Xorg graphics drivers.

I am loving Marco’s high DPI work in Wayland sessions :heart: but think using Xrandr for this is a mistake.

3 Likes
4

Got it.

I am loving Wayland Fractional scaling too. But X11 APP with that will be blurry.
Actually we just don’t need to scaling the X11 app. many X11 app has better scaling option itself. Why not just leave them unscaled?

Okay I saw this:

https://gitlab.gnome.org/GNOME/mutter/issues/478

And Knew that Marco is working on it. Hope we can get this feature in next circle.

Lacking fractional scaling is the main reason I still using Ubuntu 18.04 with Unity 7.

5

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 = …

6

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
7

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!

8

@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
9

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
10

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.

11

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
12

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.

13

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.

14

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?

15

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).

16

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.

18

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
19

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.

20

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.