Xpra: Ticket #2497: Screen doesn't refresh when app closes with start-desktop

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
  ssh/redacted@10.0.0.16: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 4.0.0.24461



Thu, 28 Nov 2019 05:47:13 GMT - Bob Babcock: attachment set

Screen shot of non-repaint


Thu, 28 Nov 2019 08:24:15 GMT - Antoine Martin: owner, description changed

First, some comments about your command line:


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)


Sat, 30 Nov 2019 07:44:10 GMT - Bob Babcock:

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.

Currently running 4.0-r24461 on Windows, v4.0-r24529 on Fedora 31.


Sat, 30 Nov 2019 16:38:46 GMT - Antoine Martin:

I'm not sure if it should be --env=... or --start-env,

It should be --env=, ie: --env=XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION=640x640 start-env= is only used for commands we start with --start=, --start-child, etc..

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_SYNC_ICC=0:

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

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

Oh! How so? Visual corruption, slow refresh (#2481), see-through windows (#2466), or something else? Is that still true with the latest builds? (works fine here with an nvidia card and windows7)

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.


Tue, 03 Dec 2019 07:10:50 GMT - Bob Babcock:

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.


Tue, 03 Dec 2019 08:50:21 GMT - Antoine Martin:

I see traps in libglib and unhandled python exceptions in /usr/bin/xpra

Can you please post the details? Especially the python backtraces.


Thu, 06 Feb 2020 08:57:50 GMT - Antoine Martin:

Bump!


Wed, 12 Feb 2020 05:24:30 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 05:52:54 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2497