xpra icon
Bug tracker and wiki

Opened 14 months ago

Last modified 13 months ago

#1967 new defect

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

Reported by: J. Max Mena Owned by: Antoine Martin
Priority: minor Milestone: 2.4
Component: server Version: 2.3.x
Keywords: Cc:

Description

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.

Attachments (12)

1967 initial connection.png (20.5 KB) - added by J. Max Mena 14 months ago.
Screenshot of the initial connection
1967 second connection.png (21.0 KB) - added by J. Max Mena 14 months ago.
After disconnecting and re-attaching
1967 i3.jpg (69.3 KB) - added by Antoine Martin 14 months ago.
third screenshot with i3 running to show the offset more clearly (replacing with a more reasonable file size)
1967dopenglpaintinitial.log (49.2 KB) - added by J. Max Mena 14 months ago.
-d opengl,paint logs of the initial connection.
1967dopenglpaintsecond.log (46.8 KB) - added by J. Max Mena 14 months ago.
-d opengl,paint logs of the second connection (same session)
1967dpaintnoopengl.log (5.5 KB) - added by J. Max Mena 14 months ago.
-d paint logs of a different session, with a working initial connection
1967 reinitialize.png (59.8 KB) - added by J. Max Mena 14 months ago.
after clicking re-initialize from the systray
1967infobeforeconnect.txt (56.3 KB) - added by J. Max Mena 14 months ago.
Xpra info before connection
1967infoafterconnect.txt (97.3 KB) - added by J. Max Mena 14 months ago.
Xpra info after first connection
1967infofinal.txt (97.3 KB) - added by J. Max Mena 14 months ago.
Xpra info after second connection disconnects
1967dmetadatafirst.log (3.6 KB) - added by J. Max Mena 14 months ago.
-d metadata of initial client connection (with offset)
1967dmetadatasecond.log (3.7 KB) - added by J. Max Mena 14 months ago.
-d metadata of second client connection (without offset)

Download all attachments as: .zip

Change History (23)

Changed 14 months ago by J. Max Mena

Attachment: 1967 initial connection.png added

Screenshot of the initial connection

Changed 14 months ago by J. Max Mena

Attachment: 1967 second connection.png added

After disconnecting and re-attaching

Changed 14 months ago by Antoine Martin

Attachment: 1967 i3.jpg added

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

comment:1 Changed 14 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
  • 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.

comment:2 Changed 14 months ago by J. Max Mena

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.

Last edited 14 months ago by J. Max Mena (previous) (diff)

Changed 14 months ago by J. Max Mena

Attachment: 1967dopenglpaintinitial.log added

-d opengl,paint logs of the initial connection.

Changed 14 months ago by J. Max Mena

Attachment: 1967dopenglpaintsecond.log added

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

Changed 14 months ago by J. Max Mena

Attachment: 1967dpaintnoopengl.log added

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

comment:3 Changed 14 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.

comment:4 Changed 14 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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

comment:5 Changed 14 months ago by J. Max Mena

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.

Last edited 14 months ago by Antoine Martin (previous) (diff)

Changed 14 months ago by J. Max Mena

Attachment: 1967 reinitialize.png added

after clicking re-initialize from the systray

Changed 14 months ago by J. Max Mena

Attachment: 1967infobeforeconnect.txt added

Xpra info before connection

Changed 14 months ago by J. Max Mena

Attachment: 1967infoafterconnect.txt added

Xpra info after first connection

Changed 14 months ago by J. Max Mena

Attachment: 1967infofinal.txt added

Xpra info after second connection disconnects

Changed 14 months ago by J. Max Mena

Attachment: 1967dmetadatafirst.log added

-d metadata of initial client connection (with offset)

Changed 14 months ago by J. Max Mena

Attachment: 1967dmetadatasecond.log added

-d metadata of second client connection (without offset)

comment:6 Changed 14 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.

comment:7 Changed 14 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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.

comment:8 Changed 14 months ago by Antoine Martin

Milestone: 2.4

comment:9 Changed 13 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

Back from vacation!

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?

comment:10 Changed 13 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

@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

comment:11 Changed 13 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

@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

Note: See TracTickets for help on using tickets.