[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Consider making screen resolution 1920x1080 by default for all VMs

On first boot, Whonix VMs (both gw and ws) display a default (very ugly) 1024x768 resolution:

This can fortunately be easily changed by changing the display setting to other resolutions.

Now I am not a display specialist (among many other things I am not a specialist of :slight_smile: ), but I have noticed that changing the display to 1920x1080 ALWAYS fills the entire screen, on whatever computer and configurations I have tested this.

It does not come as a surprise as 1920x1080 is the standard screen resolution in the industry (1080p).

So instead of forcing the user to once again edit stuff manually and risking to put off new KVM users, why not making 1920x1080 as default?

It only needs this file to be created: https://github.com/Whonix/whonix-xfce-desktop-config/tree/master/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

And adding two lines to the default version:

          <property name="Resolution" type="string" value="1920x1080"/>
          <property name="RefreshRate" type="double" value="60"/>

Thoughts?

EDIT: correction: we need to create https://github.com/Whonix/whonix-xfce-desktop-config/tree/master/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml, not modify https://github.com/Whonix/whonix-xfce-desktop-config/tree/master/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml !

2 Likes

Related discussion:

1 Like

What happens for VMs if host resolution is low? Then text in VMs looks so small that it’s difficult to lower screen resolution?

Needs a VM specific package since this should only be done in VMs, not on hosts?

Otherwise starting Whonix-Host with a too high desktop resolution could lead to broken graphics by default. (In past I managed to set settings which where impossible to revert due to broken graphics. Or monitor change didn’t work. Hard/undocumented to fix on command line.)

Don’t know. But I doubt lower resolutions than 1920x1080 are still common nowadays. Wonder whether such machines could even run Whonix VMs. Reminds me of the 32 bits deprecation debate.

Yes, most probably…

Agreed.

1 Like

The auto resizing is not flawless unfortunately. It requires 2 reboots for it to kick in for some reason. It seems every stable release brings its new surprises an headaches for this feature. I don;t even know what is broken this time around so I an report it to the right upstream project.

1 Like

Could you test this please?

  1. get a new Whonix KVM VM that was never booted before
  2. don’t boot to graphical user interface (use rads or so)
  3. create the suggested settings file (in home folder, not /etc/skel, because skel to home is already done at that time)
  4. reboot normally (into XFCE)

(Alternatively: a new Whonix build with this settings file in /etc.; Or (chroot) editing the disk image before booting it for the first time.)

Does that work? Does that maybe even workaround auto resize issues?

I just booted a Whonix WS that had never been booted before.

Prior to that I mounted its disk in another VM and created the following file:
/home/user/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

<?xml version="1.0" encoding="UTF-8"?>

<channel name="displays" version="1.0">
  <property name="Default" type="empty">
    <property name="Virtual-0" type="string" value="Virtual-0">
      <property name="Active" type="bool" value="true"/>
      <property name="Resolution" type="string" value="1920x1080"/>
      <property name="RefreshRate" type="double" value="60"/>
      <property name="Rotation" type="int" value="0"/>
      <property name="Reflection" type="string" value="0"/>
      <property name="Primary" type="bool" value="true"/>
      <property name="Position" type="empty">
        <property name="X" type="int" value="0"/>
        <property name="Y" type="int" value="0"/>
      </property>
    </property>
  </property>
</channel>

Screen resolution worked fine on first boot. 1920x1080. Just as expected.

I have never experienced such thing.

2 Likes

Reamed https://github.com/Whonix/power-savings-disable-in-vms to https://github.com/Whonix/vm-config-dist

We now have a package in which we can add anything that should only happen inside VMs.

Added config.

Commit:

File:

1 Like

This is included in Whonix 15.0.1.0.3-developers-only.

As of 15.0.1.0.3-developers-only it does nothing in VirtualBox. Also does not break it.

There might be a regression in 15.0.1.0.4-developers-only but chances are slim.


15.0.1.0.3-developers-only does not change anything in VirtualBox. KVM seems to use Virtual-0 as monitor name. In VirtualBox XFCE added a new section Virtual1 to displays.xml config file. That inspired me. This commit might likely also fix VirtualBox:

(But there is a small chance that this will interfere with KVM.)

Resolution is actually too high for VirtualBox but that’s actually good because: it triggers VirtualBox to automatically scale down to optional (auto-resize) screen resolution.

This would work around a pretty difficult to report, find workaround, fix VirtualBox issue:
https://www.whonix.org/wiki/Dev/VirtualBox#Resize_Issues


Can these virtual monitor names Virtual-0 vs Virtual1 be configured somewhere so we could use the same for both VirtualBox and KVM?

https://bugzilla.redhat.com/show_bug.cgi?id=1814766

1 Like

Some adjustment is needed.

After more testing, it appears that correct default display property name for Whonix VM is Virtual-1, not Virtual-0 (this seems to correspond to the virtio video model, see below).

Just tested now: using newly built Whonix VM 15.0.1.0.3, on first boot the expected 1920x1080 resolution did not launch. It appears that it is caused by the fact that Whonix VM default display name is Virtual-1 and not Virtual-0, and thus it could not launch the correct settings for Virtual-0. Replacing Virtual-0 by Virtual-1 in the skel file fixes the error (now boots into 1920x1080 mode on first boot).

Explanation (empiric findings):
It seems that current Whonix KVM video settings (virtio video model type):

<video>
      <model type='virtio' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>

result in a Virtual-1 display value inside the Whonix VM (by the way is there a specific reason for using virtio driver instead of virt-manager default qxl driver?).

When replacing these values by default values set by virt-manager for a new virtual machine (qxl video model):

<video>
  <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
</video>

Whonix VM display is now set to Virtual-0.

Could you please test it on your own hardware?

  • -> boot a Whonix VM (gw or ws): what does the “display” setting show? (expected: Virtual-1).
  • -> shut down the vm. In virt-manager, change the “video” model from virtio to QXL. Reboot the vm. What does the “display” setting show? (expected: Virtual-0)…

If you confirm my findings I assume we can safely replace Virtual-0 by Virtual-1 in https://github.com/Whonix/vm-config-dist/blob/master/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

Another, maybe even safer solution would be to duplicate Virtual-0 settings for Virtual-1, just in case. This seems to work in all scenarios (correct Virtual-0 or Virtual-1 settings are picked up by the machine automatically depending on the video driver used):

<?xml version="1.0" encoding="UTF-8"?>

<channel name="displays" version="1.0">
  <property name="Default" type="empty">
    <property name="Virtual-0" type="string" value="Virtual-0">
      <property name="Active" type="bool" value="true"/>
      <property name="Resolution" type="string" value="1920x1080"/>
      <property name="RefreshRate" type="double" value="60"/>
      <property name="Rotation" type="int" value="0"/>
      <property name="Reflection" type="string" value="0"/>
      <property name="Primary" type="bool" value="true"/>
      <property name="Position" type="empty">
        <property name="X" type="int" value="0"/>
        <property name="Y" type="int" value="0"/>
      </property>
    </property>
    <property name="Virtual-1" type="string" value="Virtual-1">
      <property name="Active" type="bool" value="true"/>
      <property name="Resolution" type="string" value="1920x1080"/>
      <property name="RefreshRate" type="double" value="60"/>
      <property name="Rotation" type="int" value="0"/>
      <property name="Reflection" type="string" value="0"/>
      <property name="Primary" type="bool" value="true"/>
      <property name="Position" type="empty">
        <property name="X" type="int" value="0"/>
        <property name="Y" type="int" value="0"/>
      </property>
    </property>
  </property>
1 Like

Not sure if still up to date. This is what I recently read about it:

Maybe create a separate discussing for that if needed.

If figured out, could you please send a pull request against https://github.com/Whonix/whonix-libvirt/tree/master/usr/share/whonix-libvirt/xml?
Then let’s hope @HulaHoop doesn’t find any problem with that.

Yes, for sure. Also to keep support for users who are still using the old XML file version.

What’s causing the KVM dash “-”?
Virtual-0

VirtualBox does not have any dash.
Virtual1

If monitor name could be same for KVM and VirtualBox then that config file could be simplified.

Also as for https://github.com/Whonix/vm-config-dist/blob/master/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml … If you have any suggestions please send a pull request. I guess easiest is to merge it, create a git tag and then let everyone test.

Documented the recommendation here explaining why virtio-gpu is used and noth qxl which is obsolete:

https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/ [archive]

According to Gerd Hoffman (libvirt dev) vhost-user virtio gpu is the ideal mode for performance and security but this is only available as of QEMU 4.1 which came after the Buster freeze[5] Libvirt support is also pending.

QXL has been superseded by virtio-vga where most development happens (and security attention probably). 2D acceleration as a distinct mechanism is outdated and 3D mode is where all types of graphical acceleration will be handled:

" This device has support for 2D acceleration. This becomes more and more useless though as modern display devices don’t have dedicated 2D acceleration support any more and use the 3D engine for everything. The same happens on the software side, modern desktops are rendering with opengl or vulkan instead of using 2D acceleration. "

@onion_knight if you see everything works alright that’s ok with me.

1 Like

Let’s keep the new virtio video driver instead of qxl as it is as per @HulaHoop explanations.

I don’t know. And I am a bit confused, because I see that the file already has both Virtual-0 and Virtual-1 entries (without dash for Virtual-1), while the original file had only Virtual-0 entry, did you already modify it in the meantime?

Anyway, I corrected it. Hopefully it’s working now.

I will try to test it on VirtualBox later.

2 Likes

Yes. Before. See:

That was me to fix VirtualBox. :slight_smile:

Will re-add VirtualBox support on top.

Here it is:

Full file:

https://github.com/Whonix/vm-config-dist/blob/master/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

Above file edited. Hope it didn’t break KVM but I guess is ok.

Also managed to fix (workaround) VirtualBox initial screen resolution.


1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]