Screen doesn't refresh when app closes with start-desktop

[totaam]

Issue migrated from trac ticket # 2497

component: client | priority: minor | resolution: needinfo

2019-11-28 05:46:18: wssddc created the issue

---

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-24387
Windows version is 4.0.0.24461

[totaam]

2019-11-28 05:47:14: wssddc uploaded file xpra-no-repaint.gif (56.9 KiB)

Screen shot of non-repaint

[totaam]

2019-11-28 08:24:15: antoine changed owner from antoine to wssddc

[totaam]

2019-11-28 08:24:15: antoine edited the issue description

[totaam]

2019-11-28 08:24:15: antoine commented

---

First, some comments about your command line:

• set XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION=1024x768 will 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 ...
• ssh/redacted@10.0.0.16:22/100 the correct syntax is ssh://redacted@10.0.0.16:22/100 and :22 is optional since that is the default ssh port
• --speed=80 - usually a bad idea, --min-speed=80 is more likely to be what you want, and since you're setting a fairly high min-quality of 80, this is probably counter-productive as it doesn't leave enough room for maneuver
• --clipboard=yes and --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)

[totaam]

2019-11-30 07:44:11: wssddc commented

---

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-24529 on Fedora 31.

[totaam]

2019-11-30 16:38:47: antoine commented

---

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](../commit/12f87951af2bde34992a8a551209dc45d6809e1e) 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 colord: How it works and colord FAQ - in particular: 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.

[totaam]

2019-12-03 07:10:51: wssddc commented

---

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.

[totaam]

2019-12-03 08:50:22: antoine commented

---

I see traps in libglib and unhandled python exceptions in /usr/bin/xpra
Can you please post the details?
Especially the python backtraces.

[totaam]

2020-02-06 08:57:50: antoine commented

---

Bump!

[totaam]

2020-02-12 05:24:30: antoine changed status from new to closed

[totaam]

2020-02-12 05:24:30: antoine set resolution to needinfo