Using macOS-10.13.3 client to display a linux (centos 6.6 or 6.9) server, mode=ssh exclusively. Previously while using client Xpra 2.0.2, my client config file could specify encoding=rgb (and it worked). After upgrading to client 2.2.4, same file yields encoding of auto (checked while connection is active).
The goal is (as worked using 2.0.2), to start the client-GUI with a predefined config file, and just hit Connect (without editing any GUI fields) and achieve encoding=rgb. The GUI is capable of achieving encoding=rgb, but incapable (it seems now) of saving a config file to reproduce same. I have not tried if explicitly assigning other encodings do work (i.e. it may not be specific to only rgb).
Because of above #1-3 I conclude it's a client-specific issue. It demos the server is still capable of rgb. But I did not nail down an exact 100% reliable way to "play" with advanced enc. options to always achieve the rbg. And every time I think I found a play-sequence that works, if I repeat same but Save those settings to a file (instead of Connect), then try and launch from that file, it returns to encoding=auto.
I also tried to explore many variations in the config file just using an editor (including encoding=rgb24, or rgb32), with no success. Somehow I thought perhaps omitting quality=... or some special value of quality (0, -1, 100, auto, Auto, none...) might get it to work, but no success yet. Note when you play with advanced enc. options, select other encodings, then reselect original desired encoding, often the initially displayed speed=Auto, quality=Auto GUI fields don't both come back (i.e. quality tends to be omitted; prob. unrelated issue, though it was leading me to try to drop quality or define it "specially" in the config file).
From a client terminal I can reproduce the problem this way:
% open /Applications/Xpra.app myconfig.xpra
but if I start it this way it works (gives rgb):
% /Applications/Xpra.app/Contents/MacOS/Launcher myconfig.xpra
I've associated (in macos Finder) the Xpra.app as the app to "open-with" for files of type *.xpra. Maybe that was a mistake, and I need to figure out how to associate them with the path to the .../Launcher instead (though the app worked in 2.0.2)? When I use above Launcher the GUI window is initially iconified (I want it either open instead of iconified, as the app does; or an option to tell .../Launcher to just auto-Connect: by-pass the GUI). (Also unrelated, I didn't find the way yet to start multiple unrelated Xpra clients). Thanks.
This also avoids this issue for me:
% open /Applications/Xpra.app --args myconfig.xpra
So it is likely an appleScript wrapper can encapsulate this (and be associated as open-with for the *.xpra file-type) as a work-around.
note: 'open -n' can force a new client instance. But no easy way to elect that mode (or not) from the Finder (like via a modifier key). Really want max-1 instance per unique combo of remote: user/host/sshPort/DISPLAY.
or an option to tell .../Launcher to just auto-Connect: by-pass the GUI
Set autoconnect=true
in your config file.
I didn't find the way yet to start multiple unrelated Xpra clients
2.3 will have support for this, but only for local servers: #1706
Wow, autoconnect (i.e. by virtue of by-passing manipulation thru the GUI?) avoids the problem: Easy work-around.
With autoconnect:
$ xpra info | grep -e encoding= -e encodings.video -e 'pipe.*encoding' -e encoding.selection features.auto-video-encoding=True window.1.encoding=rgb window.1.encoding.selection=encoding_is_rgb24 window.1.encodings.video=('h264', 'vp9', 'vp8')
WithOUT autoconnect:
$ xpra info | grep -e encoding= -e encodings.video -e 'pipe.*encoding' -e encoding.selection features.auto-video-encoding=True window.1.encoding=auto window.1.encoding.pipeline_param.encoding=('h264', 'vp9', 'vp8') window.1.encoding.selection=best_encoding_video window.1.encodings.video=('h264', 'vp9', 'vp8')
I've associated (in macos Finder) the Xpra.app as the app to "open-with" for files of type *.xpra. Maybe that was a mistake, and I need to figure out how to associate them with the path to the .../Launcher instead
The recommended way to ensure the file association is setup correctly is to install using the PKG installer. Note that macos can really get in a twist if you have multiple versions installed anywhere on your hard-drives, and running the installer will then do totally unexpected things we have zero control over. This is not a bug but a feature, apparently (...)
That said, I've tried with older versions (2.2.x branch), with the current development version (2.3 beta), with the open
command and also by executing the full command % /Applications/Xpra.app/Contents/MacOS/Launcher myconfig.xpra
I got "rgb" every time.
So I cannot reproduce the problem, which is going to make it very hard to fix. Please try the fresh "python3" 2.3 beta builds and see if the problem still occurs: https://xpra.org/beta/osx/
Note: unless you have a very fast network (10Gbps?) between your server and client, you may be better off setting speed=100 and quality=100 instead of encoding=rgb.
I must have used the DMG install always in the past. Just tried upgrading via 2.2.2 PKG on a 2nd machine (different: macos 10.12.6). But only the /usr/local/bin/ wrappers were updated, nothing in /Applications. Guess should uninstall first? Once I get that sorted, I'll try the beta too.
Just tried upgrading via 2.2.2 PKG
2.2.4 is out, use that instead.
on a 2nd machine (different: macos 10.12.6). But only the /usr/local/bin/ wrappers were updated, nothing in /Applications. Guess should uninstall first?
Yes. See comment:4, macos can make a complete mess of installations when the application bundle already exists anywhere on the filesystem...
xpra v2.3-r18406, xpra v2.3-r18395 : Both failed on Connect for me, saying '>' not supported between instances of 'str' and 'int'. Tried several older betas that don't reach that far (no GUI is displayed).
xpra v2.2.4-r18312: (PKG) recreates same failure for me, on 2nd machine also.
If I define encoding=rgb (in addition to my usual dpi and swap-keys) in the ~/Library/Application Support/Xpra/xpra.conf
this does work, though does not let a specific conf file override it.
xpra v2.3-r18406, xpra v2.3-r18395 : Both failed on Connect for me, saying '>' not supported between instances of 'str' and 'int'. Tried several older betas that don't reach that far (no GUI is displayed).
That's very odd, those are the versions I was testing with.
Please post the exact error message, and the ".xpra" file you have used to trigger it.
xpra v2.2.4-r18312: (PKG) recreates same failure for me, on 2nd machine also.
Which failure? "'>' not supported"? Again, this has been tested more than once. I suspect that there's something messed up with your environment. Maybe two versions are mixed up. Please also post the output of "xpra showconfig".
The "'>' not supported" was only for the 2.3 betas. The 2.2.4 recreates the failure of the .xpra file to set encoding=rgb.
I played with minimizing the .xpra, and this still triggers that xpra v2.3-r18406 "'>' not supported":
username=xy host=centos2 mode=ssh port=3
I'll attach a snapshot of the window. Just noticed the dialogue does not show Advanced Encoding Options.
GUI > not supported
showconfig v2.3-r18406
Starting v2.3-r18406 like this:
/Applications/Xpra.app/Contents/MacOS/Launcher -d launcher myconfig.xpra
on connect I get:
... update_options_from_gui() ('xy', '', 'ssh', '', 'centos2', '3', '22', 'auto') cannot connect: Traceback (most recent call last): File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/client_launcher.py", line 562, in do_connect self.connect_builtin() File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/client_launcher.py", line 576, in connect_builtin if self.config.port and self.config.port>0: TypeError: '>' not supported between instances of 'str' and 'int' handle_exception('>' not supported between instances of 'str' and 'int')
TypeError: '>' not supported between instances of 'str' and 'int'
That was only with ssh mode and python3 builds, this is now fixed in r18420. (the underlying bug was always there but only triggered a real visible problem with this combination) I have uploaded a new build with this fix: https://xpra.org/beta/osx.
Just noticed the dialogue does not show Advanced Encoding Options.
The python3 / gtk3 builds don't have support for this yet, as gtk3 changed everything... (in progress: #1717)
Which only leaves the original 'rgb' bug. I'll try again to reproduce it.
Confirmed v2.3-r18406 beta (after worked-around that bug), does respect encoding=... (rgb, ...) in the specific .xpra file. xpra v2.3-r18416 beta still gave me: '>' not supported.
Betas (v2.3-r18406) not ready for me to use otherwise. Performance not as good. Appeared to mostly hang on client-disconnect (have to Force-quit). desktop-fullscreen=yes didn't work for me.
I like performance (quality & latency, pre-2.3) of your suggestion: encoding=auto, quality=100, speed=100 (versus encoding=rgb, min-speed=85, min-quality=65 which I had settled on previously for some reason).
If I hack the Launcher to log stdout/stderr, (so I can capture debug logs, triggered by env-vars, despite using 'open ...') I get this (edited down to those of interest):
In 2.2.4 (explicit encoding is not retained):
35 loaded : encoding=rgb assigned (new): encoding='rgb' _apply_props({..., 'encoding': 'rgb', ... setting encoding combo to rgb / 9 may_show() osx open signal=False update_options_from_gui() ('xy', '', 'ssh', '', 'centos2', '3', '22', 'auto')
(With autoconnect above are consistent, except that last -- update_options_from_gui() -- is missing: explicit encoding retained).
In 2.3 beta yields (explicit encoding retained):
35 loaded : encoding=rgb assigned (new): encoding='rgb' _apply_props({..., 'encoding': 'rgb', ... may_show() osx open signal=False update_options_from_gui() ('xy', '', 'ssh', '', 'centos2', '3', '22', 'rgb')
In 2.0.2 (explicit encoding retained):
35 loaded : encoding=rgb assigned (new): encoding='rgb _apply_props({..., 'encoding': 'rgb', ... setting encoding combo to rgb / 8 may_show() osx open signal=False update_options_from_gui() ('xy', '', 'ssh', '', 'centos2', '3', '22', 'rgb')
xpra v2.3-r18416 beta still gave me: '>' not supported.
The fix is in r18420. You need a newer version that that. Sorry, I think I forgot to upload one, done now.
Confirmed v2.3-r18406 beta (after worked-around that bug)
Workaround, how?
Performance not as good
How so? Framerate? Quality? Testing using what application? Does it make any difference if you turn opengl on or off? (the new opengl backend is the only major difference since 2.2, that and switching to python3 + gtk3)
Appeared to mostly hang on client-disconnect
Can you run it from the command line with "-d all" and see where it gets stuck? (works fine here - including on non-virtualized hardware)
versus encoding=rgb, min-speed=85, min-quality=65
Setting quality with rgb is meaningless. Setting speed is usually not helpful.
desktop-fullscreen=yes didn't work for me.
This isn't related to this bug, is it? I don't know how you tried to use it or what you expected it to do. Did this work in older versions?
If I hack the Launcher to log stdout/stderr
How?
Regarding update_options_from_gui
, that quality and speed menu code is horrible, which is why it is so hard to port to GTK3.
It "works" with the 2.3 builds because the GUI widget is not created, so it falls back to the default value.
The 2.3 betas include client_launcher.py source. I just removed the 'and ... > 0' clause of the line 576 (leaving the port a string in the code). I'll revisit 2.3, on performance and to debug-log the quit.
In 2.0.x, 2.2.x I use desktop-fullscreen=yes and it works; no title-bar at top of window (until you mouse up to top when it will pop-down giving access to the Xpra menu, kind of like an auto-hide). In 2.3 you just click the full-screen button on the title-bar. It is unrelated to this bug. I coerce my desktop resolution, and then access/display on one of two machines, one with monitor of that exact resolution, other one is larger. I think on the larger monitor I intended no scaling (to display black bars at bottom/right edges), now it is scaling up, not sure when or how that change occurred. (Don't think that's a bug, some option I added or removed).
Edit the Contents/MacOS/Launcher sh-script. After 1st line (after the shebang) add: exec >& /tmp/debug.log
then in a shell:
export XPRA_LAUNCHER_DEBUG=1 open /Applications/Xpra.app myconfig.xpra
hit connect, after desktop displays quit it. Examine the log (a bit ugly with ESC sequences). An "empty" exec can be used to just redirect the I/O of the current process.
Examine the log (a bit ugly with ESC sequences)
As of r18426, you can now disable escape sequences by adding the env var: XPRA_COLOR_LOG=0
.
In 2.0.x, 2.2.x I use desktop-fullscreen=yes and it works
So you're connecting to a desktop or shadow server.
In 2.3 you just click the full-screen button on the title-bar.
Do you mean the "maximize" button? This may just be because the xpra 2.3 builds you tried were all based on python3 + gtk3, rather than a change in xpra 2.3 itself.
I managed to reproduce the bug using the python3 builds and using the file association (double click on session file or using the "open" syntax from comment:14). Using the command line arguments directly does not trigger the bug... This is now fixed in r18428 (with some extra debug logging thrown in by accident). Please confirm and I will backport to the 2.2.x branch.
What happened was that although the item was shown as selected in the combo box, the item with the check mark next to it was still the default. This only happens when we update the selection programmatically after the dialog has been created. (we only do this on macos because of the really strange way they handle launching applications on file association)
Other improvements to the launcher:
As for the performance issue, please try both types of 2.3 builds so we know if the issue is with the 2.3 release or with the switch to python3 + GTK3. There are now beta builds of the same revision, both with the older gtk2 libraries and the newer python3 ones: https://xpra.org/beta/osx. If the performance is lower only with the python3 builds, please attach the client output with "-d opengl".
py3-2.3-r18428-quit.log.gz
As I expected, the drop in performance with the python3 builds is due to opengl getting turned off:
Error loading OpenGL support: 'NoneType' object does not support item assignment
Can you try xpra from the command line with "-d opengl"? ie:
./Xpra.app/Contents/MacOS/Xpra attach ssh://username:password@host/ -d opengl
If I can find what's causing opengl to fail on this system, it should be easy to fix and the performance should be at least as good as it was with older versions.
As for the exit hang, this log doesn't seem to contain anything related to closing down the client process, as if you hadn't tried to close it. Can you try it from the command line? Maybe also try to close it with a control-c to see if it fares any better?
py3 xpra v2.3-r18428: The menu item to Quit works. cmd-Q hangs (see attached log, I can't tell where/if it logs a disconnect event). cmd-H is not recognized.
At connect a notification window flashes by (error show in the log also):
OpenGL setup failure 'NoneType' object does not support item assignment.
Another small notification flashes after this, which may be just a status, looks like it has desktop resolution.
My remote desktop cursor mostly disappears: May be a big factor in my perception of poor performance (its "obviously" too loaded down to display the cursor).
% /Applications/Xpra.app/Contents/Helpers/OpenGL_check Traceback (most recent call last): File "<frozen importlib._bootstrap>", line 888, in _find_spec AttributeError: 'DynamicImporter' object has no attribute 'find_spec' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<string>", line 1, in <module> File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk_base/gtkgl_check.py", line 35, in <module> from xpra.client.gl.gtk_base.gtk_compat import MODE_RGBA, MODE_ALPHA, MODE_RGB, MODE_DOUBLE, MODE_SINGLE, MODE_DEPTH File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk_base/gtk_compat.py", line 15, in <module> from gi.repository import Gtk, GdkGLExt, GtkGLExt #@UnresolvedImport File "/Applications/Xpra.app/Contents/Resources/lib/python/gi/importer.py", line 127, in find_module 'introspection typelib not found' % namespace) ImportError: cannot import name GdkGLExt, introspection typelib not found
/Applications/Xpra.app/Contents/Helpers/OpenGL_check
Traceback (most recent call last):
..
This tool still needs porting to the new backend, to get the opengl diagnostics please use "xpra attach -d opengl" until this is complete. (as per comment:16)
Can I backport the "rgb" fix?
Yes, both r18428 versions respect encoding-rgb.
Thanks for the log!
Got it. Forgot to test with multiple monitors attached and there's a bug.. You can just comment out the whole block where the code fails and you should get a working opengl python3 build. I'll upload a new build as soon as I get back.
py3 xpra v2.3-r18428: If I attach, I can control-C. If I cmd-Q, the display freezes, I get the spinning beach-ball cursor, and (also shown in debug-alls-py3-2.3-r18428-quit.log.gz) I get "UI thread is now blocked". Like this:
2018-02-13 22:34:43,541 reap() calling os.waitpid(-1, 'WNOHANG') 2018-02-13 22:34:43,541 reap() waitpid=0 2018-02-13 22:34:45,132 Xpra X11 desktop server version 1.0.9-r17257 64-bit 2018-02-13 22:34:45,133 running on Linux CentOS 6.6 Final 2018-02-13 22:34:45,133 enabled remote logging 2018-02-13 22:34:45,158 Warning: Desktop scaling adjusted to accomodate the server 2018-02-13 22:34:45,158 server desktop size is 1920x1080 2018-02-13 22:34:45,158 using scaling factor 1.067 x 1.067 2018-02-13 22:34:45,159 Attached to andro2 via ssh 2018-02-13 22:34:45,159 (press Control-C to detach) 2018-02-13 22:35:03,456 UI thread is now blocked ^Z Suspended
I never use cmd-q, as I often test within a vm with limited keyboard emulation. I'm pretty sure that's a gtk3 "feature". If I can't find an easy workaround I'll ask the gtk-osx mailing list. I'm sure we can fix this too.
I have uploaded builds from both branches with those fixes: https://xpra.org/beta/osx/
Unless you have other problems, I think we can close this ticket? Many thanks for your help!
Great, yes can close this ticket, thank you.
If I have more feedback on betas, should they just be more tickets? How can I tell if opengl "survived" initialization and is in effect or not? i.e. from output of "attach -d opengl' (despite some stacktraces) or better from "xpra info"?
% /Applications/Xpra.app/Contents/MacOS/Xpra attach ssh://xy@centos2/ --desktop-fullscreen --quality=100 --speed=100 -d opengl --desktop-scaling=0 /Applications/Xpra.app/Contents/Resources/lib/python/xpra/platform/darwin/gui.py:98: Warning: invalid cast from 'GtkMenuBar' to 'GtkWindow' osxapp.set_menu_bar(mh.rebuild()) /Applications/Xpra.app/Contents/Resources/lib/python/xpra/platform/darwin/gui.py:98: GtkWarning: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed osxapp.set_menu_bar(mh.rebuild()) 2018-02-14 13:11:57,781 Xpra gtk2 client version 2.3-r18437 64-bit 2018-02-14 13:11:57,781 running on Mac OS X 10.13.3 2018-02-14 13:11:58,455 GStreamer version 1.12.4 for Python 2.7.14 64-bit 2018-02-14 13:11:58,897 init_opengl(auto) 2018-02-14 13:11:58,897 checking with <function OpenGL_safety_check at 0x1100ce398> 2018-02-14 13:11:58,897 <function OpenGL_safety_check at 0x1100ce398>()=None 2018-02-14 13:11:58,898 checking with <function gl_check at 0x1155e25f0> 2018-02-14 13:11:58,898 <function gl_check at 0x1155e25f0>()=None 2018-02-14 13:11:58,898 init_opengl: going to import xpra.client.gl 2018-02-14 13:11:58,899 init_opengl: backend options: ('gtk', 'native') 2018-02-14 13:11:58,900 attempting to load gtk OpenGL backend 2018-02-14 13:11:58,900 importing xpra.client.gl.gtk2.gtkgl_client_window 2018-02-14 13:11:58,961 OpenGL_accelerate module loaded 2018-02-14 13:11:58,982 Using accelerated ArrayDatatype 2018-02-14 13:11:59,314 xpra.client.gl.gtk2.gtkgl_client_window=<module 'xpra.client.gl.gtk2.gtkgl_client_window' from '/Applications/Xpra.app/Contents/Resources/lib/python/xp\ ra/client/gl/gtk2/gtkgl_client_window.py'> Traceback (most recent call last): File "logging/__init__.pyc", line 861, in emit File "logging/__init__.pyc", line 734, in format N(RRSRt showwarningR(tcapture((slogging/__init__.pycR???s (bRuR'RLRBR???R???RR???RFt__all__R???t ImportErrorRSR\R^t File "logging/__init__.pyc", line 465, in format Log 'msg % args' with severity 'DEBUG'. File "logging/__init__.pyc", line 329, in getMessage N( traiseExceptionsR'tstderrR(R???R???RStwriteRORUtIOError(RiR???((slogging/__init__.pyct handleErrors TypeError: not enough arguments for format string Logged from file log.py, line 111 2018-02-14 13:11:59,333 Config_new_by_mode(2)=<gtk.gdkgl.Config object at 0x116f7a870 (GdkGLConfigImplQuartz at 0x7fea0a2168f0)> Traceback (most recent call last): File "logging/__init__.pyc", line 861, in emit File "logging/__init__.pyc", line 734, in format N(RRSRt showwarningR(tcapture((slogging/__init__.pycR???s (bRuR'RLRBR???R???RR???RFt__all__R???t ImportErrorRSR\R^t File "logging/__init__.pyc", line 465, in format Log 'msg % args' with severity 'DEBUG'. File "logging/__init__.pyc", line 329, in getMessage N( traiseExceptionsR'tstderrR(R???R???RStwriteRORUtIOError(RiR???((slogging/__init__.pyct handleErrors TypeError: not enough arguments for format string Logged from file log.py, line 111 2018-02-14 13:11:59,335 Config_new_by_mode(10)=<gtk.gdkgl.Config object at 0x11821da50 (GdkGLConfigImplQuartz at 0x7fea0a216940)> 2018-02-14 13:11:59,335 OpenGL initialization error Traceback (most recent call last): File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/gtk_client_base.py", line 973, in init_opengl self.opengl_props = gl_client_window_module.check_support(force_enable) File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk_base/gtkgl_check.py", line 80, in check_support props["display_mode"] = get_MODE_names(display_mode) File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk_base/gtk_compat.py", line 136, in get_MODE_names friendly_modes = [v for k,v in FRIENDLY_MODE_NAMES.items() if k>0 and (k&mode)==k] NameError: global name 'FRIENDLY_MODE_NAMES' is not defined 2018-02-14 13:11:59,336 Error loading OpenGL support: 2018-02-14 13:11:59,337 global name 'FRIENDLY_MODE_NAMES' is not defined 2018-02-14 13:11:59,771 init_opengl(auto) Traceback (most recent call last): File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/gtk_client_base.py", line 973, in init_opengl self.opengl_props = gl_client_window_module.check_support(force_enable) File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk_base/gtkgl_check.py", line 80, in check_support props["display_mode"] = get_MODE_names(display_mode) File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk_base/gtk_compat.py", line 136, in get_MODE_names friendly_modes = [v for k,v in FRIENDLY_MODE_NAMES.items() if k>0 and (k&mode)==k] NameError: global name 'FRIENDLY_MODE_NAMES' is not defined 2018-02-14 13:11:59,805 keyboard settings: layout=us 2018-02-14 13:11:59,969 desktop size is 2560x1440 with 1 screen: 2018-02-14 13:11:59,970 xy-mbp.local (903x508 mm - DPI: 72x72) workarea: 2560x1417 at 0x23 2018-02-14 13:11:59,970 monitor 1 /Applications/Xpra.app/Contents/Resources/lib/python/xpra/platform/darwin/osx_tray.py:86: Warning: invalid cast from 'GtkMenuBar' to 'GtkWindow' self.macapp.set_menu_bar(self.menu) /Applications/Xpra.app/Contents/Resources/lib/python/xpra/platform/darwin/osx_tray.py:86: GtkWarning: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed self.macapp.set_menu_bar(self.menu) 2018-02-14 13:12:01,491 Xpra X11 desktop server version 1.0.9-r17257 64-bit 2018-02-14 13:12:01,492 running on Linux CentOS 6.6 Final 2018-02-14 13:12:01,492 enabled remote logging 2018-02-14 13:12:01,502 Attached to centos2 via ssh 2018-02-14 13:12:01,502 (press Control-C to detach)
opengl shown on session info
If I have more feedback on betas, should they just be more tickets?
Usually, creating new tickets is preferred, but we can handle what should be a quick query like this one here.
How can I tell if opengl "survived" initialization and is in effect or not?
There are at least 3 ways you can tell:
OpenGL enable with $YOUR_OPENGL_DRIVER
"
more opengl driver information is also available in the "software" section if opengl is enabled.
i.e. from output of "attach -d opengl' (despite some stacktraces) or better from "xpra info"?
The first problem had already been fixed in r18440, but I had not published new builds with this fix. For some reason, something on macos mangles a lot of the stacktraces, so I can't be certain I've got everything going on there. My guess is that you may also have hit this issue: r18441, in fixing the GTK3 opengl, it looks like I broke the GTK2 opengl.. doh! The latest beta builds fix both of those issues.
Thanks. Session Info even showed the error message for OpenGL-Mode! Confirmed on openGL fix in r18441.
In GTK3, after maximize, the screen is offset upward (top of screen cut-off), and mouse action is likewise offset (does not occur where pointer is displayed).
My monitor is larger than the remote desktop, and using desktop-scaling=0, though not sure if these symptoms are specific to these conditions.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1766