[winswitch] Xpra GL and gtkglext woes

Ben Sferrazza bsferrazza at avnera.com
Mon Mar 5 21:25:25 GMT 2018


On Mon, Mar 5, 2018 at 11:50 AM, Antoine Martin via shifter-users <
shifter-users at lists.devloop.org.uk> wrote:

> On 06/03/18 00:38, Ben Sferrazza via shifter-users wrote:
> > Hi. I've built Xpra 2.2.4 on a Linux server at work which runs an old
> > distribution, CentOS 5. The kernel is 2.6.18, but I've created a fully
> > bootstrapped toolchain/binary/library environment that runs the latest
> > version of glibc (2.19) for the kernel, gcc 7.3.0, and binutils 2.30,
> > following most of the Linux From Scratch book. Everything I've thrown at
> it
> > works well, even having built Xorg, GTK+2/3, and GUI applications. I made
> > sure to build all the Xpra dependencies and built it with
> > --prefix=/home/tools, which is where my updated environment is.
> Impressive!
>
> I am considering using a similar approach (maybe using snap / flatpack /
> appimage) to continue to support CentOS 6 in the future.
>

Thanks. Certainly wasn't easy at first, and had to make quite few tweaks
and workarounds along the way.


>
> > I have built Mesa, and am using the Xdummy xorg.conf. All seems well, but
> > the Xpra client never showed the --start-child app of konsole. It had
> > errors like this.
> >
> > 2018-03-05 17:04:40,440 x_event_filter event=('xpra-create-event',
> > None)/CreateNotify window=0x299
> > 2018-03-05 17:04:40,440 cannot get gdk window for <gtk.gdk.Display object
> > at 0x2ae82f5ea050 (GdkDisplayX11 at 0x1b3be1f0)>, 12582913
> > 2018-03-05 17:04:40,441 XError: XError: 3 processing CreateNotify
> > Traceback (most recent call last):
> >   File "xpra/x11/gtk2/gdk_bindings.pyx", line 1062, in
> > xpra.x11.gtk2.gdk_bindings.parse_xevent
> >   File "xpra/x11/gtk2/gdk_bindings.pyx", line 914, in
> > xpra.x11.gtk2.gdk_bindings._gw
> > XError: XError: 3
> > 2018-03-05 17:04:40,442 Some window in our event disappeared before we
> > could handle the event 16/CreateNotify using ('xpra-create-event', None);
> > so I'm just ignoring it instead. python event=<X11:CreateNotify
> > {'delivered_to': '0x299', 'send_event': 0, 'serial': '0x36a', 'type': 16,
> > 'display': ':100'}>
> Error 3 is BadWindow. This usually means that the window got destroyed
> before we could get hold of it. (X11 is asynchronous)
> I assume that you got this error in your server log with some debug
> flags enabled, right?
>

correct. I start xpra using '-d all'

xpra start :100 --start-child=xterm --socket-dirs=~/.xpra -d all


>
> > So I then went ahead and installed gtkglext and the Python bindings,
> > thinking it was somehow related to OpenGL.
> What makes you think that?
> What vfb are you using? Are you using Xdummy or Xvfb? Have you tried
> switching to the other option? Does your vfb support opengl?
> Is using VirtualGL an option?
> (there's quite a bit on the wiki about all these options)
>

It was just a hunch. Perhaps a poor one. I believe to be using Xdummy. I
have the latest Xvfb as part of the xorg-server-1.19.6 tar ball. I placed
the following line in my /home/tools/etc/xpra/xpra.conf

xvfb=Xorg -dpi 96 -noreset -nolisten tcp \
                        +extension GLX +extension RANDR +extension RENDER \
                        -logfile ${HOME}/.xpra/Xvfb-10.log -config
/home/tools/etc/X11/xorg.conf

I have built and installed the latest xf-video-dummy, am using the
xorg.conf provided by Xpra. Is this sufficient to be using Xdummy?

I'll have to give VirtualGL a try. These servers at work are headless
multi-Xeon CPU systems without much of a video card. An lspci -v | grep VGA
returns

0a:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. G200eR2
(rev 01) (prog-if 00 [VGA controller])

The are completely modern systems, so I find it odd that it would have a
video card from the late 90s in it.


> > However, passing --opengl=no on
> > the command line when starting xpra appeared to do nothing.
> Correct, it doesn't do anything to the server. This is a client command
> line option for enabling the OpenGL accelerated rendering backend.
>
> > But now I get
> > this mysterious ImportError
> >
> > 2018-03-05 17:04:38,809 err(xpra opengl)=xpra main error:
> > Traceback (most recent call last):
> >   File "/home/tools/lib/python/xpra/scripts/main.py", line 175, in main
> >     return run_mode(script_file, err, options, args, mode, defaults)
> >   File "/home/tools/lib/python/xpra/scripts/main.py", line 1517, in
> run_mode
> >     return run_glcheck(options)
> >   File "/home/tools/lib/python/xpra/scripts/main.py", line 2723, in
> > run_glcheck
> >     from xpra.client.gl.gtk_base.gtkgl_check import check_support
> >   File "/home/tools/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 "/home/tools/lib/python/xpra/client/gl/gtk_base/gtk_compat.py",
> line
> > 59, in <module>
> >     from gtk import gdkgl, gtkgl
> >   File
> > "/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/__init__.py",
> > line 21, in <module>
> >     from _gdkgl import *
> > ImportError:
> > /home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/_gdkgl.so:
> > undefined symbol: gdk_window_is_gl_capable
> >
> > When I run strings on that _gdkgl.so, I get the following
> >
> > bash-4.4$ strings _gdkgl.so | grep gdk_window_is_gl_capable
> > gdk_window_is_gl_capable
> > _wrap_gdk_window_is_gl_capable
> > _wrap_gdk_window_is_gl_capable
> >
> > and the function is defined in the following include file
> >
> > /home/tools/include/gtkglext-1.0/gdk/gdkglwindow.h
> >
> > bash-4.4$ grep gdk_window_is_gl_capable gdkglwindow.h
> > gboolean     gdk_window_is_gl_capable       (GdkWindow   *window);
> Looks like your build of pygtkgl is not quite right.
> This is unrelated to the missing window problem.
>

OK, the latter is reassuring. Using both the latest sources from the git
repositories of gtkglext and pygtkglext, I had to use the patch file you
created as part of https://www.xpra.org/trac/ticket/226 to get it to even
build correctly. The only change I made to the patch was removing the OSX
dependent paths in configure.in. $TOOLS = /home/tools.

+CFLAGS="$CFLAGS -I$TOOLS/include/gtkglext-1.0
-I$TOOLS/lib/gtkglext-1.0/include -I$TOOLS/include/"


> During startup the xpra server probes the vfb's OpenGL capabilities by
> running "xpra opengl" in a subprocess (so it won't crash the server if
> opengl is somehow badly misconfigured to the point of causing crashes)
> The message you are seeing just means that the probing fails.
>
> > Perhaps the issue of not getting a window drawn is unrelated to the
> > ImportError, but I'd like to fix both of these issues. Thank you for any
> > help in solving this!
> Is the window not being drawn, or not being shown at all?
>
> Are you sure that the application (konsole in this case) is still
> running and hasn't just crashed?
> The best way to debug this is to launch an xterm instead, then run your
> applications from there. Or maybe even with gdb if it does crash.
>

konsole is just the KDE terminal program. But good point. Changing it to
xterm seems to suggest I'm not even connecting. I am prompted for my
password and the Xpra client (Windows) disappears. Seems to be running as
per taskmgr, but the tray icon goes away.

Here's where the child process is executed.

2018-03-05 20:25:44,790 exec_start_commands() start=[],
start_child=['xterm']
2018-03-05 20:25:44,790 start_child('xterm', 'xterm', False, None, True,
None, {})
2018-03-05 20:25:44,791 threaded_init() start
2018-03-05 20:25:44,796 add_process(<subprocess.Popen object at
0x2ba85fca5cd0>, xterm, ['xterm'], False, False) pid=7293
2018-03-05 20:25:44,797 pid(['xterm'])=7293
2018-03-05 20:25:44,797 started command 'xterm' with pid 7293
2018-03-05 20:25:44,797 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'xterm', 'process': <subprocess.Popen object at
0x2ba85fca5cd0>, 'pid': 7293, 'dead': False, 'ignore': False, 'callback':
None, 'command': ['xterm'], 'forget': False})]
2018-03-05 20:25:44,797 guess_session_name() commands=['xterm']
2018-03-05 20:25:44,797 <bound method XpraServer.init_sockets of
<XpraServer object at 0x2ba85a41b460 (xpra+x11+server+XpraServer at
0xc9849a0)>>([('unix-domain', <socket._socketobject object at
0x2ba857935d00>, '/home/bsferrazza/.xpra/l-server-13-100')])
2018-03-05 20:25:44,798 init_sockets([('unix-domain', <socket._socketobject
object at 0x2ba857935d00>, '/home/bsferrazza/.xpra/l-server-13-100')]) will
add unix-domain socket <socket._socketobject object at 0x2ba857935d00>
(/home/bsferrazza/.xpra/l-server-13-100)
2018-03-05 20:25:44,798 added unix socket path:
/home/bsferrazza/.xpra/l-server-13-100
2018-03-05 20:25:44,798 local sockets we can use for printing:
['/home/bsferrazza/.xpra/l-server-13-100']
2018-03-05 20:25:44,798 <bound method XpraServer.init_when_ready of
<XpraServer object at 0x2ba85a41b460 (xpra+x11+server+XpraServer at
0xc9849a0)>>([])
2018-03-05 20:25:44,798 running <bound method XpraServer.run of <XpraServer
object at 0x2ba85a41b460 (xpra+x11+server+XpraServer at 0xc9849a0)>>
2018-03-05 20:25:44,799 xpra X11 version 2.2.4-r18312 64-bit
2018-03-05 20:25:44,801  uid=10345 (bsferrazza), gid=1001 (eng)
2018-03-05 20:25:44,801  running with pid 6769 on Linux CentOS 5.11 Final
2018-03-05 20:25:44,802  connected to X11 display :100 with 24 bit colors
2018-03-05 20:25:44,802 do_run() calling <function gtk_main at
0x2ba84d7a52a8>
2018-03-05 20:25:44,802 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'xterm', 'process': <subprocess.Popen object at
0x2ba85fca5cd0>, 'pid': 7293, 'dead': False, 'ignore': False, 'callback':
None, 'command': ['xterm'], 'forget': False})]
2018-03-05 20:25:44,803 check() alive=[ProcInfo({'returncode': None,
'name': 'xterm', 'process': <subprocess.Popen object at 0x2ba85fca5cd0>,
'pid': 7293, 'dead': False, 'ignore': False, 'callback': None, 'command':
['xterm'], 'forget': False})], quit callback=None
2018-03-05 20:25:44,803 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x400001
2018-03-05 20:25:44,803 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x400001', 'send_event': 0, 'window': '0x400001', 'atom':
'_NET_WM_NAME', 'serial': '0x3a', 'type': 28, 'display': ':100'}>
2018-03-05 20:25:44,804 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.8ms
2018-03-05 20:25:44,804 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x400001
2018-03-05 20:25:44,804 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x400001', 'send_event': 0, 'window': '0x400001', 'atom':
'WM_NAME', 'serial': '0x3b', 'type': 28, 'display': ':100'}>
2018-03-05 20:25:44,804 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.6ms
2018-03-05 20:25:44,805 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x400001

The bottom of the log file, before and even after attempting a connection
still just shows this.

2018-03-05 21:16:09,763 sigchld(17, <frame object at 0x2acc79900238>)
2018-03-05 21:16:09,763 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'xterm', 'process': <subprocess.Popen object at
0x2acc8e6a9d50>, 'pid': 27371, 'dead': False, 'ignore': False, 'callback':
None, 'command': ['xterm'], 'forget': False})]
2018-03-05 21:16:09,763 reap() calling os.waitpid(-1, 'WNOHANG')
2018-03-05 21:16:09,763 reap() waitpid=0
2018-03-05 21:16:09,764 add_listen_socket(unix-domain,
<socket._socketobject object at 0x2acc8633ad00>)
info=/home/bsferrazza/.xpra/l-server-13-100
2018-03-05 21:16:09,764 reset_server_timeout(True) server_idle_timeout=0,
server_idle_timer=None
2018-03-05 21:16:09,764 xpra is ready.
2018-03-05 21:16:09,764 org.xpra.Server.Event(ready, [])
2018-03-05 21:16:09,764 server-event: ('ready',)

So it's as though it's not even aware of the attempt client connection?

It's probably unrelated but I receive this error immediately when starting
Xpra. This again is run as non-root. I have XDG_RUNTIME_DIR set to a path
in my home directory. So I'm not sure why it's still attempting to access
/run/xpra/system

2018-03-05 21:16:04,755 get_enabled_encoders(['rencode', 'bencode',
'yaml']) enabled=['yaml', 'rencode', 'bencode']
2018-03-05 21:16:04,799 netifaces loaded sucessfully
2018-03-05 21:16:04,799 successfully loaded socket C library from libc.so.6
2018-03-05 21:16:04,804 failed to connect using <bound method
_socketobject.connect of <socket._socketobject object at
0x2b9f9143e520>>/run/xpra/system
Traceback (most recent call last):
  File "/home/tools/lib/python/xpra/scripts/main.py", line 1910, in
_socket_connect
    sock.connect(endpoint)
  File "/home/tools/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 2] No such file or directory
Warning: cannot use the system proxy for 'start' subcommand,
 failed to connect to '/run/xpra/system':
 [Errno 2] No such file or directory



> As for the gdkgl error, this is a build issue. I would just ignore it
> and remove the package. Unless you also intend to use this same system
> as an xpra client, in which case you do want accelerated rendering...
>

I do not intend to use this system as a client. Thank you for your help!


>
> Cheers
> Antoine
>



More information about the shifter-users mailing list