start-desktop --use-display: wrong display size

[totaam]

Issue migrated from trac ticket # 1656

component: client | priority: major | resolution: fixed

2017-10-07 22:42:11: mviereck created the issue

---

System: debian 9 with xpra v2.1.2-16903

If using an already running X server with --start-desktop --use-display, the appearing desktop window size does not match the size of the X server. Example:

Xephyr :5
DISPLAY=:5 lxsession
xpra start-desktop :5 --use-display --start-via-proxy=no
xpra attach :5

xpra tries to change resolutions, but the results does not match (X server vs. xpra desktop window). I would rather expect xpra not to change the resolutions at all. Instead, the xpra client window should match the resolution of the attached X server.

(Curiously, option --desktop-scaling=1.1 changes this behaviour in some cases. The scale factor must not be an integer. This is not the case for this Xephyr example, but happens to my Xdummy setups with x11docker. Example:)

# mismatching screen size and/or OpenGL issues:
x11docker --xpra --desktop --exe lxsession
# works fine:
x11docker --xpra --desktop --exe lxsession --scale 1.1

[totaam]

2017-10-07 22:45:49: mviereck changed component from android to client

[totaam]

2017-10-08 06:48:37: antoine changed owner from antoine to mviereck

[totaam]

2017-10-08 06:48:37: antoine commented

---

fixed in r17117, please close if that works for you.

[totaam]

2017-10-08 15:13:11: mviereck commented

---

Thank you!
I will check it as soon as it appears in your debian beta repository. The latest one is currently r17112.

[totaam]

2017-10-08 20:24:25: antoine commented

---

r17117 builds posted.

[totaam]

2017-10-08 21:22:35: mviereck commented

---

I did some tests and so far, all works fine!

One minor bug: If the maximal size of the attached X server is smaller than the client display, and I try to enlarge the client desktop window, it does not work. That is good so far as it would cause RAM failures otherwise. But the server log shows a bug. Example for an X server with maximum size 800x600:

2017-10-08 21:59:55,567  XError: BadMatch
2017-10-08 21:59:55,567 Warning: no matching resolution found for 906x603
2017-10-08 21:59:55,568  using 318x(800, 600) instead
2017-10-08 21:59:55,568 ouch, failed to set new resolution: %d format: a number is required, not tuple
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/x11/x11_server_core.py", line 607, in set_screen_size
    RandR.set_screen_size(w, h)
  File "xpra/x11/bindings/randr_bindings.pyx", line 289, in xpra.x11.bindings.randr_bindings._RandRBindings.set_screen_size (xpra/x11/bindings/randr_bindings.c:3950)
  File "xpra/x11/bindings/randr_bindings.pyx", line 207, in xpra.x11.bindings.randr_bindings._RandRBindings._set_screen_size (xpra/x11/bindings/randr_bindings.c:2412)
TypeError: %d format: a number is required, not tuple

It seems xpra tries to set the maximum of 800x600 as the best choice, but failes with a wrong parameter (tuple) format.

Creating smaller screen sizes works like a charm. Maximizing and de-maximizing the client window causes some mismatches, but that may be solved if xpra can handle the maximum screen size.

[totaam]

2017-10-09 05:39:30: antoine commented

---

The code searching for the closest match was buggy (318x(800, 600) is not a resolution!), r17118 + r17119 should fix that.
Can you try the latest build and report back?

[totaam]

2017-10-09 11:10:17: mviereck commented

---

Works fine: startup

2017-10-09 11:45:02,335 client 1: server does not support xi input devices
2017-10-09 11:45:02,336 client 1:  server uses: xtest
2017-10-09 11:45:02,496 New unix-domain connection received on /run/user/1000/xpra/debian9-102
2017-10-09 11:45:02,497 New unix-domain connection received on /home/lauscher/.xpra/debian9-102
2017-10-09 11:45:02,520 New unix-domain connection received on /run/xpra/debian9-102
2017-10-09 11:45:02,707 cannot find a temporary resolution for Xinerama workaround!
2017-10-09 11:45:02,716 server virtual display now set to 800x600
2017-10-09 11:45:02,719 DPI set to 96 x 96
2017-10-09 11:45:05,401 best resolution matching 800x600 is unchanged: 800x600
2017-10-09 11:45:05,713 best resolution matching 800x600 is unchanged: 800x600

Works fine: setting smaller resolutions (smaller client window)

2017-10-09 11:45:47,607 server virtual display now set to 564x429 (best match for 561x429)
2017-10-09 11:45:47,622 DPI set to 96 x 96
2017-10-09 11:45:47,872 best resolution matching 564x429 is unchanged: 564x429

Works fine: snapping back to greatest possible resolution (making client window too big). (But xrandr still shows this too-big resolution as available).

2017-10-09 11:46:16,191 Warning: failed to add resolution 1017x665:
2017-10-09 11:46:16,191  XError: BadMatch
2017-10-09 11:46:16,192 Warning: no matching resolution found for 1017x665
2017-10-09 11:46:16,192  using 800x600 instead
2017-10-09 11:46:16,208 server virtual display now set to 800x600 (best match for 1017x665)
2017-10-09 11:46:16,257 DPI set to 96 x 96
2017-10-09 11:46:16,986 Warning: failed to add resolution 1273x791:
2017-10-09 11:46:16,987  XError: BadMatch
2017-10-09 11:46:16,987 Warning: no matching resolution found for 1273x791
2017-10-09 11:46:16,987  using 800x600 instead
2017-10-09 11:46:16,987 best resolution matching 1273x791 is unchanged: 800x600
2017-10-09 11:46:17,268 best resolution matching 800x600 is unchanged: 800x600

Maximizing client window (window manager xfwm4): Window maximizes, desktop appears at center, content is not refreshed well. Strange "2" in logfile. Clicking around or disabling/enabling OpenGL fixes this:

2017-10-09 11:48:44,712 Warning: failed to add resolution 1871x1019:
2
 017-10-09 11:48:44,713  XError: BadMatch
2017-10-09 11:48:44,713 Warning: no matching resolution found for 1871x1019
2017-10-09 11:48:44,713  using 800x600 instead
2017-10-09 11:48:44,714 best resolution matching 1871x1019 is unchanged: 800x600

De-maximizing client window: Unusable result. Desktop is misplaced, mouse events does not match display. Disabling and re-enabling OpenGL fixes that.

2017-10-09 11:52:31,815 best resolution matching 800x600 is unchanged: 800x600

[totaam]

2017-10-09 11:44:56: mviereck commented

---

Sorry, strange "2" in logfile may be my failure in my own logfile creation.

Tested with xpra v2.2-r17120 on debian 9.

[totaam]

2017-10-09 13:02:28: mviereck commented

---

Additional: Xwayland issues
Using Xwayland (800x600) as attached X server, there are similar issues with maximizing/demaximizing client window. The desktop appears at 0:0 instead of center of client window. I have to refresh the output in both cases (maximized/de-maximized). But the desktop is not misplaced after demaximizing as it stayes at 0:0.

Xwayland is a bit itchy with xrandr. It seems to allow custom resolution modes without error feedback, but does not applicate them. The display size of Xwayland cannot be changed.

Startup with Xwayland is fine:

2017-10-09 13:53:10,762 client 1: server does not support xi input devices
2017-10-09 13:53:10,762 client 1:  server uses: xtest
2017-10-09 13:53:10,915 New unix-domain connection received on /run/user/1000/xpra/debian9-104
2017-10-09 13:53:10,917 New unix-domain connection received on /home/lauscher/.xpra/debian9-104
2017-10-09 13:53:10,931 New unix-domain connection received on /run/xpra/debian9-104
2017-10-09 13:53:11,155 cannot find a temporary resolution for Xinerama workaround!
2017-10-09 13:53:11,156 server virtual display now set to 800x600
2017-10-09 13:53:11,157 DPI set to 96 x 96

Making client window smaller. The window is smaller, but the desktop is only partially visible. Maybe xpra should check which resolution is really at work after xrandr settings are done. The logfile shows some nonsense values:

2017-10-09 13:53:45,071 best resolution matching 800x600 is unchanged: 800x600
2017-10-09 13:53:45,540 best resolution matching 800x600 is unchanged: 800x600
2017-10-09 13:53:45,816 best resolution matching 800x600 is unchanged: 800x600
2017-10-09 13:54:07,849 Error: failed to set new screen size
2017-10-09 13:54:07,852 Warning: tried to set resolution to 532x416
2017-10-09 13:54:07,852  and ended up with 785x0
2017-10-09 13:54:07,862 DPI set to 94 x 0 (wanted 96 x 96)
2017-10-09 13:54:07,862  you may experience scaling problems, such as huge or small fonts, etc
2017-10-09 13:54:07,863  to fix this issue, try the dpi switch, or use a patched Xorg dummy driver
2017-10-09 13:54:08,113 Warning: failed to add resolution 531x416:
2017-10-09 13:54:08,114  XError: BadName
2017-10-09 13:54:08,114 Warning: no matching resolution found for 531x416
2017-10-09 13:54:08,114 best resolution matching 531x416 is unchanged: 800x600

Resizing window greater than 800x600 works fine, the window snaps to 800x600. Still some strange logfile values:

2017-10-09 13:56:14,784 Warning: failed to add resolution 531x416:
2017-10-09 13:56:14,784  XError: BadName
2017-10-09 13:56:14,784 Warning: no matching resolution found for 531x416
2017-10-09 13:56:14,784 best resolution matching 531x416 is unchanged: 800x600
2017-10-09 13:56:15,087 Warning: failed to add resolution 531x416:
2017-10-09 13:56:15,087  XError: BadName
2017-10-09 13:56:15,088 Warning: no matching resolution found for 531x416
2017-10-09 13:56:15,088 best resolution matching 531x416 is unchanged: 800x600
2017-10-09 13:56:15,341 Warning: failed to add resolution 531x416:
2017-10-09 13:56:15,342  XError: BadName
2017-10-09 13:56:15,342 Warning: no matching resolution found for 531x416
2017-10-09 13:56:15,342 best resolution matching 531x416 is unchanged: 800x600
2017-10-09 13:56:15,594 Warning: failed to add resolution 531x416:
2017-10-09 13:56:15,595  XError: BadName
2017-10-09 13:56:15,595 Warning: no matching resolution found for 531x416
2017-10-09 13:56:15,595 best resolution matching 531x416 is unchanged: 800x600
2017-10-09 13:56:19,937 Error: size not found for 956x688
2017-10-09 13:56:19,937 Warning: tried to set resolution to 956x688
2017-10-09 13:56:19,938  and ended up with 785x0
2017-10-09 13:56:19,970 DPI set to 94 x 0 (wanted 96 x 96)
2017-10-09 13:56:19,970  you may experience scaling problems, such as huge or small fonts, etc
2017-10-09 13:56:19,970  to fix this issue, try the dpi switch, or use a patched Xorg dummy driver
2017-10-09 13:56:20,707 Error: size not found for 1300x865
2017-10-09 13:56:20,707 Warning: tried to set resolution to 1300x865
2017-10-09 13:56:20,708  and ended up with 49x0
2017-10-09 13:56:20,710 DPI set to 6 x 0 (wanted 96 x 96)
2017-10-09 13:56:20,710  you may experience scaling problems, such as huge or small fonts, etc
2017-10-09 13:56:20,710  to fix this issue, try the dpi switch, or use a patched Xorg dummy driver
2017-10-09 13:56:20,982 Warning: failed to add resolution 800x600:
2017-10-09 13:56:20,983  XError: BadName
2017-10-09 13:56:20,984 Warning: no matching resolution found for 800x600
2017-10-09 13:56:20,984 best resolution matching 800x600 is unchanged: 800x600

[totaam]

2017-10-09 13:09:14: mviereck commented

---

Note: Xwayland display size cannot be changed with xrandr at all. It has nothing to do with xpra. Same for dpi values, Xwayland does not accept changes.

[totaam]

2017-10-09 17:26:48: antoine commented

---

Using Xephyr as vfb is not a supported configuration, so I am not sure all these issues can be fixed. Why are you so interested in using Xephyr instead of Xvfb?

best resolution matching 800x600 is unchanged: 800x600
FYI: as of r17133, this won't be logged anymore unless the window is actually resized and not just moved, I was finding that a little bit confusing.

content is not refreshed well.
Please clarify, works ok-ish here: only the first frame is slightly off, but it refreshes almost immediately. (will try to fix)

De-maximizing client window: Unusable result. Desktop is misplaced..
Confirmed, will fix. The content offsets should be re-adjusted.

This one is weird:

Warning: tried to set resolution to 532x416
 and ended up with 785x0

The values shown there are straight from randr API, via XRRGetScreenInfo. r17135 tries harder to validate those values.
If randr returns nonsensical values, there's not much we can do. How can I reproduce this reliably?

Maybe xpra should check which resolution is really at work after xrandr settings are done.
That's exactly what it does and why you see messages like this one: Warning: tried to set resolution to... and ended up with

Wayland should not be making too much difference as this is all client side and we are somewhat shielded from it by the window manager and Xwayland.

[totaam]

2017-10-09 20:51:07: mviereck commented

---

Using Xephyr as vfb is not a supported configuration
I don't use Xephyr in normal cases, it was just an easy and visible example for the first posting showing the different display sizes of X server and xpra client window.
Most times I am using Xvfb or Xdummy. If I want GPU acceleration, I am using Xwayland as virtual frame buffer.
In that case, with Xwayland as invisible frame buffer, I get the strange logfile values noted in comment 9.
Wayland should not be making too much difference as this is all client side and we are somewhat shielded from it by the window manager and Xwayland.
Some misunderstanding: it is about Xwayland as virtual frame buffer. My regular desktop is Xfce and not wayland-related.

The values shown there are straight from randr API, via ​XRRGetScreenInfo. r17135 tries harder to validate those values.
If randr returns nonsensical values, there's not much we can do. How can I reproduce this reliably?
Sample setup with Xwayland as virtual frame buffer:

weston --no-config --socket=wayland-30
export WAYLAND_DISPLAY=wayland-30
Xwayland :30 -noreset
export XPRA_OPENGL_DOUBLE_BUFFERED=1
xpra start-desktop :30 --use-display --start-via-proxy=no
xpra attach :30
DISPLAY=:30 lxsession # LXDE desktop

Resizing this client with LXDE desktop leads to the strange values of comment 9. xrandr still shows the right resolution.
The same setup with x11docker (showing xpra logfile, too) is x11docker --xpra-xwayland --desktop --verbose --exe lxsession.

content is not refreshed well.
Please clarify, works ok-ish here: only the first frame is slightly off, but it refreshes almost immediately. (will try to fix)
I have to re-check this; sometimes the desktop is redrawn immediatly, sometimes it stays black until I do some actions/mouse events to redraw parts of the desktop or all of it.

[totaam]

2017-10-10 09:33:09: antoine commented

---

Sample setup with Xwayland as virtual frame buffer:
Having the exact command lines to use makes a huge difference, I get it now.
The values were completely bogus, dereferencing an invalid pointer from an array of size zero...
r17140 detects Xwayland (or any other vfb without usable randr support) and will not allow the window to be resized.
For older versions, we now just bail out: 17141.

There's probably still a bug in xpra when the window is somehow resized anyway (the size constraints are only hints and the window managers can still overrule them), but since it should no longer be possible to trigger this particular bug using a regular setup, can we close this ticket?

export XPRA_OPENGL_DOUBLE_BUFFERED=1
Why do you set this option? It should be the default on all supported platforms.
(and only affects the client)

DISPLAY=:30 lxsession
Always use xpra start --start=lxsession instead, to ensure that the environment is correct and that the command doesn't die if the terminal it is started from does.

[totaam]

2017-10-10 16:56:25: mviereck commented

---

r17140 detects Xwayland (or any other vfb without usable randr support) and will not allow the window to be resized.
This works fine so far, except for maximized windows, see below.
There's probably still a bug in xpra when the window is somehow resized anyway (the size constraints are only hints and the window managers can still overrule them), but since it should no longer be possible to trigger this particular bug using a regular setup, can we close this ticket?

We can close the ticket if you like to; the bug appears only if the vfb X server is smaller than the client window and cannot be enlarged, a rather special case. Maximizing windows enforces the bug to appear, and tiling window managers likely, too.

export XPRA_OPENGL_DOUBLE_BUFFERED=1
Why do you set this option?
Sorry, not needed actually; it is a relict from ticket #1469, I always set this for backwards compatibility.

Always use xpra start --start=lxsession instead, to ensure that the environment is correct
I am using xpra to run GUI applications in docker containers; xpra can not set environment variables inside a container on its own. I could do that myself. Is there a straightforward way to find out which environment variables xpra would set? Comparing the output of env showes me some differences, but I am not sure if they are all from xpra and if they may change, and I did not find them on https://www.xpra.org/trac/wiki/Usage/EnvironmentOptions :

MWWM=allwm
DISABLE_IMSETTINGS=1
QT_X11_NO_NATIVE_MENUBAR=1
CKCON_X11_DISPLAY=:100
UBUNTU_MENUPROXY=
MWNO_RIT=true
GTK_IM_MODULE=xim
_=/usr/bin/xpra
MWNOCAPTURE=true
GDK_BACKEND=x11
DISPLAY=:100
XAUTHORITY=/home/lauscher/.cache/x11docker/X100-wine-Xpra/share/Xclientcookie
XMODIFIERS=@im=none
QT_IM_MODULE=xim
IMSETTINGS_MODULE=none

content is not refreshed well.
Please clarify, works ok-ish here: only the first frame is slightly off, but it refreshes almost immediately. (will try to fix)
I have to re-check this; sometimes the desktop is redrawn immediatly, sometimes it stays black until I do some actions/mouse events to redraw parts of the desktop or all of it.
Both following issues can be fixed with disabling and enabling OpenGL:
Maximized window not refreshed well, 800x600 desktop in the center:
http://up.picr.de/30610088rs.jpg
De-maximized window, misplaced desktop, mouse events do not match:
http://up.picr.de/30610089fd.jpg
It could be good to have an obvious "refresh" option in xpra tray menu.

[totaam]

2017-10-10 17:30:09: mviereck commented

---

Always use xpra start --start=lxsession instead, to ensure that the environment is correct
I just found in xpra -h:

'UBUNTU_MENUPROXY='
'QT_X11_NO_NATIVE_MENUBAR=1',
'MWNOCAPTURE=true'
'MWNO_RIT=true'
'MWWM=allwm'
'GDK_BACKEND=x11'

Is everything well if I just set this myself in container environment?

[totaam]

2017-10-10 17:43:42: antoine commented

---

This works fine so far, except for maximized windows, see below.
I believe that this case has now also been fixed in r17150. Works for me with Xephyr. (this change has been backported to older branches in 17151)
If that works for you and this is the last issue, please close the ticket.

xpra can not set environment variables inside a container on its own
I'm not 100% sure what you mean here.
You can tell xpra to set environment variables, see --env=KEY=VALUE and --start-env=.
You can view the default values it will be using for child processes with xpra showconfig.

If you cannot use --start=child, then you can just set them yourself. (and bear in mind that more may be added in the future)

[totaam]

2017-10-10 22:47:13: mviereck changed status from new to closed

[totaam]

2017-10-10 22:47:13: mviereck set resolution to fixed

[totaam]

2017-10-10 22:47:13: mviereck commented

---

I believe that this case has now also been fixed in r17150.
I still have xpra v2.2-r17140 and cannot test r17150 now. I will check as soon as it appears in debian beta repository, and report back if there is still an issue. So far, I will close this ticket.
I'm not 100% sure what you mean here. You can tell xpra to set environment variables
That's just about docker, it isolates applications from the host similar to a virtual machine. I cannot set variables or start applications directly, I have to do that inside the isolated container. xpra runs on the host, but the applications in the container, and their only common workplace is the X server.
You can view the default values it will be using for child processes with xpra showconfig.
I am now parsing xpra showconfig, thank you! It is a bit tricky as the comment values contain special chars , and ', but I made it.

Thanks for your great work!

[totaam]

2017-10-10 23:21:01: mviereck commented

---

By the way, r17140 shows an error message, even on xpra --version:
Warning: invalid optio2n: 'shadow-fullscreen'
Maybe it is already fixed in r17150.

[totaam]

2017-10-11 05:18:22: antoine commented

---

Warning: invalid optio2n: 'shadow-fullscreen'
You must have an old configuration file laying around.
This value is not present anywhere in the source tree.

PS: new beta posted.

[totaam]

2017-10-11 19:34:16: mviereck commented

---

You must have an old configuration file laying around.
You are right; I did some compatibility tests with older xpra versions and got and outdated config file.
PS: new beta posted.
Still r17140 here ...

I found different behaviour between Xvfb and Xdummy. While I can change the client window seamless to arbitrary sizes in Xvfb, I am bound to already defined modes in Xdummy. The client window snaps to the nearest matching size already defined/visible in xrandr. Though, Xdummy accepts custom arbitrary sizes/new xrandr modes and could be seamless like Xvfb. Not a problem, just less flexible behaviour than with Xvfb.

[totaam]

2017-10-11 19:43:05: antoine commented

---

Still r17140 here ...
Try again now.

I am bound to already defined modes in Xdummy
That's a know limitation of Xdummy, see #56 for details.

[totaam]

2017-10-11 21:44:24: mviereck commented

---

Now with 17160:
Two issues with too-small X servers:

Minor issue: maximizing and minimizing multiple times can lead to frame fragments in the black area around the desktop in maximized window. Example:
http://up.picr.de/30620549hp.jpg
(Also, mouse clicks in the black area cause mouse events at the edge of the desktop. Not a problem, only a bit irritating.)

Major issue: de-maximizing still leads to misplaced desktop and mismatching mouse events, like mentioned above: http://up.picr.de/30610089fd.jpg
This may be resolved if the desktop is always placed at 0:0 of the client window instead of being centered. Changing the client window size fixes this.

I have tested with three window managers (xfwm4, kwin, openbox), everywhere the same results.

Maybe I am nitpicking, I hope you don't mind. ;-)

[totaam]

2017-10-11 23:09:44: mviereck commented

---

Another minor issue: With Xdummy providing display sizes smaller and greater than a maximized window, and I maximize xpra client window, xpra chooses a display size greater than the maximized client window. The egdes of the desktop become hidden as it is too big to be shown completly. xpra should rather choose the next smaller display size.

[totaam]

2017-10-12 16:25:00: antoine commented

---

Some of the maximizing issues you encountered may have required specific client and vfb screen sizes to hit, so I am not 100% this is all fixed, but r17164 fixes the ones I managed to reproduce.
If you still hit some problems, please include the "-d randr,geometry,screen" debug output of both client and server.

xpra should rather choose the next smaller display size.
r17165 does that (this might have been a regression caused by some refactoring).

I am not sure if these two fixes will be backported.

Do you mind creating a new ticket about the clamping of clicks to the edge of the desktop? This one could turn out to be a bit tricky to get right and may well end up interfering with seamless mode (in some cases, applications could see the pointer lingering over the edge of the window - which could trigger unwanted behaviour)

[totaam]

2017-10-12 18:47:14: mviereck uploaded file xpraserver.log (21.0 KiB)

[totaam]

2017-10-12 18:47:41: mviereck uploaded file xpraclient.log (9.5 KiB)

[totaam]

2017-10-12 18:49:54: mviereck commented

---

Do you mind creating a new ticket about the clamping of clicks to the edge of the desktop?
Ok, I will do.

With r17165, most things work quite well, and I always get a usable, full visible and well redrawn desktop regardless of my attacks against the client window.

Still remaining: maximizing and de-maximizing multiple times sometimes leads to fragments in the black area around the desktop. It may be due to the palinopsia bug: https://security.stackexchange.com/questions/123756/how-to-mitigate-risk-of-x11-buffer-ghosting-palinopsia-bug

Screenshot with fragments belonging to attached logfiles: http://up.picr.de/30625975rm.jpg

I had to maximize about 5 times until I get the fragments. I made screenshot and logfile copies immediatly after appearing of fragments.

[totaam]

2017-10-13 15:57:54: antoine commented

---

r17167 should now repaint the padding around the central paint area.
This code only runs when we have an offset, which happens mostly when running desktop mode with fullscreen or maximized windows.

You can change which colour is used for painting it (useful for testing) with XPRA_PADDING_COLORS=R,G,B, ie::

XPRA_PADDING_COLORS=0,0.2,1 xpra attach

New beta posted.

Looks like the changes in r17164 caused a regression: #1659.

[totaam]

2017-10-13 20:50:26: mviereck commented

---

r17167 should now repaint the padding around the central paint area.
I am a bit confused:

• The current xpra debian package name ends with r17168, but xpra --version shows xpra v2.2-17160.
• Setting XPRA_PADDING_COLORS=0,0.2,1 has no effect.
• Sometimes I still get fragments in the black area.

Maybe something went wrong in packaging?

[totaam]

2017-10-15 12:13:23: antoine commented

---

The current xpra debian package name ends with r17168, but xpra --version shows xpra v2.2-17160.
I must have misconfigured the buildbot, sorry.

Setting XPRA_PADDING_COLORS=0,0.2,1 has no effect.
Just tested in a Stretch VM without opengl, and I do see the colors I set.
(just by updating using the beta repo)

Sometimes I still get fragments in the black area.
Then maybe you're not really running r17167 or later then.
There are newer beta builds now.

The regression has been fixed: #1659#comment:4.