Start-desktop initial connection offset paints when using xrandr to resize display on start

totaam commented 6 years ago

Issue migrated from trac ticket # 1967

component: server | priority: minor

2018-09-21 18:46:53: maxmylyn created the issue

Found a minor bug while working on the automated tests. My server and client are both Fedora 28 machines running trunk r20495.

In order to run into this issue, you have to start a server and use xrandr as a start option to resize the display as so:

xpra start-desktop --bind-tcp=0.0.0.0:2200 --start="xrandr -s 1920x1080" --start=xterm

Upon initial connection with xpra attach ssh:user@host, the xterm will appear above the top of the session window. If you disconnect and reconnect, the Xterm appears at the top of the window as it should. I'll attach screenshots to demonstrate what I'm seeing. Alternatively, you can add --start=i3 to the start command, and the bottom bar appears above where it should be on the first connection; it makes it more obvious what's going on.

Unfortunately, I have no idea what -d logs I should be getting.

totaam commented 6 years ago

2018-09-21 18:48:20: maxmylyn uploaded file `1967 initial connection.png` (20.5 KiB)

Screenshot of the initial connection 1967 initial connection.png

totaam commented 6 years ago

2018-09-21 18:48:42: maxmylyn uploaded file `1967 second connection.png` (21.0 KiB)

After disconnecting and re-attaching 1967 second connection.png

totaam commented 6 years ago

2018-09-22 07:43:59: antoine uploaded file `1967 i3.jpg` (69.3 KiB)

third screenshot with i3 running to show the offset more clearly (replacing with a more reasonable file size) 1967 i3.jpg

totaam commented 6 years ago

I cannot reproduce anywhere
does the resolution used with xrandr matter?
does the application started make any difference?
can you reproduce locally? (without ssh)
have you tried the usual debugging steps: starting without opengl, etc?
does it occur with other platforms? other versions?

Since we're capturing the whole screen as one buffer in desktop mode, if this is a bug in xpra then it is likely to be client side.

totaam commented 6 years ago

2018-09-26 17:55:44: maxmylyn commented

To answer your questions up front:

Resolution doesn't matter as far as I can tell, it will be offset if you do 1080p or 1440p or 1600x900.
Application started makes no difference
Yes, I can reproduce it locally
I should have thought of that first, sorry I didn't. Turns out OpenGL is the culprit.

If I start and attach with OpenGL disabled, it works fine on the initial connection. If I start and attach with OpenGL enabled, that's where I see the offset. I'll retry this with -d opengl,paint logs running; the initial connection and the second connection where it shows up properly.

For good measure, I'll also attach -d paint when attaching without OpenGL for a comparison to a working case.

Shouldn't take me more than a few minutes.

totaam commented 6 years ago

2018-09-26 17:57:48: maxmylyn uploaded file `1967dopenglpaintinitial.log` (49.2 KiB)

-d opengl,paint logs of the initial connection.

totaam commented 6 years ago

2018-09-26 17:58:06: maxmylyn uploaded file `1967dopenglpaintsecond.log` (46.8 KiB)

-d opengl,paint logs of the second connection (same session)

totaam commented 6 years ago

2018-09-26 17:58:48: maxmylyn uploaded file `1967dpaintnoopengl.log` (5.5 KiB)

-d paint logs of a different session, with a working initial connection

totaam commented 6 years ago

2018-09-26 18:06:56: maxmylyn changed owner from maxmylyn to antoine

totaam commented 6 years ago

2018-09-26 18:06:56: maxmylyn commented

I retested this with a local setup - Fedora 28 workstation running trunk r20535.

I started a session with xpra start-desktop :13 --start="xrandr -s 1920x1080" --start=xterm and attached with xpra attach :13 (and also with --opengl=no). Even connecting locally, I still see the offset.

It's pretty straightforward to trigger for me, but I should mention an important caveat:

My workstation has an Nvidia GTX 745, so I think that may be a contributing factor. In my experience, a lot of OpenGL weirdness usually stems from the Nvidia driver - my laptop has an Intel Iris Pro + Nvidia GTX 850 and the Primus bridge means the GPU is disabled 99% of the time, and I never seem to run into nearly as many OpenGL oddities as I do with my other machines that only use the Nvidia card. Of course, all of the mentioned machines run Fedora.

In the meantime, I'll play around with it a little bit and try a few more xrandr resolutions.

totaam commented 6 years ago

I still cannot reproduce.

what nvidia driver version do you have installed? does updating to the latest version fix things?
does it fix things if you use the "refresh windows" from the systray menu? what about "re-initialize"?
minimize then restore it?
please capture "xpra info" before and after the first connection
please attach the "-d metadata" client log output for the first and second connection attempts

totaam commented 6 years ago

2018-09-27 17:32:23: maxmylyn commented

To answer your questions:

Currently running the 396.45 - I'm upgrading as we speak, but I have a large number of updates.
Refresh Windows does nothing, but re-initialize did put me into a weird state where the everything is kinda...squished? I'll attach a screenshot to demonstrate what I'm seeing. After doing that, I ran xrandr --listmonitors and this is the output:

[max@vorfuehreffekt ~] $ xrandr --listmonitors
xrandr: Failed to get size of gamma for output default
Monitors: 1
 0: +default 1920/508x1024/271+0+0  default

As you can see, it lowered the virtual display's resolution from 1920x1080 -> 1920x1024, which about matches with the ~60 or so pixels missing from the bottom.

Minimize / restore does nothing - I tried that before hoping it would help, but it doesn't.

I'll retry and get the xpra info and -d metadata momentarily.

In the meantime, both my client and server have been updated to r20536.

totaam commented 6 years ago

2018-09-27 17:32:50: maxmylyn uploaded file `1967 reinitialize.png` (59.8 KiB)

after clicking re-initialize from the systray 1967 reinitialize.png

totaam commented 6 years ago

2018-09-27 18:47:01: maxmylyn uploaded file `1967infobeforeconnect.txt` (56.3 KiB)

Xpra info before connection

totaam commented 6 years ago

2018-09-27 18:47:22: maxmylyn uploaded file `1967infoafterconnect.txt` (97.3 KiB)

Xpra info after first connection

totaam commented 6 years ago

2018-09-27 18:47:57: maxmylyn uploaded file `1967infofinal.txt` (97.3 KiB)

Xpra info after second connection disconnects

totaam commented 6 years ago

2018-09-27 18:48:15: maxmylyn uploaded file `1967dmetadatafirst.log` (3.6 KiB)

-d metadata of initial client connection (with offset)

totaam commented 6 years ago

2018-09-27 18:48:34: maxmylyn uploaded file `1967dmetadatasecond.log` (3.7 KiB)

-d metadata of second client connection (without offset)

totaam commented 6 years ago

2018-09-27 18:49:54: maxmylyn changed owner from maxmylyn to antoine

totaam commented 6 years ago

2018-09-27 18:49:54: maxmylyn commented

Posted requested info, and I also ran an upgrade real quick and rebooted all my machines, and I still see the same issues. But, I'm still seeing the same driver version, which is the latest that is available, and has been for some time.

totaam commented 6 years ago

Well, I managed to reproduce a problem, just not the same symptom. And that's only using the laptop's 1080p screen. I will have to play with client resolutions to try to reproduce this more reliably, including your particular version of this bug.

So:

r20541 fixes the symptoms I have been seeing: when we pad a window with a border because the window contents are smaller than the window, the previous window contents could end up lingering in that border area, we now repaint the whole window area every time (and use black rather than white) - Is glClear(GL_COLOR_BUFFER_BIT) preferred before a whole frame buffer overwritten?: sounds like the performance cost is negligible
r20542 prevents negative padding values, which would have explained the screenshots you've posted - please confirm if things look better now. This doesn't actually fix the underlying problem (a mismatch between the window and the actual vfb size) and part of the window contents would still be missing (the bottom and right sides), but will tell me where to look next.

totaam commented 6 years ago

2018-10-09 18:49:09: maxmylyn commented

I've upped my server and client to r20635 and I'm still seeing the exact same issue - I also don't see any solid black prints when starting with i3, just the offset bottom bar as shown in the i3 screenshot I already posted.

However I do get a DPI warning saying that it's set to 96x96 and it wanted 108x107, is that related?

totaam commented 6 years ago

@maxmylyn: do you use a wacky window manager by any chance?

Is this bug really caused by the first vs second connection, or just by the resizing that happens when you connect? Does it trigger again if you run this before re-connecting:

DISPLAY=:13 xrandr -s 1920x1080

totaam commented 6 years ago

2018-10-11 17:41:22: maxmylyn commented

@antoine: It's KDE, so maybe?

It triggers again if I run that in between connections.

Just to be clear:

Initial connection with xrandr -s 1920x1080 set as a start command -> offset

Disconnect and reconnect -> Offset goes away

Disconnect, run DISPLAY=:13 xrandr -s 1920x1080, then reconnect -> offset

Xpra-org / xpra