search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
541 stars 48 forks source link

Improve support for high resolution displays #1951

Open marmarek opened 8 years ago

marmarek commented 8 years ago

For having full HiDPI support in Qubes, we need:

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 commented 8 years ago

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 commented 8 years ago

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

marmarek commented 8 years ago

Status update for Qubes 3.2:

andrewdavidwong commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

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 commented 8 years ago

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 commented 7 years ago

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

najamelan commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.

ghost commented 6 years ago

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

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 commented 6 years ago

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 commented 6 years ago

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.

ghost commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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.

... 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 commented 5 years ago

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 commented 5 years ago

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

  1. 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 qubes-users@googlegroups.com mailing list.

/Sven

ahimta commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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"

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago
  • [ ] 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 https://github.com/QubesOS/qubes-issues/issues/1951#issuecomment-1243371806, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABUQBYGESHO4JN5PEF4ENLV53Q2HANCNFSM4CC6EHJQ. You are receiving this because you commented.Message ID: @.***>

0spinboson commented 2 years ago

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

jamke commented 2 years ago

Probably related to this issue: #7881.

lorenzog commented 9 months ago

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 commented 9 months ago

@marmarek: is this an Xorg limitation?

0spinboson commented 9 months ago

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 commented 9 months ago

@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 commented 9 months ago

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