add support for xrandr hotplug_mode_update property / SPICE resize support

Martin said:

GNOME changed that here: https://gitlab.gnome.org/GNOME/mutter/commit/957513242c26be458be7a101b83180e3f59f6a44

Olivier Fourdan @olivier said:

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).

As a workaround, I use https://github.com/seife/spice-autorandr

I'll give that spice-autorandr a try... Thanks for mentioning.

FWIW, I tried spice-autorandr, but couldn't make it work. Seems there's still value in fixing this issue :-).

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.

This affects users of Kali Linux who run it through libvirt / qemu.

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:

https://docs.gtk.org/gdk3/class.Screen.html#signals

And xfwm4 already listens to the existing GdkScreen signals.

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?

FYI: there is another issue in the vd_agent repo about the same problem.

possible temp fix is a udev rule that I found

https://gist.githubusercontent.com/wynnchel/02f5218b0abf5d8c1ee0b0d7d08646cd/raw/f0f59f56766fb6ec892b5a6d5a2617c235793b27/x-resize

I have applied it and it's working ok in my testing

For Arch users, I have created an x-resize AUR package for easier installation.

Hi! Where did you get that Expat (MIT) license from; did you contact the Gist author?

I've asked here: https://gist.github.com/3lpsy/4cc344ae031bf77595991c536cbd3275?permalink_comment_id=4735124#gistcomment-4735124

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.

Thanks for honesty :-)

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

Yeah, even using the gist script as-is doesn't work here.

@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.log
2023-12-30 04:33:41 (INFO): screen 0 resized from 1024x768 to 1918x1010
2023-12-30 04:33:48 (INFO): screen 0 resized from 1918x1010 to 958x1010
2023-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!

Finally, @3lpsy added a license identifier (MIT). I also updated my gist fork.

@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?

The original x-resize didn't work for me either, so I had to apply some patches. See my fork, if you are interested in the changes: https://gist.github.com/IngoMeyer441/84cf1e40fa756a9c3e6c8d9e38ee9b6f.

Hi, and thanks for the feedback! The logging library comes from the guile-lib package, which is called guile-library in Debian (see: https://packages.debian.org/bookworm/guile-library).

The script was created to solve this issue for the GNU Guix demo VM image: https://issues.guix.gnu.org/57068; the vm-image.template operating system definition only needs to add the x-resize package to get the extra dependencies pulled in the VM image (see: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1d4db94bebbaecfd4ddd96f90b8dc3ae3f6bf1a3). I think this should be true for Arch and other distributions as well, assuming your x-resize package lists the required dependencies.

added 2. Feature label

add support for xrandr hotplug_mode_update property / SPICE resize support

Submitted by Martin

Description

Designs

Child items ...

Activity