Running Windows 7 or 10, connecting to Fedora 31. Commands used (wrapped for readability):
set XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION=1024x768 xpra start-desktop --exit-with-children=yes --start-child=startkde email@example.com:22/100 --min-quality=80 --speed=80 --clipboard=yes --clipboard-direction=both --speaker=off
When I exit from an app, say Konsole, the screen doesn't repaint so the last app output remains visible. Forcing a refresh from the system tray works. Attached is a screenshot of a popup I get on login. I've clicked on the cancel button and the screen under that button has updated, but nothing else. I've only very recently tried start-desktop, so I don't know if this is a new problem.
Linux version is v3.0.2-r24387 Windows version is 22.214.171.12461
Screen shot of non-repaint
First, some comments about your command line:
set XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION=1024x768will not be forwarded to the server start command and therefore it will not be honoured, instead use
xpra start-desktop --env=XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION=1024x768 ...
firstname.lastname@example.org:22/100the correct syntax is
:22is optional since that is the default ssh port
--speed=80- usually a bad idea,
--min-speed=80is more likely to be what you want, and since you're setting a fairly high
min-qualityof 80, this is probably counter-productive as it doesn't leave enough room for maneuver
--clipboard-direction=both- those values are the default, so specifying those options has no effect
When I exit from an app, say Konsole, the screen doesn't repaint so the last app output remains visible.
Is there anything in your server log? Or even in the console if you use
xpra_cmd.exe to run it.
Does it work any better if you turn off (or on?) opengl in the client? (either
--opengl=on or via the system tray at runtime)
I got fooled making multiple changes at once. My attempt to set resolution really wasn't working. I haven't gotten resolution setting to work with start-desktop. I'm not sure if it should be --env=... or --start-env, and in one of the config files I see a similar variable XPRA_DEFAULT_VFB_RESOLUTION setting commented out. I've tried various combinations on the Windows command line and in ~/.xpra/xpra.conf. (I'm not having much luck with XPRA_SYNC_ICC=0 either. I think I had it working briefly, then it failed and I'm not sure why.)
I think the ssh format I used was right back around version 2.5. I specify the port because I use a non-standard port when coming in from the outside.
I played with speed and quality when my remote desktop sessions weren't updating as fast as I would like, but I think that is no longer a problem. I changed to only specifying min-quality, and only on a local GB connection.
There were some builds with clipboard problems, since fixed. I now am not setting those default values.
Opengl breaks things for both start and start-desktop if I turn it on under Windows 7. It has no obvious effect under Windows 10. I'm not sure what debug options I should enable.
I'm not sure if it should be --env=... or --start-env,
It should be
start-env= is only used for commands we start with
and in one of the config files I see a similar variable XPRA_DEFAULT_VFB_RESOLUTION setting commented out
That's the default resolution for seamless mode. r24540 adds an example for desktop mode in that same file.
This works fine for me:
xpra start-desktop ssh://localhost/ --start=xterm --env=XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION=1024x768
Gives me a 1024x768 desktop session.
r24541 also adds logging so we can see the desktop resolution in the server log file:
xpra GTK3 X11 desktop version 4.0-r24395 64-bit uid=XXXX (UUUUUUU), gid=XXXX (UUUUUUUU) running with pid 27417 on Linux Fedora 31 ThirtyOne connected to X11 display :2 with 24 bit colors initial resolution: 1024x768 :2.0 (270x203 mm - DPI: 96x96) monitor 2
I'm not having much luck with XPRA_SYNC_ICC=0 either.
Works fine here, r24539 makes it easier to see if colourspace synchronization is enabled or not, and if enabled what profile is in use:
$ xpra info | grep display.icc display.icc.profile= display.icc.sync=True
If I start my server via ssh with
xpra start ssh://localhost/ --start=xterm --env=XPRA_SYNC_ICC=0
Then it will show that synchronization is disabled:
$ xpra info | grep -i display.icc display.icc.sync=False
But then it occurred to me that when xpra is setting the ICC X11 properties on the virtual display, it isn't going to involve polkit directly (this whole colourspace sync was originally discussed here: start-desktop with Fedora KDE Plasma) and so colord may well get its data from other sources (gnome-settings-daemon? xsettings / xresources?).
See How does colord interface with the session?.
So I may have to reproduce the problem myself to make sure that we filter out the color profile data everywhere, and not just the X11 property
I think the ssh format I used was right back around version 2.5
The format you use is the original one, and it still works OK, it has been supported for the last 10 years. It's just better to move towards the more standard URL syntax that we can parse with standard libraries, the older format will be dropped eventually.
Opengl breaks things for both start and start-desktop if I turn it on under Windows 7
PS: all those commands were run on Linux locally, I don't expect a different platform (ie: mswindows) to handle those command line options differently, but I will verify that anyway - just in case.
I've been fighting with this for a while, and results just aren't consistent when I change options on either side. Perhaps I've found a clue. I just noticed in logwatch output that I had multiple traps in python3. Looking at /var/log/messages, I see traps in libglib and unhandled python exceptions in /usr/bin/xpra. Is it possible for parts of the setup to fail, yet the connection gets made? That could explain what I'm seeing.
I see traps in libglib and unhandled python exceptions in /usr/bin/xpra
Can you please post the details? Especially the python backtraces.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2497