search

utmapp / UTM

Virtual machines for iOS and macOS
https://getutm.app
Apache License 2.0
26.23k stars 1.32k forks source link

Automatic Resize Display not working #4064

Open Drake0815 opened 2 years ago

Drake0815 commented 2 years ago

I have Upgrade my UTM Version from 3.1.5 to 3.2.4 Since the Upgrade I have the Problem that the automatically reside from the Display not working. Spice Toll is installed

image

UTM Version 3.2.4 OS Version 12.3.1 Apple MacBook 14" M1 Pro

w0utert commented 2 years ago

I'm having the same problem and found some additional information that may be useful for debugging.

Guest OS has spice-vdagent & spice-vdagentd running, but when resizing the UTM window the spice-vdagentd log shows the following:

● spice-vdagentd.service - Agent daemon for Spice guests
     Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indirect; vendor preset: disabled)
     Active: active (running) since Sun 2022-05-29 13:30:57 CEST; 3s ago
TriggeredBy: ● spice-vdagentd.socket
    Process: 868 ExecStart=/usr/bin/spice-vdagentd $SPICE_VDAGENTD_EXTRA_ARGS (code=exited, status=0/SUCCESS)
   Main PID: 869 (spice-vdagentd)
      Tasks: 2 (limit: 11808)
     Memory: 1.1M
        CPU: 9ms
     CGroup: /system.slice/spice-vdagentd.service
             └─869 /usr/bin/spice-vdagentd

May 29 13:30:57 derp systemd[1]: Starting Agent daemon for Spice guests...
May 29 13:30:57 derp systemd[1]: Started Agent daemon for Spice guests.
May 29 13:30:57 derp spice-vdagentd[869]: opening vdagent virtio channel
May 29 13:30:57 derp spice-vdagentd[869]: Set max clipboard: 104857600
May 29 13:30:57 derp spice-vdagentd[869]: invalid message size for VDAgentMonitorsConfig
May 29 13:30:57 derp spice-vdagentd[869]: Set max clipboard: 104857600
May 29 13:30:57 derp spice-vdagentd[869]: invalid message size for VDAgentMonitorsConfig

I quickly checked the spice-vdagentd source code, and this message is logged in spice-vdagentd.c on line 212 when the service receives a monitor configuration message with an unexpected message body size:

static void do_client_monitors(VirtioPort *vport, int port_nr,
    VDAgentMessage *message_header, VDAgentMonitorsConfig *new_monitors)
{
    VDAgentReply reply;
    uint32_t size;

    /* Store monitor config to send to agents when they connect */
    size = sizeof(VDAgentMonitorsConfig) +
           new_monitors->num_of_monitors * sizeof(VDAgentMonConfig);

    if (message_header->size != size) {
        syslog(LOG_ERR, "invalid message size for VDAgentMonitorsConfig");
        return;
    }

It seems as if the side that sends the monitor config message (UTM/QEMU) and the side that receives it (the spice-vdagentd inside the VM) are using a different protocol, possibly some mismatch in the SPICE version used to build UTM and the one in the VM? The spice-vdagent in Arch is version 0.22.1 released three months ago.

I did try to find some clues in the UTM source code but it seems this code that sends this message is somewhere in a QEMU or SPICE dependency, and building all that myself seems complicated.

UTM Version 3.2.4 (58) Host OS: macOS Monterey 12.4 Guest OS: Arch Linux aarch64 with i3 desktop environment Apple MacBook 14" M1 Pro

w0utert commented 2 years ago

I would like to try to debug this myself, as auto-resizizing the desktop environment running inside the VM so I can set it fullscreen is an important feature for me.

I've checked out the UTM code + the sys root and I can build and run the UTM GUI, but I need some help running a VM from Xcode with a debugger enabled. Right now when I try to start a VM I just get a 'Failed to connect to SPICE' and that's it.

Are there any instructions available somewhere to explain how to work on the code, starting the GUI from Xcode with a debugger attached, any configuration required to be able to start a VM while running in the debugger, etc?

pfremm commented 2 years ago

@w0utert Are you sure the latest spice drivers for your OS doesn't resolve this? I had this issue but probably 3-4 months ago I updated spice tools in my windows VM and this issue was resolved.

Drake0815 commented 2 years ago

@pfremm i have running two systems with UTM.

  1. Kali Linux Version 2022.02 with the news available Spice Version 0.22.1-3
  2. Debian 11 (bullseye) with the newes available Spice Version 0.20.0-2

With Debian the automatic resize from the Display is working fine. But with Kali not

w0utert commented 2 years ago

@w0utert Are you sure the latest spice drivers for your OS doesn't resolve this? I had this issue but probably 3-4 months ago I updated spice tools in my windows VM and this issue was resolved.

I'm using 0.22.1, which appears to be the latest version. My experience exactly matches @Drake0815: the auto-resizing did work with an earlier UTM version (Arch Gnome desktop) but not with the latest (different VM, also Arch but now with i3). It really looks as if in the latest release, a mismatch was introduced in the SPICE protocol versions on both sides (host and guest).

In the mean time, I've configured i3 keybindings to resize the desktop manually using xrandr, which works. So there is no problem with the X session or the WM itself, just with the spice-vdagent that doesn't understand the monitor config messages it receives.

javitab commented 2 years ago

Just adding my $.02 that, while I didn't have it working prior, auto resize is not working for me either. I have an Ubuntu 22.04 guest with KDE and spice-vdagent running per x-session and spice-vdagentd running, but no resizing is happening. Clipboard works, but no resize. Current spice-vdagent version is 0.22.1-1 as gotten from Ubuntu repo.

pefribeiro commented 2 years ago

Same issue here with Ubuntu 22.04 LTS guest. Any workaround?

qdmudong commented 2 years ago

Same issue here with Ubuntu 20.04 LTS guest on MacOS.

kurzdev commented 2 years ago

Same issue here with macOS host and EndeavourOS guest (Kernel 5.18.15-arch1-1), spice 0.15.0-1, spice-gtk 0.41-2, spice-protocol 0.14.4-1 and spice-vdagent 0.22.1-2 😢

gkhull commented 1 year ago

I found a workaround for windows at least. Enable retina mode in the UTM vm display settings. Then in windows set the dpi to 175%

alanomeara1 commented 1 year ago

Partial fix/workaround but need to add @reboot + command to crontab -e to run every time VM reboots or run command manually each time. Otherwise make and alias in bashrc or add something to startup.sh

You may also need to change window scaling depending on what you're running. May need some finessing to get it the way you want it.

Source: https://docs.getutm.app/guest-support/dynamic-resolution/

Resolution is not changing on Linux:

There is a known bug on some distributions that prevents dynamic resolution from working. The following command will force the window manager to update the resolution:

$ xrandr --output Virtual-1 --auto

meop commented 1 year ago

I found the xrandr command above to work on Debian ARM with XFCE, but not consistently.

For Arch ARM with KDE (Plasma), xrandr command was not required. However, in order for SPICE clipboard and display resize to work in KDE, I needed to edit the spice-vdagent XDG autostart file (comment out the X-GNOME line): https://github.com/systemd/systemd/issues/18791

sunmast commented 1 year ago

Hit the same issue after upgrading Debian 11 to testing (spice-vdagent version is upgraded to 0.22)

asoltesz commented 1 year ago

The xrandr workaround is working for me (Macbook Pro M1, Manjaro, KDE 5.27, UTM 4.2.5)

Also, I had to execute it only once and the effect persisted between VM restarts without any cron or startup script. After the first application of the xrandr command the resizing seems to work without any manual intervention or repeat.

I had to comment out the X-GNOME line from the desktop file of the Spice agent to make it work at all (but that is a general issue, not related to resizing)

rsmogura commented 1 year ago

For Ubuntu install spice-vdagent: sudo apt-get install spice-vdagent Check if two spice processes are running, like here

rado@rado-vm # ps -A |grep spice-vd
   1557 ?        00:00:01 spice-vdagentd
  10448 ?        00:00:00 spice-vdagent

The first one is a daemon which should be started autmatically. The 2nd one (spice-vdagent) should be started as part of XDG autostart. For me, it was not started in Ubuntu 23, but it works ok with Ubuntu 22.

spice-vdagent - can be started from a console or from some X profile scripts

whi-tw commented 1 year ago

I've done a workaround which may help people: https://gist.github.com/whi-tw/30878179fffd9b994cc978beb894bd9b

/opt/utm-resolution-fix/watch-and-fix.sh

#!/usr/bin/env bash

journalctl -fu spice-vdagentd -g 'invalid message size for VDAgentMonitorsConfig' -n0 |\
while read line; do
    echo "window changed, resizing"
    xrandr --output Virtual-1 --auto
done

/etc/systemd/user/utm-resolution-fix.service


[Unit]
Description=Watch for SPICE errors and resize display

[Service] Type=simple Restart=always RestartSec=1 Environment=DISPLAY=:0 ExecStart=/opt/utm-resolution-fix/watch-and-fix.sh

[Install] WantedBy=default.target



Yep, it's super grubby, but is barely using any resources, starts on boot and automatically does the resizing when necessary
rsmogura commented 1 year ago

Thanks. Frankly speaking I think this should be opened upstream on Ubuntu, I'll check launchpad and open bug there.

whi-tw commented 1 year ago

Frankly speaking I think this should be opened upstream on Ubuntu, I'll check launchpad and open bug there.

Agreed, although I'm facing this problem on Parrot, so it may be a 'not our problem' response

kroko commented 11 months ago

While using

On M2 Max

the observations about autoscaling for vanilla installations are

ghost commented 10 months ago

Same problem hope a fix it drive me crazy

cutzenfriend commented 10 months ago

Debian 12 arm has the same issues on M1 Max on OS Sonoma

ghost commented 10 months ago

Fedora 38 arm do not have the issue (if it can help to track down the culprit)

whi-tw commented 10 months ago

Thanks. Frankly speaking I think this should be opened upstream on Ubuntu, I'll check launchpad and open bug there.

@rsmogura did you ever find anything on launchpad?

w0utert commented 10 months ago

Thanks. Frankly speaking I think this should be opened upstream on Ubuntu, I'll check launchpad and open bug there.

I’m not sure this really is an Ubuntu problem and not an UTM problem, I’ve been using QEMU for virtualizing Ubuntu 22.04 before on a Linux host, and never experienced this kind of resizing problem when using for example the virt-manager graphics console or VNC to connect to the VM. And as mentioned before, I had the same problem on Arch i3, but only after upgrading UTM (this was long ago, around the date this ticket was filed)

osy commented 10 months ago

I don't know if virt-manager uses SPICE but VNC definitely isn't SPICE so idk if it's comparable. I haven't tried Wayland but it sounds like there's some compatibility issues with spice-vdagent

w0utert commented 10 months ago

I don't know if virt-manager uses SPICE but VNC definitely isn't SPICE so idk if it's comparable. I haven't tried Wayland but it sounds like there's some compatibility issues with spice-vdagent

I mean the graphics console built into virt-manager which can be configured to use either SPICE or VNC. I think the way it works is when you configure it as VNC is that QEMU just grabs the framebuffer from the virtualized video driver and runs a VNC server on the host that the graphics console then uses. You don’t need to run any server inside the guest itself for this to work, it even works for a DOS VM for example. For a Linux desktop guest, when you resize the graphics console window virt-manager communicates with the spice-vdagent in the guest to tell it to resize the desktop, so same idea as UTM. I’m not an expert though so maybe I’m misunderstanding. Anyway, it was not working as expected on Arch i3 either, while it used to work for the same VM before the UTM update

shenghan97 commented 10 months ago

I've done a workaround which may help people: https://gist.github.com/whi-tw/30878179fffd9b994cc978beb894bd9b

/opt/utm-resolution-fix/watch-and-fix.sh

#!/usr/bin/env bash

journalctl -fu spice-vdagentd -g 'invalid message size for VDAgentMonitorsConfig' -n0 |\
while read line; do
  echo "window changed, resizing"
  xrandr --output Virtual-1 --auto
done

In my VM this script will run xrandr multiple times each time if I ever restart the service. I think has something to do with how grep option (-g) of journalctl works. I tweaked it a little bit by using actual grep command so it will work regardless of restarts:

#!/usr/bin/env bash

journalctl -fu spice-vdagentd -n0 | grep --line-buffered  "invalid message size for VDAgentMonitorsConfig"  |\ 
while read line; do
        echo "window changed, resizing"
        xrandr --output Virtual-1 --auto
        # Set display scale to 2.0 
        # /usr/bin/python3 /opt/utm-resolution-fix/set-scale.py
done

But actually, on my machine, the auto-resizing works fine in terms of resolution, but the scale setting will not persist during the resize - ubuntu will always default to 1x scale on a lower resolution. I modified the code from this answer on askubuntu (https://askubuntu.com/a/1267328) to create a script to set the scale automatically upon resizing. Uncomment the line /usr/bin/python3 /opt/utm-resolution-fix/set-scale.py in the script above to enable this.

/opt/utm-resolution-fix/set-scale.py

#!/usr/bin/python3
# Note: use system python3, not /usr/bin/env, because whichever python3 is on
# $PATH may not have dbus, but the system python3 does.

"""Toggle display scaling between 100% and 200%.

Based on https://gist.github.com/strycore/ca11203fd63cafcac76d4b04235d8759

For data structure definitions, see
https://gitlab.gnome.org/GNOME/mutter/blob/master/src/org.gnome.Mutter.DisplayConfig.xml
"""

import dbus

namespace = "org.gnome.Mutter.DisplayConfig"
dbus_path = "/org/gnome/Mutter/DisplayConfig"

session_bus = dbus.SessionBus()
obj = session_bus.get_object(namespace, dbus_path)
interface = dbus.Interface(obj, dbus_interface=namespace)

current_state = interface.GetCurrentState()
serial = current_state[0]
connected_monitors = current_state[1]
logical_monitors = current_state[2]

# Multiple monitors are more complicated. For now, since I only use one monitor
# in Ubuntu, everything is hard-coded so that only info about the first monitor
# is used, and only it will be connected after running the script.
#
# If someday updating this script: a logical monitor may appear on mutiple
# connected monitors due to mirroring.
connector = connected_monitors[0][0][0]
current_mode = None
# ApplyMonitorsConfig() needs (connector name, mode ID) for each connected
# monitor of a logical monitor, but GetCurrentState() only returns the
# connector name for each connected monitor of a logical monitor. So iterate
# through the globally connected monitors to find the mode ID.
for mode in connected_monitors[0][1]:
    if mode[6].get("is-current", False):
        current_mode = mode[0]
updated_connected_monitors = [[connector, current_mode, {}]]

x, y, scale, transform, primary, monitors, props = logical_monitors[0]

if scale == 2.0: exit()

scale = 2.0

monitor_config = [[x, y, scale, transform, primary, updated_connected_monitors]]

# Change the 1 to a 2 if you want a "Revert Settings / Keep Changes" dialog
interface.ApplyMonitorsConfig(serial, 1, monitor_config, {})
print('Set scale to 2.0')
Jugulaire commented 5 months ago

Hi, just adding a more elegant way of making dynamic resolution. We gonna just use the udev event for that.

YOU MUST have installed : 

sudo apt install spice-vdagent
sudo systemctl start spice-vdagent
sudo systemctl enable spice-vdagent

Here is my config files for the udev rule : 

sudo cat /etc/udev/rules.d/10-resize.rules
ACTION=="change",KERNEL=="card0", SUBSYSTEM=="drm", RUN+="/usr/local/bin/resize"

Now the script it trigger : 

sudo cat /usr/local/bin/resize            
#! /bin/sh 
PATH=/usr/bin
desktopuser=$(/bin/ps -ef  | /bin/grep -oP '^\w+ (?=.*vdagent( |$))') || exit 0
export DISPLAY=:0
export XAUTHORITY=$(eval echo "~$desktopuser")/.Xauthority
xrandr --output "$(xrandr | awk '{if($0 ~/ connected/){print $1}}')" --auto

The script take account of the possibility that the monitor is not named Virtual-1

I can confirm that's not an issue from UTM because i apply similar workaround for almost every Kali install i do. And it is also a bug that have been signaled for years without any real fix.

ghost commented 5 months ago

Hi, just adding a more elegant way of making dynamic resolution. We gonna just use the udev event for that.

YOU MUST have installed :

sudo apt install spice-vdagent
sudo systemctl start spice-vdagent
sudo systemctl enable spice-vdagent

Here is my config files for the udev rule :

sudo cat /etc/udev/rules.d/10-resize.rules
ACTION=="change",KERNEL=="card0", SUBSYSTEM=="drm", RUN+="/usr/local/bin/resize"

Now the script it trigger :

sudo cat /usr/local/bin/resize            
#! /bin/sh 
PATH=/usr/bin
desktopuser=$(/bin/ps -ef  | /bin/grep -oP '^\w+ (?=.*vdagent( |$))') || exit 0
export DISPLAY=:0
export XAUTHORITY=$(eval echo "~$desktopuser")/.Xauthority
xrandr --output "$(xrandr | awk '{if($0 ~/ connected/){print $1}}')" --auto

The script take account of the possibility that the monitor is not named Virtual-1

I can confirm that's not an issue from UTM because i apply similar workaround for almost every Kali install i do. And it is also a bug that have been signaled for years without any real fix.

Personally on fedora simply update do the trick since they updated the package who introduced to problem but thanks.

fig-stack commented 1 month ago

Hi, just adding a more elegant way of making dynamic resolution. We gonna just use the udev event for that.

YOU MUST have installed :

sudo apt install spice-vdagent
sudo systemctl start spice-vdagent
sudo systemctl enable spice-vdagent

Here is my config files for the udev rule :

sudo cat /etc/udev/rules.d/10-resize.rules
ACTION=="change",KERNEL=="card0", SUBSYSTEM=="drm", RUN+="/usr/local/bin/resize"

Now the script it trigger :

sudo cat /usr/local/bin/resize            
#! /bin/sh 
PATH=/usr/bin
desktopuser=$(/bin/ps -ef  | /bin/grep -oP '^\w+ (?=.*vdagent( |$))') || exit 0
export DISPLAY=:0
export XAUTHORITY=$(eval echo "~$desktopuser")/.Xauthority
xrandr --output "$(xrandr | awk '{if($0 ~/ connected/){print $1}}')" --auto

The script take account of the possibility that the monitor is not named Virtual-1

I can confirm that's not an issue from UTM because i apply similar workaround for almost every Kali install i do. And it is also a bug that have been signaled for years without any real fix.

This worked perfectly for me.