xpra icon
Bug tracker and wiki

Opened 8 months ago

Last modified 7 months ago

#2658 assigned defect

Re-attaching a client session puts the window off-monitor

Reported by: stdedos Owned by: Antoine Martin
Priority: minor Milestone: 4.1
Component: client Version: 3.0.x
Keywords: Cc:

Description (last modified by stdedos)

from #2643

With the same geometry:

Re-attaching a gnome-terminal and a libre-office gives me this


(the black is not mine, it's coming from ShareX. The screenshot application "identifies" bounding boxes for application windows and not only that; the should be the libre-office that's outside of the monitor)

Window state at this moment is maximized.

"Xpra-Python3-x86_64_4.0-r25669\xpra_cmd" attach ssh://user@ip/20 --ssh="plink -ssh -agent" --modal-windows=no

2020-03-20 09:15:09,027 Xpra GTK3 client version 4.0-r25669 64-bit
2020-03-20 09:15:09,027  running on Microsoft Windows 10
2020-03-20 09:15:09,120 Warning: failed to import opencv:
2020-03-20 09:15:09,120  No module named 'cv2'
2020-03-20 09:15:09,120  webcam forwarding is disabled
2020-03-20 09:15:10,069 GStreamer version 1.16.2 for Python 3.8.2 64-bit
2020-03-20 09:15:10,380 keyboard layout code 0x409
2020-03-20 09:15:10,380 identified as 'United States - English' : us
2020-03-20 09:15:10,583 OpenGL_accelerate module loaded
2020-03-20 09:15:10,629 Using accelerated ArrayDatatype
2020-03-20 09:15:11,532 Warning: vendor 'Intel' is greylisted,
2020-03-20 09:15:11,532  you may want to turn off OpenGL if you encounter bugs
2020-03-20 09:15:11,548 OpenGL enabled with Intel(R) HD Graphics 4000
2020-03-20 09:15:11,812  keyboard settings: layout=us
2020-03-20 09:15:11,812  desktop size is 3520x1081 with 1 screen:
2020-03-20 09:15:11,812   Default (931x286 mm - DPI: 96x96) workarea: 3520x1041
2020-03-20 09:15:11,812     Generic PnP Monitor 1600x900 at 0x181 (309x174 mm - DPI: 131x131) workarea: 1600x860
2020-03-20 09:15:11,812     C32JG5x 1920x1080 at 1600x0 (697x392 mm - DPI: 69x69) workarea: 1920x1040
2020-03-20 09:15:18,644 enabled remote logging
2020-03-20 09:15:18,644 Xpra GTK3 X11 server version 3.0.7-r25627 64-bit
2020-03-20 09:15:18,644  running on Linux Ubuntu 16.04 xenial

Attachments (3)

xpra-geometry-ApplicationFrameHost_2020-03-20_09-17-15.png (333.6 KB) - added by stdedos 8 months ago.
Xpra-reattach_cmd_2020-03-20_09-19-49.png (56.8 KB) - added by stdedos 8 months ago.
xpra-2658-debug.log (130.7 KB) - added by stdedos 7 months ago.

Download all attachments as: .zip

Change History (15)

Changed 8 months ago by stdedos

comment:1 Changed 8 months ago by stdedos

Description: modified (diff)

comment:2 Changed 8 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

Please attach the -d window,screen,geometry log of when you re-attach.

comment:3 Changed 8 months ago by stdedos

And now I cannot retrigger it ...

Would you please consider to make client diagnostics toggleable on demand in the client?

I could start all instances with -d window,screen,geometry, but then the logging would be super excessive on-screen (or saved to a file).

If I could disable them after connecting without having #2658 replicated, then I could remove the strain on my eyes and on xpra logging.

comment:4 Changed 7 months ago by Antoine Martin

Would you please consider to make client diagnostics toggleable on demand in the client?

They already are - though you will need r25718 or later with python3 clients. (stupid bytes vs strings)

The syntax is almost identical to the way you can toggle server debug logging:

xpra control :2 debug enable compress

For the client, you just add client:

xpra control :2 client debug enable draw

This will enable draw debugging on all connected clients.

comment:5 in reply to:  4 Changed 7 months ago by stdedos

(..)
This will enable draw debugging on all connected clients.

🤯🤯🤯🤯🤯🤯🤯

I didn't even see it coming. My feature request idea was a dialog box from the client itself, and a searchable list of checkboxes; but I could definitely work with that :-D

Let's see from Monday :-)

Last edited 7 months ago by stdedos (previous) (diff)

comment:6 Changed 7 months ago by stdedos

Owner: changed from stdedos to Antoine Martin

Unfortunately, not enough coffee and I totally forgot about >=r25718.

I won't risk missing necessary debug by manually truncating; so find the diagnostics on the attachment below.

Changed 7 months ago by stdedos

Attachment: xpra-2658-debug.log added

comment:7 Changed 7 months ago by stdedos

Note that compound xpra control :200 client debug disable window,geometry,screen does not work, and no error is shown

comment:8 Changed 7 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

Note that compound xpra control :200 client debug disable window,geometry,screen does not work, and no error is shown

r25742 updates the client to support the same syntax variations as the server.
Note however that this still does not do what you expect: disable window,geometry,screen will disable all loggers that match window, geometry AND screen - which is precisely 0 loggers.
If you want to enable more than one debug categories using the same command line you will need r25743, so you can do things like:

  • enable many categories:
    xpra control :2 client debug enable window geometry screen
    
  • enable loggers that match both categories:
    xpra control :2  client debug disable focus+grab
    

With this out of the way, the log:

  • this looks odd: get_workarea() absolute total monitor area: (0, -181, 3520, 900) / total monitor dimensions: (3520, 1081) - looks like the workarea calculations need normalizing to 0
  • both windows get mapped in the same place:
    2020-03-23 09:08:57,620 map-window wid=1, geometry=(8, 31, 1600, 837), client props={b'workspace': 65535, 'encodings.rgb_formats': ['BGRA', 'BGRX', 'RGBA', 'RGBX', 'BGR', 'RGB'], 'encoding.transparency': True, 'encoding.full_csc_modes': {'h264': ['ARGB', 'BGRA', 'BGRX', 'GBRP', 'RGB', 'XRGB', 'YUV420P', 'YUV422P', 'YUV444P'], 'vp8': ['YUV420P'], 'h265': ['BGRA', 'BGRX', 'GBRP', 'RGB', 'XRGB', 'YUV420P', 'YUV422P', 'YUV444P'], 'mpeg4': ['YUV420P'], 'mpeg1': ['YUV420P'], 'mpeg2': ['YUV420P'], 'vp9': ['YUV420P', 'YUV444P'], 'webp': ['BGRA', 'BGRX', 'RGBA', 'RGBX']}, 'encoding.send-window-size': True, 'encoding.scrolling': True, 'workspace': 65535}, state={'frame': (8, 8, 31, 8)}
    2020-03-23 09:08:57,635 map-window wid=2, geometry=(8, 31, 1600, 837), client props={b'workspace': 65535, 'encodings.rgb_formats': ['YUV420P', 'YUV422P', 'YUV444P', 'GBRP', 'BGRA', 'BGRX', 'RGBA', 'RGBX', 'RGB', 'BGR'], 'encoding.transparency': False, 'encoding.full_csc_modes': {'h264': ['ARGB', 'BGRA', 'BGRX', 'GBRP', 'RGB', 'XRGB', 'YUV420P', 'YUV422P', 'YUV444P'], 'vp8': ['YUV420P'], 'h265': ['BGRX', 'GBRP', 'RGB', 'XRGB', 'YUV420P', 'YUV422P', 'YUV444P'], 'mpeg4': ['YUV420P'], 'mpeg1': ['YUV420P'], 'mpeg2': ['YUV420P'], 'vp9': ['YUV420P', 'YUV444P'], 'webp': ['BGRA', 'BGRX', 'RGBA', 'RGBX']}, 'encoding.send-window-size': True, 'encoding.scrolling': True, 'encoding.bit-depth': 24, 'workspace': 65535}, state={'focused': True, 'frame': (8, 8, 31, 8)}
    

Could this be off-screen since the first monitor is at an offset?
Generic PnP Monitor 1600x900 at 0x181 (309x174 mm - DPI: 131x131) workarea: 1600x860.

Does it "fix" things if you align your monitors to the top of the screen rather than the bottom?

comment:9 in reply to:  8 ; Changed 7 months ago by stdedos

Note however that this still does not do what you expect: disable window,geometry,screen will disable all loggers that match window, geometry AND screen - which is precisely 0 loggers.

I don't understand what that means; would you explain that for the viewers?

Reading from your example below focus+grab, I assume that ~= focus,grab so... what is that syntax?

  • both windows get mapped in the same place:

(..)

You mean drawn on top of each other? That sounds normal to me.
If I have one monitor, and work with maximized windows ... where could they possibly be if not on top of each other?

Keep into account that on the win-client, I keep alternating (arbitrarily) between one and two monitor setup.

Consider the edge-case that I have a client attached on dual screen; go on hibernate for ~30 minutes, and I start up + reconnect on single monitor layout

Could this be off-screen since the first monitor is at an offset?
Generic PnP Monitor 1600x900 at 0x181 (309x174 mm - DPI: 131x131) workarea: 1600x860.

Does it "fix" things if you align your monitors to the top of the screen rather than the bottom?

Sounds like it; I'll test at night though (no second monitor to test against right now)

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

comment:10 in reply to:  9 Changed 7 months ago by Antoine Martin

Note however that this still does not do what you expect: disable window,geometry,screen will disable all loggers that match window, geometry AND screen - which is precisely 0 loggers.

I don't understand what that means; would you explain that for the viewers?

That there are NO loggers that use window and geometry and screen logging categories at the same time.
As per the examples from comment:8, if you want to enable all of these categories, use separate arguments (using spaces) not the CSV format.

Reading from your example below focus+grab, I assume that ~= focus,grab so... what is that syntax?

"focus+grab" and "focus,grab" do the same thing, I added "+" because I think it is clearer.

comment:11 Changed 7 months ago by Antoine Martin

Milestone: 4.04.1
Owner: changed from stdedos to Antoine Martin
Status: newassigned

comment:12 Changed 7 months ago by stdedos

I don't have explicit replication steps, and I haven't seen something related since I switched to this layout.

http://xpra.org/trac/raw-attachment/ticket/2703/xpra_monitor-setup_ApplicationFrameHost_2020-04-02_10-50-02.png

I'll now revert to the original layout (which also makes mouse pointer work more naturally), and be on the lookout for this one

Note: See TracTickets for help on using tickets.