Improve support for high resolution displays

[marmarek]

For having full HiDPI support in Qubes, we need:

• [x] have dom0 desktop environment support - upgrade dom0 to Fedora 23 should do (#1807)
• [x] have VM applications/toolkits support - Fedora 23 probably is good enough
• [ ] Fix very low AppVM refresh rate on high resolution monitor setups (#3175)
• [ ] somehow inform the VM about the DPI
• [ ] possibly improve GUI performance

The last one may be really hard, if turn out to be a problem - because VM have no hardware graphics acceleration, so all that is computed on CPU.

[marmarek]

Regarding informing VM about DPI, the most straightforward (I think) solution would be to pass physical screen size along with its resolution (qubes.SetMonitorLayout qrexec service). But this may pose a big privacy issue, especially for Whonix VMs. One solution would be to disable this feature for Whonix VMs, but that means no HiDPI support for Whonix. Another idea is to pass some different information - for example some approximate DPI value - like one of 96, 150, 300 and so on.

@adrelanos what would be the best option? Maybe something different?

[marmarek]

Related message about informing DPI to the VMs: https://groups.google.com/d/msgid/qubes-devel/56E49569.9020506%40noses.com

[marmarek]

Status update for Qubes 3.2:

• installer handle HiDPI nicely - enable scaling automatically so it's readable
• KDE5 (dom0) doesn't automatically enable it, but it's a matter of one setting: Increase font dpi (System Settings → Font → Force font dpi, enter a number such as 125, 144 or 150 etc); and if you like, increase icon sizes
• VM - no progress yet. Probably require minor modification of dummyqbs xorg driver (expose an interface to set dPtr->paOutputs[i]->mm_width (and mm_height).

[andrewdavidwong]

On 2016-07-04 14:05, R.B. wrote:

Hello,

For the people who want to use a HIDPI display, or have one on their laptop, Here's an easy way to get your vm's up to scale while issue #1951 is open ;-)

Settings that I use on my machine with 3.2rc1: gsettings set org.gnome.desktop.interface scaling-factor 2 gsettings set org.gnome.desktop.interface text-scaling-factor 0.75

You could run it through qvm-run from dom0 for all your vm's.

Note that for some reason it won't affect templates. The (gnome-)terminal for instance remains the same size and scale.

For reference: https://github.com/QubesOS/qubes-issues/issues/1951

Enjoy.

Regards,

RB

Original message

[brinded]

Awesome! I will readily volunteer my time on any tests regarding HiDPI as I love Qubes and have a 4k laptop (Y50-70). Of note, xrandr pulls up the correct info in regards to resolution (3840x2160) and display size of 344mm x 194mm. However, xdpyinfo returns the same resolution and a display size of 1016mm x 571mm yielding 96dpi. I'm plugging my way through it.

That being said, Fedora 24 with GNome handled it extremely well.

[marmarek]

I've added support for custom screen/output size to video driver. It can be even changed on the fly :) When manually set to HiDPI-suggesting values (DPI > 200), gnome-terminal (and probably other GTK+ applications) in Fedora 23 VM automatically turns on font scaling. According to gnome-settings-daemon sources, it is triggered on:

• DPI >= 192
• height >= 1200px

Those properties expect screen size in mm.

The easiest thing to do would be to pass actual screen size from dom0 directly. But (I guess) this would be major problem for Whonix VMs as physical screen size is even more unique than just resolution. @adrelanos what do you think? I've already proposed some solution in https://github.com/QubesOS/qubes-issues/issues/1951#issuecomment-216999709 - is it ok?

[adrelanos]

I am not sure yet. Does this require a quick answer?

Another idea is to pass some different information - for example some approximate DPI value - like one of 96, 150, 300 and so on.

This sounds best. The more common the value is, the better.

[andrewdavidwong]

I've marked the first two items as complete since we have F23 in dom0 and an F24 template now.

[najamelan]

This message of the user mailing list might be of interest. I can confirm it works on Q4RC3. After rebooting the template, it's dpi is correct, and it is also propagated to all app vms:

The only way I found to get a reasonable view is to change the default 96 dpi setting of Xft.dpi in /etc/X11/Xresources (in the TemplateVM).

For the whonix-ws template it works when adding it to /etc/X11/Xresources/x11-common

[mossy-nw]

setting Xft.dpi to >96 isn't working for me in R4.0_rc4 for debian-9 or fedora-26 templates (whonix not tested).

However, in VMs with fedora-26 templates this solution from R3.2 is working again (running commands in the VM terminal on launch):

gsettings set org.gnome.desktop.interface scaling-factor 2
gsettings set org.gnome.desktop.interface text-scaling-factor 0.75

This fails (with no apparent effect) in VMs with debian-9 templates, with the following error:

dconf-WARNING **: unable to open file '/etc/dconf/db/local': Failed to open file '/etc/dconf/db/local': open() failed: No such file or directory; expect degraded performance

[mossy-nw]

in R4.0_rc4, for at least one (electron-based) app using a debian-9 template, running the following command in a terminal before launching the app did the trick:

echo Xft.dpi: 144 | xrdb -merge

This also works for torbrowser in a whonix-ws based VM.

[taradiddles]

just found out that setting DPI scaling depends on the presence of the /usr/libexec/gsd-xsettings daemon (provided by the gnome-settings-daemon package in fedora):

• without /usr/libexec/gsd-xsettings running, applications honor Xft.dpi
• with /usr/libexec/gsd-xsettings running, applications are prevented from using Xft.dpi so the gsettings commands have to used.

I've documented this in https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md ; if it gets enough testing (eg. for kde/qt apps) I can submit a PR to the official docs.

[ncm]

For the "expect degraded performance" problem, I created # ln -s /home/user/.config/dconf/user /etc/dconf/db/local in my debian-9 template. The complaint went away. Dunno about the "degraded performance".

[gdamdam]

I found easier change the display resolution. Unfortunately on Qubes 4 the display choices are incomplete, and some popular one are missing.

To add 1600x900 60Hz you can run on dom0:

xrandr --newmode $(gtf 1600 900 60 | grep Modeline | sed s/Modeline\ // | tr -d '"')
xrandr --addmode "eDP-1" "1600x900_60.00"
xrandr --output "eDP-1" "1600x900_60.00"

The option to change the DPI as described at https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md works for the fedora but not for debian and whonix.

[taradiddles]

The option to change the DPI as described at https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md works for the fedora but not for debian and whonix

The doc isn't distro specific - it really boils down to whether gnome settings daemon is installed or not. If you have time, please open an issue over at qubes-community with your findings so that we can update the doc. I've read somewhere about whonix "anonymizing" resolution, that could be the reason for the instructions not working on that distribution.

I found easier change the display resolution

Save for multiples of 2 of your real screen resolution, don't you get blurry fonts ?

[adrelanos]

Ivan:

I've read somewhere about whonix "anonymizing" resolution, ...

Deprecated. Not used in Qubes-Whonix ever, I think but not used in Whonix 14 for sure.

[alinazzal]

@andrewdavidwong The thing is, when changing the resolution the screen ends up flattening down from top and bottom. It doesn’t end up taking the full length up and down of my screen. Not only that, but it doesn’t retain the screen resolution on restart/shutdown.

[ahimta]

I'm using Qubes OS 4.0.1 on a laptop with a 4K/UHD display. On Ubuntu I can have the resolution to 3840x2160 (which is 2(1920x1080)) with 200% zoom.

I would like to do the same in Qubes but the Display in XFCE preferences doesn't seem to have zoom/scale option and I'm forced to use 1920x1080 with a 100% zoom which is inferior to the 3840x2160 with 200% zoom:sweat_smile:.

I searched on how this can be done in XFCE or using xrandr but I couldn't find a working solution in a reasonable amount of time:sweat_smile:.

Is the zoom option related to Qubes OS, XFCE, or am I just asking the wrong question:sweat_smile:?

[SvenSemmler]

On 7/27/19 11:59 AM, Abdullah Alansari wrote:

Is the zoom option related to Qubes OS, XFCE, or am I just asking the wrong question😅?

I don't think this is in any way specific to Qubes beside the fact that you need to change things in Dom0 AND the templates.

• set resolution in Dom0 using xrandr to 3840x2160
• use gnome-tweak-tool (gnome-tweaks in newer templates) to set scale in Dom0 and the templates

... that worked for me when I was using R3.2 on a MBP several years back. However I don't like HiDPI on Linux ... because it'll take you hours to have every corner case working and it'll never look right anyway. That's the main reason I went for a standard resolution display with my new ThinkPad.

/Sven

[ahimta]

Thanks @SvenSemmler:smiley:. Now I understand better the scope of Qubes OS relating to this issue and that the first step I want to do (using 3840x2160 with 200% zoom) is more of a usability issue with XFCE where the zoom is not in the Display settings UI:sweat_smile:.

As a next step

1. I will create an XFCE issue for missing the zoom in Display preferences if an issue doesn't already exist.
2. I will try to figure out how to use xrandr to add a 3840x2160 with 200% zoom. I did some research before but I couldn't find any fast solutions and will need to understand xrandr more to do what I need.
3. After getting the 3840x2160 with 200% zoom working on Dom0, I will start to get the Qubes OS specific stuff working (e.g: fonts DPI, zoom/DPI in VMs, etc...).

On the Linux HiDPi front, I used the 3840x2160 with 200% zoom with Ubuntu for a couple of years (18.04 LTS last) and it's flawless. You get an 1920x1080 space in the screen but much crisper (including fonts).

The only things that had some issues were the MySQL workbench ~5.0 (but still very usable and the new ~8.0 may not have this issue) and the VMs in Virtualbox and changing the zoom in the VM may fix this:smiley:.

[SvenSemmler]

On 8/6/19 9:46 AM, Abdullah Alansari wrote:

2. I will try to figure out how to use xrandr to add a 3840x2160 with 200% zoom. I did some research before but I couldn't find any fast solutions and will need to understand xrandr more to do what I need.

xrandr knows nothing about "200% zoom" it only deals in resolution (e.g. 3840x2160)

Your "200% zoom" is implemented by GTK/Gnome and Qt. The easiest way to get there is to use gnome-tweaks and qt5ct.

Also: this is an issue tracker for Qubes and since you understand now that it's actually not an issue with Qubes it would be kind if you'd close the issue and move further discussion over to the [email protected] mailing list.

/Sven

[ahimta]

I just tried gnome-tweaks and the closest thing I found was Fonts -> Scaling Factor but it only works for the font/text:sweat_smile:.

In Ubuntu, when I set the resolution to 3840x2160 with a 200% zoom, the UI and screen space looks exactly like in 1920x1080 with a 100% but everything is much clearer (icons, fonts). I think GNOME page define it appropriately as "Hi-dpi support means that applications render at half the available screen resolution to avoid content that is defined in terms of pixels from becoming tiny. Effectively, this means treating 2x2 blocks of device pixels as a 1x1 logical pixel, with the extra twist that data that is available in high resolution (e.g. svgs or fonts) can be rendered at the full resolution. "

For fedora-29 based-AppVMs gsettings set org.gnome.settings-daemon.plugins.xsettings overrides "[{'Gdk/WindowScalingFactor', <2>}]" seems to work (even Firefox). This is from the GNOME HiDPI URL referenced in https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md

But I still can't get HiDPI to work on Dom0.

1. Using Xfce: Qubes Menu → System Tools → Appearance → Fonts tab: Custom DPI setting: only affects the font.
2. Using echo Xft.dpi: 144 | xrdb -merge seems to be the exact same thing just in the CLI instead.
3. All gsettings sets don't seem to change anything.

I have read all the comments of this issue again to see how this is done on Dom0 and it boils down to the following:

1. https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md (only fonts actually seem to work).
2. The DPI >= 192 and resolution >= 1200. I will try setting the resolution to 3840x2160 and font DPI to 192 and restart and see what happens:sweat_smile:.

I just need 3840x2160 with a 200% zoom even if I have to set it on each AppVM start (it will probably not come to that). This is very important to me and I see it as an investment especially when programming:smiley:.

And to be honest, the difference between 1920x1080 and 3840x2160 with a 200% zoom is more than the difference between 1280x720 (HD) and 1920x1080 (FHD); and bigger than the difference between SD and HD too:yum:.

[0spinboson]

It's not directly related to HiDPI, but it is to UI performance on 4k monitors (which seems to me the underlying consideration), so could I propose renaming this issue slightly and adding this to the task list for this issue? https://github.com/QubesOS/qubes-issues/issues/3175

[andrewdavidwong]

It's not directly related to HiDPI, but it is to UI performance on 4k monitors (which seems to me the underlying consideration), so could I propose renaming this issue slightly and adding this to the task list for this issue? #3175

Done.

[wjbrob]

It is hypothetically possible to scale with workarounds in Xterm for Fedora DVMs, - via fonts or dpi, - but a hassle. I haven't figured out yet how to install such fonts in Xterm on Qubes.

The Fast way for scaling with fedora DVMs I use. When opening a browser - first open xterm, open gnome-terminal, then run the working code below to enable 2x scaling. Then open your browser of choice.... Is this the way others on 4.0 operate scaling with the Fedora template on high res screens for DVMs?

gsettings set org.gnome.settings-daemon.plugins.xsettings overrides "[{'Gdk/WindowScalingFactor', <2>}]"

Is there any other default OS with DVMs users utilise scaling with? For Fedora, because of the hassle: Could there be a solution that skips writing these lines in each time for users with high-res displays if this works for others? Gnome only supports scaling of integers, and xterm doesn't support any factoral scaling (only text-based) so I can't see how there might be improvement to the end result, even if others are unhappy with the 2x scaling look! (I am satisfied with it on my 4k monitors, would like it as a global setting if possible).

I realise this universal option (below) to rescale a large dpi screen down to 1600x900 in Dom0 has worked in the past (latest 2018?) but I can't get it to work for me now. If senior devs can get it to work (?), it may be a default option to put into qubes global settings, like other distros & windows facilitate. Especially because the gtf function w/modeline brings the frame rate back up to 60 - Qubes dom0 defaults to 24hz (which is also unclear, long thread #3175)

xrandr --newmode $(gtf 1600 900 60 | grep Modeline | sed s/Modeline\ // | tr -d '"') xrandr --addmode "eDP-1" "1600x900_60.00" xrandr --output "eDP-1" "1600x900_60.00"

• https://www.reddit.com/r/Qubes/comments/8c830e/qubes_40_scaling_issues_on_hidpi_laptops/

Also scrolling to the bottom of this issue discussion Modeline is also the only existing fix/workaround for rescaling the XFCE and DOM0 in 4.0? https://github.com/QubesOS/qubes-issues/issues/3175

-Will

[marmarek]

You can apply the gsettings in fedora-...-dvm VM, which is a base for new DisposableVMs. That should help for applications using this setting, but not xterm. Since gnome-terminal is problematic in DisposableVM, you may want to install and use xfce4-terminal there - it is more advanced than xterm (especially should handle scaling) and does work in DisposableVM.

[gasull]

in R4.0_rc4, for at least one (electron-based) app using a debian-9 template, running the following command in a terminal before launching the app did the trick:

echo Xft.dpi: 144 | xrdb -merge

Is there any way to have this in the template, so it's executed automatically in al VMs?

I tried /etc/rc.local, /etc/bash.bashrc, /etc/xprofile, etc.

[taradiddles]

Is there any way to have this in the template, so it's executed automatically in al VMs?

~~Try with a .desktop file in /etc/xdg/autostart/ - that's how I launch most custom stuff in templates. (I'm not sure pipes in the exec line would work though - if so put an executable shell script with the echo... command somewhre and exec it in the .desktop file).~~

Edit- put your executable shell script in /etc/X11/xinit/xinitrc.d/. The approach above was my "old" way of doing things but sometimes the scripts would take a bit of time to start and apps wouldn't pick the X resources; stuff started by xinit is always started before any user apps.

A systemd service (user session) should probably work too ; testing/migrating from xdg stuff is on my TODO list for a bit of time.

Edit- you could also put Xft.dpi: 144 in a Xresources file and run xrdb -merge /path/to/Xresources in a shell script; that's what I do for my [u]xterm/X stuff (eg. solarized colors, fonts, ...). Note: for some reason simply putting your resources in /etc/X11/Xresources doesn't work.

I tried /etc/rc.local, /etc/bash.bashrc, /etc/xprofile, etc.

rc.local won't work because X isn't started yet when the script is evaluated; bashrc and the likes don't work because they're evaluated when you start a terminal/shell, not an app.

[DemiMarie]

• [ ] possibly improve GUI performance

The last one may be really hard, if turn out to be a problem - because VM have no hardware graphics acceleration, so all that is computed on CPU.

There are two approaches to this I can think of:

1. Use SR-IOV capable graphics hardware, such as Intel Alder Lake. This is the best approach, but will only support a small variety of hardware. It also will only be able to provide acceleration to a limited number of VMs, and currently relies on out-of-tree Linux patches.
2. Once the GUI daemon switches to Wayland, it might be possible for qubes to offload compositing (though not rendering) to the GUI qube’s Wayland compositor. I say “might” because this is heavily dependent on how the new GUI protocol winds up being implemented.

[gasull]

put your executable shell script in /etc/X11/xinit/xinitrc.d/

This didn't work.

you could also put Xft.dpi: 144 in a Xresources file and run xrdb -merge /path/to/Xresources in a shell script; that's what I do for my [u]xterm/X stuff (eg. solarized colors, fonts, ...). Note: for some reason simply putting your resources in /etc/X11/Xresources doesn't work.

This did work. What I did, more exactly, is this:

$ cat /etc/X11/Xresources/dpi 
# Configure DPI.
# From 
# https://github.com/QubesOS/qubes-issues/issues/1951#issuecomment-364009076
Xft.dpi: 144

$ cat /etc/X11/xinit/xinitrc.d/dpi.sh 
# From
# https://github.com/QubesOS/qubes-issues/issues/1951#issuecomment-1221527770
xrdb -merge /etc/X11/Xresources/dpi