server xfce-4.16 desktop WM-resolution fixed at SXGA 1280x1024 (despite --resize-display=yes), for 6.1.3-10.r0.el8 (any > xpra-server-5.0.9-10.r5.el8), rocky-linux-8.9

[sto6]

Using xpra repo, I noticed 6.1.x xpra-server now available so tried them. But the desktop does not resize to the client, always remains fixed at 1280x1024. Going backwards I found xpra-server-5.0.9-10.r5.el8 works.

For working resize-display:

dnf erase --noautoremove xpra\*
dnf install xpra-server-5.0.9-10.r5.el8 xpra-x11-5.0.9-10.r5.el8

Versions that work: xpra-server-5.0.7-10.r0.el8, xpra-server-5.0.9-10.r5.el8 Versions that fail: xpra-server-5.0.10-10.r0.el8, xpra-server-6.1.2-10.r1.el8, xpra-server-6.1.3-10.r0.el8

Server-start command:

xpra start-desktop :33 --exit-with-children=yes --start-child=startxfce4 --resize-display=yes --desktop-scaling=no --dpi=96 --audio=no

Client used: xpra v6.1.2-r1 (macOS, Intel Monterey 12.7.6). Client attach command:

/Applications/Xpra.app/Contents/MacOS/Xpra attach ssh://sto@cdsr0/33 --desktop-fullscreen=yes --desktop-scaling=no --dpi=96 --swap-keys=no --opengl=yes --ssh=ssh --ssh-upgrade=no

Contents of client-side ~/.xpra/xpra.conf:

pulseaudio=no
file-transfer=off
speaker=disabled
microphone=disabled
bell=no
printing=no
html=off
webcam=no
chdir=~/Desktop
dpi=96
opengl=yes
mode=ssh
ssh=ssh
desktop-fullscreen=yes
desktop-scaling=no
swap-keys=no
ssh-upgrade=no

• Server OS: Rocky-Linux 8.9, Intel
• Client OS: macOS, Intel Monterey 12.7.6
• Xpra Server Version 6.1.3-10.r0.el8 (any newer-than 5.0.9-10.r5.el8).
• Xpra Client Version v6.1.2-r1

[sto6]

5.0.9-attach-geom.log 6.1.3-10.r0-attach-geom.log

Did attach using -d geometry, and uploaded the client-side logs for server 5.0.9 vs server 6.1.3. In the client, each time, I took it out of full-screen, and tried to resize the client window with mouse. The server-6.1.3 starts at remote desktop size 1280x1024, and never logs anything in regard to resize or fullscreen:

% grep -i -e fullscreen -e 'size is ' -e resize 5.0.9-attach-geom.log 6.1.3-10.r0-attach-geom.log
5.0.9-attach-geom.log:2024-10-11 08:00:53,823  desktop size is 2560x1440:
5.0.9-attach-geom.log:2024-10-11 08:00:55,197  remote desktop size is 2560x1440
5.0.9-attach-geom.log:2024-10-11 08:01:03,931 _process_window_resized(1, 2560, 1387, 0) resizing window GLClientWindow(1 : GLDrawingArea(1, (2560, 1387))) (id=1) to (2560, 1387)
5.0.9-attach-geom.log:2024-10-11 08:01:03,932 resize(2560, 1387, 0) current size=(2560, 1387), fullscreen=False, maximized=False
5.0.9-attach-geom.log:2024-10-11 08:01:06,698 _process_window_resized(1, 2304, 1215, 0) resizing window GLClientWindow(1 : GLDrawingArea(1, (2304, 1215))) (id=1) to (2304, 1215)
5.0.9-attach-geom.log:2024-10-11 08:01:06,699 resize(2304, 1215, 0) current size=(2304, 1215), fullscreen=False, maximized=False
6.1.3-10.r0-attach-geom.log:2024-10-11 08:07:53,054  desktop size is 2560x1440:
6.1.3-10.r0-attach-geom.log:2024-10-11 08:07:54,260  remote desktop size is 1280x1024

[totaam]

xpra start-desktop :33 --exit-with-children=yes --start-child=startxfce4 --resize-display=yes --desktop-scaling=no --dpi=96 --audio=no

• resize-display=yes is the default for a server
• desktop-scaling=no doesn't do anything for the server
• dpi=96 - is this really needed?
• html=off doesn't do anything to the client

I have briefly tested with:

xpra start-desktop --bind-tcp=0.0.0.0:10000 --no-daemon --start=xterm

And the virtual display was resize to match my client-side window every time I resized it. (checked with xrandr from the xterm) Thedesktop-fullscreen` option interferes with resizing.

[sto6]

Eliminated {,--}desktop-fullscreen=yes from attach-cmd and .conf. No change: still can't resize. The initial client view is (properly) shrunk to the 1280x1024 remote size.

But something else odd. Just after server-start, before 1st xpra-client-attach, on remote I see:

$ env DISPLAY=:33 xrandr -q | fgrep -i -e '*' -e current -e primary
Screen 0: minimum 64 x 64, current 1280 x 1024, maximum 32767 x 32767
DUMMY0 connected primary 1280x1024+0+0 339mm x 271mm
   1280x1024@50  50.00*
$ env DISPLAY=:33 xdpyinfo | grep -i -e dimen -e resolu
  dimensions:    1280x1024 pixels (339x271 millimeters)
  resolution:    96x96 dots per inch

Then do 1st xpra-client-attach, and toggle to full-screen, and toggle back to non-full-screen. Now on remote I get:

$ env DISPLAY=:33 xrandr -q | fgrep -i -e '*' -e current -e primary
Screen 0: minimum 64 x 64, current 2560 x 1440, maximum 32767 x 32767
DUMMY0 connected primary 2560x1440+0+0 339mm x 271mm
   2560x1440     59.96*
$ env DISPLAY=:33 xdpyinfo | grep -i -e dimen -e resolu
  dimensions:    2560x1440 pixels (339x271 millimeters)
  resolution:    192x135 dots per inch

2560x1440 is my client monitor's (full-screen) resolution. Which looks like its DOING desktop-scaling, to fit/force a 2560x1440 server-desktop back into client-window size of 1280x1024 (with corresponding DPI change)?!

Perhaps remote server is kind-of sizing-up (due to 1st goto-full-screen) but not sizing-down (on exit-full-screen); could be CLIENT is the problem? The -d geometry I suspect isn't enough to show me some of the scaling info.

[sto6]

Tried just an xterm, similar to your last post (but via ssh), no improvement. Did brief test of newest macOS client: Xpra-x86_64-6.1.3-r0.pkg, no improvement.

fyi/aside: Downloads: The https://xpra.org/dists/MacOS/x86_64/Xpra-x86_64-6.1.3-r0.dmg download doesn't work for me (but .pkg works), MD5 is a match, but after installing, on open: macOS says it is a damaged app. The https://github.com/Xpra-org/xpra/wiki/Download has table under MacOS/Download Links: the arm64 links are to the beta dir: https://xpra.org/beta/MacOS/arm64/Xpra.dmg is a 404 (not found); only beta/osx/ exists & it's empty. They should now be like?: https://xpra.org/dists/MacOS/arm64/Xpra.dmg

[totaam]

macOS says it is a damaged app.

Seeing how hard it is to do simple things, it is macos that is damaged IMO! :laughing: will check.

the arm64 links are to the beta dir

Ah, right. I don't have the hardware to test macos arm64 builds properly and we also had a number of issues with them, so I pointed to the beta downloads to try to stay current / better quality builds. The problem with this is that we clear the beta area when a new release comes out... So anyway, fixed: https://github.com/Xpra-org/xpra/wiki/Download/_compare/30e691cf7f7d6129ab0e385fa406016a3dbeecfa

[totaam]

I can reproduce some problems now - but only with xfce and enlightenment. They seem to resist the changes in resolution for some unknown reason! (though I am able to change resolution through their settings GUI)

fluxbox, openbox, fvwm and metacity all manage the desktop without interfering with the resolution.

@sto6 please try a different desktop environment and always start simple (ie: xterm) before moving on to more difficult components.

[sto6]

This 'fix' works for me, for xfce as a remote desktop. 1st compared (working) 5.0.9 to (failing) 5.0.10, verified a fix in 5.0.10, then ported similar into xpra-x11-0:6.2.0-10.r2.el8.x86_64. I don't claim to know why the original departure from 5.0.9 code was made; nor what other side-effects this reversion may yield. (Also monitor_server.py in same dir appears to have similar code; did not try that).

$ git diff -U10 --no-index /usr/lib64/python3.11/site-packages/xpra/x11/desktop/desktop_server.py{-0,}
diff --git a/usr/lib64/python3.11/site-packages/xpra/x11/desktop/desktop_server.py-0 b/usr/lib64/python3.11/site-packages/xpra/x11/desktop/desktop_server.py
index 25ddfe9..d8682dd 100644
--- a/usr/lib64/python3.11/site-packages/xpra/x11/desktop/desktop_server.py-0
+++ b/usr/lib64/python3.11/site-packages/xpra/x11/desktop/desktop_server.py
@@ -34,22 +34,24 @@ class XpraDesktopServer(DesktopServerBase):
         super().__init__()
         self.session_type = "desktop"
         self.gsettings_modified = {}
         self.root_prop_watcher = None
         self.resize_value = -1, -1

     def server_init(self) -> None:
         super().server_init()
         from xpra.x11.vfb_util import set_initial_resolution, get_desktop_vfb_resolutions
         screenlog(f"server_init() randr={self.randr}, initial-resolutions={self.initial_resolutions}")
-        if not features.display:
+        if not self.randr or self.initial_resolutions==() or not features.display:
             return
+        # WAS: if not features.display:
+        #            return
         res = self.initial_resolutions or get_desktop_vfb_resolutions(default_refresh_rate=self.refresh_rate)
         if len(res) > 1:
             log.warn(f"Warning: cannot set desktop resolution to {res}")
             log.warn(" multi monitor mode is not enabled")
             res = (res[0],)
             log.warn(f" using {res!r}")
         with xlog:
             set_initial_resolution(res, self.dpi or self.default_dpi)

     def configure_best_screen_size(self) -> tuple[int, int]:

Environment (now in Rocky Linux 8.10, xfce4 4.16):

# dnf rq -q --installed provides /usr/lib64/python3.11/site-packages/xpra/x11/desktop/desktop_server.py
xpra-x11-0:6.2.0-10.r2.el8.x86_64

# dnf rq -q --installed xfce\* xfwm\*
xfce-polkit-0:0.3-3.el8.x86_64
xfce4-appfinder-0:4.16.1-3.el8.x86_64
xfce4-panel-0:4.16.3-1.el8.x86_64
xfce4-pulseaudio-plugin-0:0.4.3-3.el8.x86_64
xfce4-session-0:4.16.0-4.el8.x86_64
xfce4-settings-0:4.16.5-2.el8.x86_64
xfce4-terminal-0:1.0.4-1.el8.x86_64
xfwm4-0:4.16.1-1.el8.x86_64

# dnf rq -q --installed provides /usr/libexec/Xorg
xorg-x11-server-Xorg-0:1.20.11-24.el8_10.x86_64

Also, I earlier speculated the problem was: the (resizing) remote-desktop was being 'scaled' into 1280x1024 client-window. Now I believe the remote X-server was getting resized; but the xfce window-manager didn't get the message: remained at 1280x1024 forever.

Once even got into a state, after disabling Compositing, but which I so far have not been able to reproduce, where: the desktop bg-image size/extent and panel-positions/sizes reflected an upper-left 1280x1024 region-size always, but I could drag windows to render in part past that region towards the right and bottom (i.e. into the larger extents of client-window, which was black); so long as the top-left corner of the window (such as Terminal) always remained in the upper-left 1280x1024 region.

FYI, same 'fix' for xpra-x11-5.0.10-10.r0.el8.x86_64:

$ git diff -U10 --no-index /usr/lib64/python3.6/site-packages/xpra/x11/desktop/desktop_server.py{-0,}
diff --git a/usr/lib64/python3.6/site-packages/xpra/x11/desktop/desktop_server.py-0 b/usr/lib64/python3.6/site-packages/xpra/x11/desktop/desktop_server.py
index 806f51b..74a822d 100644
--- a/usr/lib64/python3.6/site-packages/xpra/x11/desktop/desktop_server.py-0
+++ b/usr/lib64/python3.6/site-packages/xpra/x11/desktop/desktop_server.py
@@ -32,22 +32,24 @@ class XpraDesktopServer(DesktopServerBase):
         super().__init__()
         self.session_type = "desktop"
         self.resize_timer = 0
         self.gsettings_modified = {}
         self.root_prop_watcher = None

     def server_init(self) -> None:
         super().server_init()
         from xpra.x11.vfb_util import set_initial_resolution, get_desktop_vfb_resolutions
         screenlog(f"server_init() randr={self.randr}, initial-resolutions={self.initial_resolutions}")
-        if not server_features.display:
+        if not self.randr or self.initial_resolutions==() or not server_features.display:
             return
+        # WAS: if not server_features.display:
+        #            return
         res = self.initial_resolutions or get_desktop_vfb_resolutions(default_refresh_rate=self.refresh_rate)
         if len(res)>1:
             log.warn(f"Warning: cannot set desktop resolution to {res}")
             log.warn(" multi monitor mode is not enabled")
             res = (res[0], )
             log.warn(f" using {res!r}")
         with xlog:
             set_initial_resolution(res, self.dpi or self.default_dpi)

[totaam]

This was changed in 27ccf0e88d8d9dae33ca9b925007bd00596ac249. The idea is to support fixed size displays using --resize-display=no:1080p. In this case, randr is False but we still want to set the initial resolution. I fail to see how restricting the code that calls set_initial_resolution could end up restricting what can be changed later on.

[sto6]

Holmes's Razor: What remains must be true: set_initial_resolution breaks xfce resizing, or is done too early... A bit brute-force: add new option to disable (i.e. skip) set_initial_resolution?

This also works for my case:

        if self.initial_resolutions==() or not features.display:

Aside, this does not report the equivalent of: found XRandR extension version 1.6, should it?:

$ python3.11 /usr/lib64/python3.11/site-packages/xpra/x11/bindings/randr_info.py

And extension version 1.6 vs randr.is_dummy16() are unrelated? (There are DUMMY0...DUMMY15).

[Anghille]

@sto6 is this change stable ?

I do have the same problem with XFCE and KDE where XPRA correctly change the resolution of the screen (you can for exemple see it in the settings > displays setting in XFCE), but the XFCE GUI resizing itself is non-functional.

I might need to build the code myself and add this change if this makes the resizing work.