Improve support for high resolution displays

[marmarek]

For having full HiDPI support in Qubes, we need:

• have dom0 desktop environment support - upgrade dom0 to Fedora 23 should do (Fedora 22+ in dom0 #1807)
• have VM applications/toolkits support - Fedora 23 probably is good enough
• Fix very low AppVM refresh rate on high resolution monitor setups (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: #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 #1951 (comment) - 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.

[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? #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?
#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.

[ghost]

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

[0spinboson]

I'm running into a (locally) 100% reproducible issue related to high resolutions, namely that in my dual 4k display setup, after my monitors have gone to sleep once, I can no longer click inside AppVM windows shown on the second display. Prior to this, it works fine, and in dom0, I can still click everywhere. (Not using sys-gui yet, using KDE.)
I have configured the videoram to a square 3840x3840 area so I can tilt my monitor when I want to.

[ncm]

I have seen this in the past. It seems to be related to provisioning enough RAM for all the displays you might need at one time. See https://www.qubes-os.org/doc/gui-configuration/

…

On 9/12/22 04:13, Foppe wrote: I'm running into a (locally) 100% reproducible issue related to high resolutions, namely that in my dual 4k display setup, after my monitors have gone to sleep once, I can no longer click inside AppVM windows shown on the second display. Prior to this, it works fine, and in dom0, I can still click everywhere. (Not using sys-gui yet, using KDE.) I have configured the videoram to a square 3840x3840 area so I can tilt my monitor when I want to. — Reply to this email directly, view it on GitHub <#1951 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABUQBYGESHO4JN5PEF4ENLV53Q2HANCNFSM4CC6EHJQ>. You are receiving this because you commented.Message ID: ***@***.***>

[0spinboson]

nope, even changing the dimensions to double 8k had no effect

[jamke]

Probably related to this issue: #7881.

[lorenzog]

Been following this issue since my first install in Qubes 3.2, and I'm a bit frustrated that it's 2024 and I still have to restart a qube when I plug in an external display, if I want my apps to register clicks.

I understand I can manually set video ram in dom0 with the xrandr trick , but it is nevertheless painful when I'm in the middle of some complex workflow and need to save, shut down everything, restart the qube and open it all over again.

Is there no possible solution to this, short of setting the video ram to a very large value at login? Surely the virtual video driver can be informed on-the-fly that the screen size has changed..?

[DemiMarie]

@marmarek: is this an Xorg limitation?

[0spinboson]

I'm running into a new issue in Qubes 4.2 that falls into this topic, namely that once my PC (with a double 4k display connected) wakes back up with windows open in the left/primary screen, those windows are 'destroyed' and dom0 refuses to show anything from that VM until I restart it. Oddly, when a window was open on the right/second screen, that doesn't cause that issue, and having minimized the window on the left screen also decrease the chance of this issue.

[techge]

@lorenzog I don't know, what you mean. You set the videoram once and for good. Just use the highest amount you ever encountered. I am using highres and lowres screens and do not shutdown any qube when switching.

[0spinboson]

I'm running into a new issue in Qubes 4.2 that falls into this topic, namely that once my PC (with a double 4k display connected) wakes back up with windows open in the left/primary screen, those windows are 'destroyed' and dom0 refuses to show anything from that VM until I restart it. Oddly, when a window was open on the right/second screen, that doesn't cause that issue, and having minimized the window on the left screen also decrease the chance of this issue.

adding: the issue of open windows being 'destroyed' also happens to me with a single 4k display enabled, though it takes a few more display sleep/wake cycles (also the issue that I also ran into in R4.1 that after a sleep/wake cycle I could no longer click in windows on the second display until ). This suggests to me that it's an issue with memory filling up.
For reference: i have set gui-videoram-min to 132637 (tried a 4x4k total videoram size to see if that would avoid the issue, as I have 64GB ram and so don't care too much about the overhead anyway).