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.
On Fri, Nov 30, 2018, 4:23 AM Achim Patzner <[email protected] 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.
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
--
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 [email protected].
To post to this group, send email to [email protected].
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.
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/a9b0aea0-1a29-aa56-8a7b-ef268e0ee8c5%40maa.bz.
For more options, visit https://groups.google.com/d/optout.
