from #2643
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
Please attach the -d window,screen,geometry
log of when you re-attach.
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.
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.
(..) 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 :-)
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.
Note that compound xpra control :200 client debug disable window,geometry,screen
does not work, and no error is shown
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:
xpra control :2 client debug enable window geometry screen
xpra control :2 client debug disable focus+grab
With this out of the way, the log:
get_workarea() absolute total monitor area: (0, -181, 3520, 900)
/ total monitor dimensions: (3520, 1081)
- looks like the workarea calculations need normalizing to 0
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?
Note however that this still does not do what you expect:
disable window,geometry,screen
will disable all loggers that matchwindow
,geometry
ANDscreen
- 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)
Note however that this still does not do what you expect:
disable window,geometry,screen
will disable all loggers that matchwindow
,geometry
ANDscreen
- 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.
I don't have explicit replication steps, and I haven't seen something related since I switched to this layout.
I'll now revert to the original layout (which also makes mouse pointer work more naturally), and be on the lookout for this one
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2658