The state of the HiDPI display support in Qubes

[Achim Patzner]

Hi!

As I'm trying to set up a Lenovo P52 with HiDPI display (and external
nVidia GPU -- don't buy one without right now) I'm close to getting rid
of it completely and install Windows on it...

1) Xfce is not bringing in a single HiDPI theme and the window
decorations are looking extremely awful unless you find one of the
scarce themes adapted for this. It would be nice to have at least one
Theme suitable for an environment like this n the standard distribution.
At least it is xfce -- setting resolution (and some other things) in
.Xresources (or the default file in /etc) is solving the worst problems
easily.

2) The Fedora VMs delivered with Qubes right now are still fully Gnome
based, so just copying an appropriate Xresources is not sufficient
(luckily someone created an fc28-xfce template VM; could we please have
that as part of the standard distribution?) and one has to jump through
hoops to set up the template correctly.

Could whoever is doing the VM startup scripts right now (still Marek?)
consider expanding the X setup scripting to not only getting the screen
size in pixels into the virtual X server but also the correct resolution
and add a very late script that will, independently of the virtual
session manager, move a copy of the X resource db data from Dom0 into
the VM (in the current fedora template this is messed up by
gsd-xsettings which is merrily overwriting what came from Xresources via
xinitrc).

Petition: Take the developers' Lenovo laptops and replace them with
generation 6 HiDPI X1 (and to completely annoy kernel developers they
have to be using P52 or similar systems).


Achim

[ka...@transmuted.io]

I feel this situation would get better once Xfce finishes their GTK3 porting. They are at 80% right now and GTK3 supports HiDPI natively and then Qubes will need help porting their Window decoration system to the new interface if required (I haven't looked at it yet).

[Achim Patzner]

Am Donnerstag, den 01.11.2018, 11:20 -0700 schrieb ka...@transmuted.io:
> I feel this situation would get better once Xfce finishes their GTK3
> porting. They are at 80% right now and GTK3 supports HiDPI natively
> and then Qubes will need help porting their Window decoration system
> to the new interface if required (I haven't looked at it yet).

I'm still owing you an answer on this...

Trying to solve this somewhere at the level of GTK is a bit late and it
will not help applications flying lower.

I'm a dinosaur. I'm coming from a time without all that stuff where X11
(finally version 1.1! yeah!) came with The Window Manager (twm) and the
scaling was controlled by starting X with the correct settings for dpi
and position in your x11.conf.

I'm still living in that age as I'm using lots of stuff that is still
stuck in the age of Motif. My weapon of choice is the terminal and it
is coming as xterm (because you will find it everywhere) and if the X
server is configured correctly it will do miracles for you (just read
the description at
http://www.futurile.net/2016/06/14/xterm-setup-and-truetype-font-configuration/
for a good idea).

If you want this to be working well for you (including readable pop-up-
menus your X geometry has to be correct (and I don't think that gnome
is doing a better job there without that). You can of course set
parameters "by hand" in configuration files but it will not work easily
across monitors with different resolutions.


Achim

[schadensr...@gmail.com]

i am an owner of an p52s HiDPI modell and the whole scaling issues on qubes are troubling me aswell.

Maybe you got some good contributions to solve some of these scaling issues?
Edit the Xressources didnt seems to solve everything for me and also "xrandr" editing didnt quite hit it.
what kind of modifications did you do to work proper on qubes? i am tired of fiddling everytime a new window into right shape....

how do i scale the xterm terminals right for instance?

i would love to see at least proper default configuration for 4k displays and would love to contribute this to the qubes community.

maybee it does make sense to wait for the gtk3 port....but this wouldnt help me with i3wm anyway i guess. :-/

[Ivan Mitev]

The following might help to work around your issues:

https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md

Granted, having a "scale everything by a factor X" option in dom0 would
be way better but it'd be nearly impossible to implement/support if the
config has to be passed down to the VMs.

I'm wondering if it couldn't be solved at a lower level: AFAIU VM
windows are "shown" in dom0 as virtual screens - either seamless with
the help of qubes' X driver or "fullscreen" for (H)VMs with the debug
property set. Maybe there's a way for Qubes (or XEN?) to present the VM
with a virtual screen that has a lower resolution. Then Qubes/XEN would
upscale the windows' resolution. But even if that approach is feasible a
problem is that the usable scale factors are severely restricted (even
integers, or maybe only powers of 2). That could also end up being very
CPU intensive.

[Achim Patzner]

Am Donnerstag, den 29.11.2018, 09:16 +0200 schrieb Ivan Mitev:
> The following might help to work around your issues:
>
> https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md

It is solving a few of the issues but you definitely need more (like
HiDPI themes in several sizes). Or moving new Xresources into templates
(or VMs) if they change in dom0. And dealing with xsettingsd.

Especially xsettingsd -- it would be an ideal point of attack if Qubes
had a dedicated UI (or UX in techno hipster speak) team. Just give it
another database backend for its settings that was maintained in dom0
and accessible to all running VMs and you could easily change settings
in everything running on your system.

> Granted, having a "scale everything by a factor X" option in dom0
> would be way better

It is necessary unless you like using a microscope for HVMs. In a few
months we will see the first 12" mobile computers running at mobile
phone resolutions...

> but it'd be nearly impossible to implement/support if the
> config has to be passed down to the VMs.

Not at all. The currently implemented mechanisms for the virtual X
servers are not working perfectly yet but that could be changed. It
just won't solve the problem of xsettingsd messing everything up
(including Xft settings which are coming from Xresources and
.xresources) if it does not have the correct parameters in its
database. So all we have to take care of was getting the databases in
all VMs right -- or implement a central one. If one was mad enough he
could use the qubesdb which is already accessible everywhere.

> I'm wondering if it couldn't be solved at a lower level

[...]

> That could also end up being very CPU intensive.

You should let the GPU handle that; applying transformations is a
standard feature today.


Achim

[Jonathan Proulx]

Edit ~/.Xresources and add

Xft.dpi: 200

(or whatever your dpi is) then restart VM.  I've several Linux HoDPI systems and this is most general fix I've found.

Only been Qubesing for a couple days but works there on my X1.

Should be able to put this in /etc/X11/Xresources in template (where it's set to 96) but for some reason that doesn't seemnto do it for me & I've not looked for why that is yet...

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7e1f199f6cb9b469d37858c293b7e374a0bd791f.camel%40noses.com.
For more options, visit https://groups.google.com/d/optout.

[Ivan Mitev]

On 11/30/18 3:47 PM, Jonathan Proulx wrote:
> Edit ~/.Xresources and add
>
> Xft.dpi: 200
>
> (or whatever your dpi is) then restart VM. I've several Linux HoDPI
> systems and this is most general fix I've found.

Except that it won't work if gnome settings daemon is running.

>
> Only been Qubesing for a couple days but works there on my X1.
>
> Should be able to put this in /etc/X11/Xresources in template (where it's
> set to 96) but for some reason that doesn't seemnto do it for me & I've not
> looked for why that is yet...

Yes ; how to do that is described in the doc I've linked to.

Achim's main gripes are that there's no easy config and that everything
is static.

[Ivan Mitev]

On 11/30/18 11:22 AM, Achim Patzner wrote:
> Am Donnerstag, den 29.11.2018, 09:16 +0200 schrieb Ivan Mitev:
>> The following might help to work around your issues:
>>
>> https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md
>
> It is solving a few of the issues but you definitely need more (like
> HiDPI themes in several sizes). Or moving new Xresources into templates
> (or VMs) if they change in dom0. And dealing with xsettingsd.

As a side note the doc is meant to be a "workaround" guide until issue
#1951 is closed/fixed. My screen isn't HiDPI but has a resolution large
enough that I have to scale things up, however I never had a need for
such themes. A PR to the doc with a section about those could be a
welcome addition...

> Especially xsettingsd -- it would be an ideal point of attack if Qubes
> had a dedicated UI (or UX in techno hipster speak) team. Just give it
> another database backend for its settings that was maintained in dom0
> and accessible to all running VMs and you could easily change settings
> in everything running on your system.

I don't use/have xsettings on my fedora vms. Did you install it ? If
yes, what for ? Or is it maybe something that Debian uses by default ?

As to how to solve that, Qubes' policy is to keep the distribution
settings as close as possible to upstream but HiDPI is an important
issue so it could trump that rule. But if it does, the changes would
have to be minimal. AFAICT the common denominator is Xresources' Xft.dpi
so that'd mean relying on that + making sure gnome settings isn't running.
Also, any "HiDPI configuration" dom0-vm communication would likely be
implemented through QubesDB keys and/or dedicated qrexec service.

But none of the above solves the problem for OSes that don't use an X
server.

(Anecdote: I sometimes have to use a program in a windows HVM that
supports only an older version of JRE which doesn't have support for
font/dpi scaling. I literally have to be 10cm close to the screen to be
able to read something if I don't change my monitor's resolution
*globally* to a lower one (in dom0 with xrandr). I even have a keyboard
shortcut to switch between the lower resolution and the default one.)

>> Granted, having a "scale everything by a factor X" option in dom0
>> would be way better
>
> It is necessary unless you like using a microscope for HVMs. In a few
> months we will see the first 12" mobile computers running at mobile
> phone resolutions...
>
>> but it'd be nearly impossible to implement/support if the
>> config has to be passed down to the VMs.
>
> Not at all. The currently implemented mechanisms for the virtual X
> servers are not working perfectly yet but that could be changed. It
> just won't solve the problem of xsettingsd messing everything up
> (including Xft settings which are coming from Xresources and
> .xresources) if it does not have the correct parameters in its
> database. So all we have to take care of was getting the databases in
> all VMs right -- or implement a central one. If one was mad enough he
> could use the qubesdb which is already accessible everywhere.

No need to be mad to use qubesdb :)

>> I'm wondering if it couldn't be solved at a lower level
> [...]
>> That could also end up being very CPU intensive.
>
> You should let the GPU handle that; applying transformations is a
> standard feature today.

In theory yes but I'm not sure it is feasible given Qubes' architecture.

BTW, my "low level" suggestion is more or less what xrandr does, except
that xrand is "global", so no per-vm customization is possible.

Ivan