no longer control encoding in config file (macos/OS X client)

[totaam]

Issue migrated from trac ticket # 1766

component: client | priority: major | resolution: fixed | keywords: encoding rgb

2018-02-09 07:58:55: sto6 created the issue

---

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).

1. Issue persists in both server (linux) versions I've tried: xpra v1.0.6-15846, xpra v1.0.9-17257
2. Using the launcher GUI, I can hit "Advanced Encoding Options" and play with it (change to other than Raw RGB..., then change back), and then hit Connect and thereby sometimes achieve encoding=rgb (checked while connection is active).
3. In the server log when it's working I see: "using rgb as primary encoding" instead of "automatic picture encoding enabled". Also the client menu's Encoding item (while connected) confirms same: either automatic (it failed) or "Raw RGB..." (it works) has a check-mark.

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.

[totaam]

2018-02-09 09:21:41: sto6 commented

---

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.

[totaam]

2018-02-09 17:22:06: antoine changed status from new to assigned

[totaam]

2018-02-09 17:22:06: antoine edited the issue description

[totaam]

2018-02-09 17:22:06: antoine commented

---

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

[totaam]

2018-02-11 03:10:09: sto6 commented

---

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')

[totaam]

2018-02-11 16:57:09: antoine changed status from assigned to new

[totaam]

2018-02-11 16:57:09: antoine changed owner from antoine to sto6

[totaam]

2018-02-11 16:57:09: antoine commented

---

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.

[totaam]

2018-02-12 00:44:39: sto6 commented

---

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.

[totaam]

2018-02-12 04:00:26: antoine commented

---

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...

[totaam]

2018-02-12 09:07:12: sto6 commented

---

xpra v2.3-18406, 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-18312: (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.

[totaam]

2018-02-12 09:20:02: antoine commented

---

xpra v2.3-18406, 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-18312: (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".

[totaam]

2018-02-12 21:14:09: sto6 commented

---

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-18406 "'>' 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.

[totaam]

2018-02-12 21:14:59: sto6 uploaded file err1-v2d3-r18406.png (52.1 KiB)

GUI > not supported

[totaam]

2018-02-12 21:16:04: sto6 uploaded file showconfig-v2d3-r18406.txt (7.4 KiB)

showconfig v2.3-r18406

[totaam]

2018-02-12 23:34:57: sto6 commented

---

Starting v2.3-18406 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')

[totaam]

2018-02-13 06:15:51: antoine commented

---

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.

[totaam]

2018-02-13 11:10:00: sto6 commented

---

Confirmed v2.3-18406 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-18406) 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')

[totaam]

2018-02-13 11:55:20: antoine commented

---

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-18406 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.

[totaam]

2018-02-13 14:47:31: sto6 commented

---

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.

[totaam]

2018-02-13 16:41:44: antoine commented

---

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:

• r18427 make ssh port optional
• r18424 don't populate or require the display number with ssh mode

---

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".

[totaam]

2018-02-14 04:51:56: sto6 uploaded file debug-alls-py3-2.3-r18428-quit.log.gz (172.8 KiB)

py3-2.3-r18428-quit.log.gz

[totaam]

2018-02-14 05:01:24: antoine commented

---

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?

[totaam]

2018-02-14 05:04:24: sto6 commented

---

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

[totaam]

2018-02-14 05:10:31: antoine commented

---

/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?

[totaam]

2018-02-14 06:27:53: sto6 commented

---

Yes, both r18428 versions respect encoding-rgb.

[totaam]

2018-02-14 06:28:53: sto6 uploaded file debug-ogls-py3-2.3-r18428.log (4.4 KiB)

[totaam]

2018-02-14 06:36:33: antoine commented

---

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.

[totaam]

2018-02-14 06:39:30: sto6 commented

---

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-17257 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

[totaam]

2018-02-14 06:44:12: antoine commented

---

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.

[totaam]

2018-02-14 09:09:52: antoine commented

---

• r18431 fixes the opengl error with multiple monitors - this should restore the performance of the python3 builds for you
• 18432 backports the "rgb" fix to the v2.2.x branch
• the cmd-q issue is now tracked here: python3 gtk3 client feature parity #1717#comment:8
• r18434 + r18435 + r18436 + r18437: the "opengl_check" script now works again with both python2 and python3 builds

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!

[totaam]

2018-02-14 21:45:52: sto6 commented

---

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](../commit/71e4d3830856732dd4a8fa39ec1d793f69075cb7) 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-17257 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)

[totaam]

2018-02-15 03:03:48: antoine uploaded file osx-opengl.png (42.2 KiB)

opengl shown on session info

[totaam]

2018-02-15 03:11:34: antoine changed status from new to closed

[totaam]

2018-02-15 03:11:34: antoine set resolution to fixed

[totaam]

2018-02-15 03:11:34: antoine commented

---

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:

• when running from the command line, the client will print: "OpenGL enable with $YOUR_OPENGL_DRIVER"
• the opengl option will be available in the "features" menu
• the "features" section of the "session info" dialog will show the opengl status and driver information:
  [[Image(osx-opengl.png)]]
  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.

[totaam]

2018-02-15 05:41:04: sto6 commented

---

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.