I use a SPICE viewer [1] to connect to a machine running XFCE 4.12 (Debian Buster). Unfortunately spice-vdagent altered its behaviour from changing screen resolution itself to just informing the Window manager / Desktop Environment of the resolution change ("hotplug_mode_update"). So automatic resizing of all components in the viewer window fails. Other DE (KDE and GNOME) change screen resolution without problems, as they somehow fixed that problem.
Several bugs were filed in the last years [2], but the problem persists.
Could you please fix this, as I like the snappiness of xfce on poorly equipped/older machines and I do not want to switch to another DE.
Yes, but xfce is different from GNOME, in xfce, xfwm4 does not drive the xrandr modes, so this would be implemented in xfsettingsd instead, moving component.
Is there any chance to get this fixed? The (original) bug is now 7 years old and seems not to get any attention. From what I've seen in the gnome commit it's quite a small change (unfortunately I'm not a C programmer, otherwise I'd try a PR).
Here's a mcron-based workaround that worked for a Guix System VM with Xfce. It simply calls xrandr -s 0 (which sets the preferred resolution detected) every second:
1 file changed, 16 insertions(+), 1 deletion(-)gnu/system/examples/vm-image.tmpl | 17 ++++++++++++++++-modified gnu/system/examples/vm-image.tmpl@@ -5,7 +5,7 @@ ;; (use-modules (gnu) (guix) (srfi srfi-1))-(use-service-modules desktop networking spice ssh xorg)+(use-service-modules desktop mcron networking spice ssh xorg) (use-package-modules bootloaders certs fonts nvi package-management wget xorg)@@ -24,6 +24,18 @@ Run '\x1b[1;37minfo guix\x1b[0m' to browse documentation. accounts.\x1b[0m "))+;;; XXX: Xfce does not implement what is needed for the SPICE dynamic+;;; resolution to work (see:+;;; https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/142). Workaround it+;;; by manually invoking xrandr every second.+(define auto-update-resolution-crutch+ #~(job '(next-second)+ (lambda ()+ (setenv "DISPLAY" ":0.0")+ (setenv "XAUTHORITY" "/home/guest/.Xauthority")+ (execl (string-append #$xrandr "/bin/xrandr") "xrandr" "-s" "0"))+ #:user "guest"))+ (operating-system (host-name "gnu") (timezone "Etc/UTC")@@ -89,6 +101,9 @@ root ALL=(ALL) ALL ;; integration with the host, etc. (service spice-vdagent-service-type)+ (simple-service 'cron-jobs mcron-service-type+ (list auto-update-resolution-crutch))+ ;; Use the DHCP client service rather than NetworkManager. (service dhcp-client-service-type))
All the workarounds I have seen do not work for maximizing the window. This is a needed function since projects like Whonix desire lightweight over maturity and functionality.
I'm impressed that I used to face this problem around 6y ago. Today (2023) I installed a new VM with XFCE, after so many years, and the same issue is still there. TBH I'm not going to wait for a fix, instead I'm going to delete the VM and reinstall it with a different windows manager.
TBH I'm not going to wait for a fix, instead I'm going to delete the VM and reinstall it with a different windows manager.
Oh, that's perfectly OK, I completely understand.
That said, I think the main problem of this issue here is that it is not filed to the correct component, the settings is there for the user to control the configuration, it is not involved when the configuration changes behind its back and the WM needs to adjust.
FWIW, xfwm4 relies on GDK for the XRandR configuration changes:
So first thing would be to check whether GDK (from GTK3) emits a signal whenever that hotplug event occurs. If not, there is nothing xfwm4 can do I'm afraid.
That said, I think the main problem of this issue here is that it is not filed to the correct component
Glad to see that you pointed out to a roadmap for a resolution. AFAIK in GL there are no components (it's a BZ thing, right?). In this case, how would you proceed? Should we add the right labels to the issue or could you assign it to the right person?
To be honest, I copied a PKGBUILD of my own software packages and forgot to update the license field. I don't know under which license the original snippet was released, so MIT is probably wrong. I will fix this as soon as the snippet author replies to your message.
I've tried implementing the basic idea of the gist in a script of my own but it doesn't work; only the originally discovered xrandr -s 0 causes the screen to resize, not commands like DISPLAY=:0 xrandr --output "Virtual-1" --auto. I've reported my findings to the xrandr project here: https://gitlab.freedesktop.org/xorg/app/xrandr/-/issues/71
@IngoMeyer I haven't heard from the gist author w.r.t. licensing. I've made a nicer script, licensed GPL-3.0-or-later, which runs per-user via XDG autostart: https://gitlab.com/Apteryks/x-resize/. It logs screen resizing events like:
$ cat .local/state/x-resize.log.1 2023-12-30 04:31:58 (INFO): x-resize started; logging to /home/guest/.local/state/x-resize.log2023-12-30 04:33:41 (INFO): screen 0 resized from 1024x768 to 1918x10102023-12-30 04:33:48 (INFO): screen 0 resized from 1918x1010 to 958x10102023-12-30 04:34:27 (INFO): screen 0 resized from 958x1010 to 958x470
To build/install it, run ./configure && make install, then logout then back in your Xfce session. I'd be curious to know how it works for you! Or any other feedback. Hope it helps!
@Apteryks Thanks for your work. I tried to get your x-resize running, but couldn't succeed yet. Guile is in the official Arch repositories, but its libraries are not and the logging component seems to be missing in the AUR (required guile module not found: (logging logger) when running the configure script). I also tried to use guix (like described in your HACKING document), but couldn't succeed either. It is an AUR package and seems to be incomplete.
I am always a fan of using new languages, but wouldn't it be better to depend on system defaults for a script / package which should run on fresh virtual machines?