Good day,
I’m trying to run xpra (v0.15.5) + virtualgl. I have a client machine (Windows running Opentext Exceed + vglclient), and the application is running on a Linux machine. With VirtualGL, the process is:
With xpra, on the Linux side I'm doing: xpra start :123 --start-child="vglrun glxgears" setenv DISPLAY WINDOWS:0.0 xpra attach :123
This does the trick of attaching the sessions and directing them to my windows machine, but 3D acceleration is not working. I tried the vglrun –d option and set either the server or windows machine display, but that didn’t help either.
2015-09-03 13:41:39,640 cannot use pycups for printing: No module named cups 2015-09-03 13:41:39,797 xpra gtk2 client version 0.15.5 (runknown) Xlib: extension "GLX" missing on display "WINDOWS:0.0". (Xpra:31268): GdkGLExt-WARNING **: Window system doesn't support OpenGL. 2015-09-03 13:41:39,942 Error loading OpenGL support: 2015-09-03 13:41:39,942 OpenGL is not supported Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/xpra/client/gtk_base/gtk_client_base.py", line 448, in init_opengl __import__("xpra.client.gl.gtk_compat", {}, {}, []) File "/usr/lib64/python2.6/site-packages/xpra/client/gl/gtk_compat.py", line 59, in <module> from gtk import gdkgl, gtkgl File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/gdkgl/__init__.py", line 21, in <module> from _gdkgl import * RuntimeError: OpenGL is not supported 2015-09-03 13:41:39,953 XkbRF_GetNamesProp failed, returning defaults: {'rules': 'base', 'model': 'pc105', 'layout': 'us'} 2015-09-03 13:41:39,954 XkbRF_GetNamesProp failed, returning defaults: {'rules': 'base', 'model': 'pc105', 'layout': 'us'} 2015-09-03 13:41:39,975 signal_safe_exec(['setxkbmap', '-print'], None, {}) stdout='' 2015-09-03 13:41:39,975 signal_safe_exec(['setxkbmap', '-print'], None, {}) stderr='XKB extension not present on WINDOWS:0.0\n' 2015-09-03 13:41:39,975 '['setxkbmap', '-print']' failed with exit code 255 2015-09-03 13:41:39,981 no keysym found for keycode 49 2015-09-03 13:41:39,981 no keysym found for keycode 61 2015-09-03 13:41:39,981 no keysym found for keycode 65 2015-09-03 13:41:39,981 no keysym found for keycode 36 2015-09-03 13:41:39,981 no keysym found for keycode 94 2015-09-03 13:41:39,981 no keysym found for keycode 63 2015-09-03 13:41:39,981 no keysym found for keycode 96 2015-09-03 13:41:39,981 no keysym found for keycode 97 2015-09-03 13:41:40,104 XkbRF_GetNamesProp failed, returning defaults: {'rules': 'base', 'model': 'pc105', 'layout': 'us'} 2015-09-03 13:41:40,400 detected keyboard: rules=base, model=pc105, layout=us 2015-09-03 13:41:40,404 failed to get number of desktop: unpack requires a string argument of length 4 2015-09-03 13:41:40,408 failed to get current desktop: unpack requires a string argument of length 4 2015-09-03 13:41:40,408 desktop size is 5120x1600 with 1 screen(s): 2015-09-03 13:41:40,408 'WINDOWS:0.0' (1355x423 mm - DPI: 95x96) 2015-09-03 13:41:40,409 screen 2015-09-03 13:41:40,409 failed to get keyboard repeat rate: 'NoneType' object is not iterable 2015-09-03 13:41:40,776 mmap is enabled using 250MB area in /tmp/xpra.51SmaO.mmap 2015-09-03 13:41:40,776 server: Linux Red Hat Enterprise Linux Server 6.6 Santiago, Xpra version 0.15.5 (runknown) 2015-09-03 13:41:40,787 Warning: outdated/buggy version of Python: 2.6.6.final.0 2015-09-03 13:41:40,787 switching to process polling every 2 seconds to support 'exit-with-children' 2015-09-03 13:41:40,788 Attached to :123 (press Control-C to detach) Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/xpra/client/gtk_base/gtk_client_window_base.py", line 435, in property_changed state_atoms = set(wm_state_atoms) TypeError: 'NoneType' object is not iterable
Why do you use exceed instead of a native xpra client for windows? This is causing all sorts of problems with the limited X11 server you're connecting to. And performance is going to be very poor, and xpra's opengl accelerated client rendering won't work (that's completely different from vgl), etc..
Now, as for virtualgl: it's a server-side thing only. If vglrun whatever
runs something, then virtualgl is doing its job. xpra is the transport layer for the graphics, after they've been rendered on the virtual X11 server.
Interesting, so there is no need for either Exceed & vglclient on windows, and only xpra client for windows is all that's needed?
My impression was xpra is serving as an X proxy to maintain remote X applications state rather than a complete X11 server.
I'll try your suggestion and see how it will work,
Thank you for your quick reply,
so there is no need for either Exceed & vglclient on windows, and only xpra client for windows is all that's needed?
Correct.
My impression was xpra is serving as an X proxy to maintain remote X applications state rather than a complete X11 server.
Xpra is more of a compositing window manager than an X11 proxy, we use a virtual framebuffer (Xvfb or Xdummy) as display server, we can then forward the windows' contents (and clicks and whatever else) in the xpra protocol which is independent of X11: we have an HTML client, Java and android clients (new external project), etc.. And also win32 and osx shadow servers (admittedly, not as fully features as the X11 version).
I am closing this ticket as invalid because I believe vgl works just fine with xpra as long as you use a native xpra client. Feel free to file a new one if you encounter other issues.
And many thanks for the unusual log sample, we never test with X11 servers as restricted as Exceed, which led to many code improvements (mostly error handling and error messages) in trunk:
state_atoms = set(wm_state_atoms)
, TypeError: 'NoneType' object is not iterable
: fixed in r10518 (this one I will backport to older versions)
RuntimeError: OpenGL is not supported
: no longer a full stacktrace, just a warning as of r10520
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/975