From antoine at nagafix.co.uk Mon Mar 5 07:18:57 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 5 Mar 2018 14:18:57 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.2.5: minor fixes Message-ID: <94a8c731-ce82-97ec-882b-14b2a879ca6a@nagafix.co.uk> Hi, This update only fixes minor issues: the bugs fixes are either cosmetic, hard to trigger, or they affect non-default configurations (ie: Python3) There is no urgency to update if you were not affected. Release notes: * fix SSL socket errors with Python3 servers * fix SSL socket upgrade errors * fix parsing of opengl command line option * fix logging of errors in opengl backend * fix ghost windows on MS Windows with opengl and OR windows * fix gi errors on startup with Python3 + MS Windows * fix import warnings with Python3 builds * fix packaging of crypto libraries with MS Windows builds * fix errors in launcher and ssh mode * fix encoding selection not preserved with Mac OS launcher * fix multiple bandwidth limits shown as selected in menu * fix HTML5 initial focus issue * fix HTML5 URL handling for non-standard deployments * fix HTML5 audio wrongly switched off on return to the connect page * fix Python 3.x compatibility issues * fix handling of special characters in filenames from drag and drop * fix stale xauth lock files * fix PAM login module names on Debian / Ubuntu * fix AES initial exchange issues (Python 3, race condition) * focus launcher on startup with Mac OS * skip unhelpful message when connecting to older servers * skip scary warning if network device probing fails (Posix) Links: https://xpra.org/trac/wiki/Source https://xpra.org/trac/wiki/Download Cheers Antoine From bsferrazza at avnera.com Mon Mar 5 17:38:31 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Mon, 5 Mar 2018 09:38:31 -0800 Subject: [winswitch] Xpra GL and gtkglext woes Message-ID: 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. 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 , 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= So I then went ahead and installed gtkglext and the Python bindings, thinking it was somehow related to OpenGL. However, passing --opengl=no on the command line when starting xpra appeared to do nothing. 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 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 from gtk import gdkgl, gtkgl File "/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/__init__.py", line 21, in 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); 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! Ben From antoine at nagafix.co.uk Mon Mar 5 19:50:05 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 6 Mar 2018 02:50:05 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: 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. > 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 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= {'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? > 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) > 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 > 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 > from gtk import gdkgl, gtkgl > File > "/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/__init__.py", > line 21, in > 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. 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. 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... Cheers Antoine > > Ben > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From bsferrazza at avnera.com Mon Mar 5 21:25:25 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Mon, 5 Mar 2018 13:25:25 -0800 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: 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 > 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= > {'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 > > 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 > > from gtk import gdkgl, gtkgl > > File > > "/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/__init__.py", > > line 21, in > > 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(, 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': , '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 >([('unix-domain', , '/home/bsferrazza/.xpra/l-server-13-100')]) 2018-03-05 20:25:44,798 init_sockets([('unix-domain', , '/home/bsferrazza/.xpra/l-server-13-100')]) will add unix-domain socket (/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 >([]) 2018-03-05 20:25:44,798 running > 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 2018-03-05 20:25:44,802 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'xterm', 'process': , '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': , '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(..)= 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(..)= 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, ) 2018-03-05 21:16:09,763 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'xterm', 'process': , '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, ) 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 >/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 > From bsferrazza at avnera.com Mon Mar 5 22:02:34 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Mon, 5 Mar 2018 14:02:34 -0800 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: Figured I'd add the Xorg log file, with the Modeline lines stripped out. Not sure why it's trying to load libinput when it's using the dummy_mouse and dummy_keyboard. [3017180.958] X Protocol Version 11, Revision 0 [3017180.958] Build Operating System: Linux 2.6.18-398.el5 x86_64 [3017180.958] Current Operating System: Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT 2014 x86_64 [3017180.958] Kernel command line: ro root=LABEL=/ rhgb quiet [3017180.958] Build Date: 05 March 2018 12:19:47AM [3017180.958] [3017180.958] Current version of pixman: 0.34.0 [3017180.958] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [3017180.958] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [3017180.958] (++) Log file: "/home/bsferrazza/.xpra/Xvfb-10.log", Time: Mon Mar 5 21:55:36 2018 [3017180.961] (++) Using config file: "/home/tools/etc/X11/xorg.conf" [3017180.961] (==) Using config directory: "/home/tools/etc/X11/xorg.conf.d" [3017180.961] (==) ServerLayout "dummy_layout" [3017180.961] (**) |-->Screen "dummy_screen" (0) [3017180.961] (**) | |-->Monitor "dummy_monitor" [3017180.961] (**) | |-->Device "dummy_videocard" [3017180.961] (**) |-->Input Device "dummy_mouse" [3017180.961] (**) |-->Input Device "dummy_keyboard" [3017180.961] (**) Option "DontVTSwitch" "true" [3017180.961] (**) Option "AllowMouseOpenFail" "true" [3017180.961] (**) Option "AutoAddDevices" "false" [3017180.961] (**) Option "AutoEnableDevices" "false" [3017180.961] (**) Not automatically adding devices [3017180.961] (**) Not automatically enabling devices [3017180.961] (==) Not automatically adding GPU devices [3017180.961] (==) Max clients allowed: 256, resource mask: 0x1fffff [3017180.961] (==) FontPath set to: ${prefix}/share/fonts/X11/misc/, ${prefix}/share/fonts/X11/TTF/, ${prefix}/share/fonts/X11/OTF/, ${prefix}/share/fonts/X11/Type1/, ${prefix}/share/fonts/X11/100dpi/, ${prefix}/share/fonts/X11/75dpi/ [3017180.961] (**) ModulePath set to "/home/tools/lib/xorg/modules/" [3017180.961] (II) Loader magic: 0x80db00 [3017180.961] (II) Module ABI versions: [3017180.961] X.Org ANSI C Emulation: 0.4 [3017180.961] X.Org Video Driver: 23.0 [3017180.961] X.Org XInput driver : 24.1 [3017180.961] X.Org Server Extension : 10.0 [3017180.971] (--) PCI:*(0:10:0:0) 102b:0534:1028:0600 rev 1, Mem @ 0x90000000/16777216, 0x91800000/16384, 0x91000000/8388608 [3017180.971] (II) Open ACPI successful (/var/run/acpid.socket) [3017180.971] (II) LoadModule: "glx" [3017180.976] (II) Loading /home/tools/lib/xorg/modules/extensions/libglx.so [3017181.002] (II) Module glx: vendor="X.Org Foundation" [3017181.002] compiled for 1.19.6, module version = 1.0.0 [3017181.002] ABI class: X.Org Server Extension, version 10.0 [3017181.002] (II) LoadModule: "dummy" [3017181.008] (II) Loading /home/tools/lib/xorg/modules/drivers/dummy_drv.so [3017181.009] (II) Module dummy: vendor="X.Org Foundation" [3017181.009] compiled for 1.19.6, module version = 0.3.8 [3017181.009] Module class: X.Org Video Driver [3017181.009] ABI class: X.Org Video Driver, version 23.0 [3017181.009] (II) LoadModule: "void" [3017181.010] (WW) Warning, couldn't open module void [3017181.010] (II) UnloadModule: "void" [3017181.010] (II) Unloading void [3017181.010] (EE) Failed to load module "void" (module does not exist, 0) [3017181.010] (II) DUMMY: Driver for Dummy chipsets: dummy [3017181.010] (WW) Falling back to old probe method for dummy [3017181.010] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [3017181.010] (II) DUMMY(0): Chipset is a DUMMY [3017181.010] (++) DUMMY(0): Depth 24, (--) framebuffer bpp 32 [3017181.010] (==) DUMMY(0): RGB weight 888 [3017181.010] (==) DUMMY(0): Default visual is TrueColor [3017181.010] (==) DUMMY(0): Using gamma correction (1.0, 1.0, 1.0) [3017181.010] (**) DUMMY(0): VideoRAM: 192000 kByte [3017181.010] (--) DUMMY(0): Max Clock: 300000 kHz : : [3017181.012] (++) DUMMY(0): DPI set to (96, 96) [3017181.012] (II) Loading sub module "fb" [3017181.012] (II) LoadModule: "fb" [3017181.013] (II) Loading /home/tools/lib/xorg/modules/libfb.so [3017181.013] (II) Module fb: vendor="X.Org Foundation" [3017181.013] compiled for 1.19.6, module version = 1.0.0 [3017181.013] ABI class: X.Org ANSI C Emulation, version 0.4 [3017181.013] (II) Loading sub module "ramdac" [3017181.013] (II) LoadModule: "ramdac" [3017181.013] (II) Module "ramdac" already built-in [3017181.013] (--) Depth 24 pixmap format is 32 bpp [3017181.013] (II) DUMMY(0): Using 1904 scanlines of offscreen memory [3017181.013] (==) DUMMY(0): Backing store enabled [3017181.013] (==) DUMMY(0): Silken mouse enabled [3017181.013] (WW) DUMMY(0): Option "ConstantDPI" is not used [3017181.013] (==) RandR enabled [3017181.014] (II) AIGLX: Screen 0 is not DRI2 capable [3017181.014] (EE) AIGLX: reverting to software rendering [3017181.020] (II) IGLX: enabled GLX_MESA_copy_sub_buffer [3017181.021] (II) IGLX: Loaded and initialized swrast [3017181.021] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [3017181.131] (II) LoadModule: "void" [3017181.133] (WW) Warning, couldn't open module void [3017181.133] (II) UnloadModule: "void" [3017181.133] (II) Unloading void [3017181.133] (EE) Failed to load module "void" (module does not exist, 0) [3017181.133] (EE) No input driver matching `void' [3017181.133] (II) Falling back to input driver `libinput' [3017181.133] (II) LoadModule: "libinput" [3017181.134] (WW) Warning, couldn't open module libinput [3017181.134] (II) UnloadModule: "libinput" [3017181.134] (II) Unloading libinput [3017181.134] (EE) Failed to load module "libinput" (module does not exist, 0) [3017181.134] (II) LoadModule: "void" [3017181.136] (WW) Warning, couldn't open module void [3017181.136] (II) UnloadModule: "void" [3017181.136] (II) Unloading void [3017181.136] (EE) Failed to load module "void" (module does not exist, 0) [3017181.136] (EE) No input driver matching `void' [3017181.136] (II) Falling back to input driver `libinput' [3017181.136] (II) LoadModule: "libinput" [3017181.137] (WW) Warning, couldn't open module libinput [3017181.137] (II) UnloadModule: "libinput" [3017181.137] (II) Unloading libinput [3017181.137] (EE) Failed to load module "libinput" (module does not exist, 0) On Mon, Mar 5, 2018 at 1:25 PM, Ben Sferrazza wrote: > 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 > 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=> > {'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 >> > 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 >> > from gtk import gdkgl, gtkgl >> > File >> > "/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/_ >> _init__.py", >> > line 21, in >> > 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( 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': 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 0xc9849a0)>>([('unix-domain', 0x2ba857935d00>, '/home/bsferrazza/.xpra/l-server-13-100')]) > 2018-03-05 20:25:44,798 init_sockets([('unix-domain', > , '/home/bsferrazza/.xpra/l-server-13-100')]) > will add unix-domain socket > (/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 0xc9849a0)>>([]) > 2018-03-05 20:25:44,798 running 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 0x2ba84d7a52a8> > 2018-03-05 20:25:44,802 poll() procinfo list: [ProcInfo({'returncode': > None, 'name': 'xterm', 'process': 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': , > '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(..)= {'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(..)= {'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, ) > 2018-03-05 21:16:09,763 poll() procinfo list: [ProcInfo({'returncode': > None, 'name': 'xterm', 'process': 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, > ) > 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 _socketobject.connect of 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 >> > > From bsferrazza at avnera.com Mon Mar 5 22:41:27 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Mon, 5 Mar 2018 14:41:27 -0800 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: Well this actually made me realize I never install the fonts to /home/tools/share/X11/fonts/, so I did that and re-built Xorg server. So now I can actually see the connection established by Xpra. Making some progress. 2018-03-05 22:34:20,179 Handshake complete; enabling connection But it's immediately closed. 2018-03-05 22:34:20,523 update_encoding_options: common_video_encodings=['h264'], csc_encoder=None, video_encoder=None 2018-03-05 22:34:20,523 ws.update_encoding_selection(auto, [], True) encoding=auto, common encodings=['h264', 'png', 'rgb', 'rgb24', 'rgb32', 'jpeg'] 2018-03-05 22:34:20,523 update_encoding_selection: client refresh encodings=[], auto_refresh_encodings=['png', 'rgb24', 'rgb32'] 2018-03-05 22:34:20,523 can_retry: , args=(32, 'Broken pipe'), errno=32, code=32, abort=EPIPE 2018-03-05 22:34:20,523 update_encoding_options(False) wid=1, want_alpha=False, speed=40, quality=40, bandwidth-limit=0, lossless threshold: 68 / 12, rgb auto threshold=4096 (min=4096, max=131072), get_best_encoding= 2018-03-05 22:34:20,523 unix-domain socket:/home/bsferrazza/.xpra/l-server-13-100 closed Traceback (most recent call last): File "/home/tools/lib/python/xpra/net/protocol.py", line 588, in _io_thread_loop while not self._closed and callback(): File "/home/tools/lib/python/xpra/net/protocol.py", line 615, in _write return self.write_items(*items) File "/home/tools/lib/python/xpra/net/protocol.py", line 627, in write_items self.write_buffers(buf_data, fail_cb, synchronous) File "/home/tools/lib/python/xpra/net/protocol.py", line 642, in write_buffers written = con.write(buf) File "/home/tools/lib/python/xpra/net/bytestreams.py", line 282, in write return self._write(self._socket.send, buf) File "/home/tools/lib/python/xpra/net/bytestreams.py", line 164, in _write w = self.untilConcludes(*args) File "/home/tools/lib/python/xpra/net/bytestreams.py", line 156, in untilConcludes return untilConcludes(self.is_active, self.can_retry, *args) File "/home/tools/lib/python/xpra/net/bytestreams.py", line 103, in untilConcludes retry = can_retry(e) File "/home/tools/lib/python/xpra/net/bytestreams.py", line 153, in can_retry return can_retry(e) File "/home/tools/lib/python/xpra/net/bytestreams.py", line 93, in can_retry raise ConnectionClosedException(e) ConnectionClosedException: [Errno 32] Broken pipe 2018-03-05 22:34:20,524 cannot score: no pixel format! 2018-03-05 22:34:20,526 connection lost: write connection unix-domain socket:/home/bsferrazza/.xpra/l-server-13-100 closed 2018-03-05 22:34:20,526 update_refresh_attributes() sizef=0.40, qf=1.10, sf=1.10, cf=1.00, batch delay=19, bandwidth-limit=0, min-delay=150, max-delay=1000, delay=150 2018-03-05 22:34:20,526 Protocol.close() closed=False, connection=unix-domain socket:/home/bsferrazza/.xpra/l-server-13-100 2018-03-05 22:34:20,526 update_refresh_attributes() refresh quality=100%, refresh speed=50%, for cv=0.00, bwl=0 2018-03-05 22:34:20,526 Protocol.close() calling 2018-03-05 22:34:20,526 initial encoding for 1: auto 2018-03-05 22:34:20,527 unix-domain socket:/home/bsferrazza/.xpra/l-server-13-100.close() for socket={'fileno': 15, 'type': 1, 'timeout': 0, 'family': 1, 'proto': 0} 2018-03-05 22:34:20,527 send_window_icon window WindowModel(0x600027) icon=None 2018-03-05 22:34:20,527 unix-domain socket:/home/bsferrazza/.xpra/l-server-13-100.close() done 2018-03-05 22:34:20,527 get_default_window_icon() using ('xterm', 'XTerm') 2018-03-05 22:34:20,527 terminate_queue_threads() 2018-03-05 22:34:20,535 .lookup_icon(xterm-color)=None 2018-03-05 22:34:20,535 .lookup_icon(xterm)=None 2018-03-05 22:34:20,535 .lookup_icon(xterm_48x48)=None 2018-03-05 22:34:20,535 .lookup_icon(application-x-xterm)=None 2018-03-05 22:34:20,535 .lookup_icon(xterm-symbolic)=None 2018-03-05 22:34:20,535 .lookup_icon(xterm.symbolic)=None 2018-03-05 22:34:20,535 send_window_icon window WindowModel(0x600027) using default window icon=None 2018-03-05 22:34:20,537 Protocol.close() done On Mon, Mar 5, 2018 at 2:02 PM, Ben Sferrazza wrote: > Figured I'd add the Xorg log file, with the Modeline lines stripped out. > Not sure why it's trying to load libinput when it's using the dummy_mouse > and dummy_keyboard. > > [3017180.958] X Protocol Version 11, Revision 0 > [3017180.958] Build Operating System: Linux 2.6.18-398.el5 x86_64 > [3017180.958] Current Operating System: Linux l-server-13 2.6.18-398.el5 > #1 SMP Tue Sep 16 20:50:52 EDT 2014 x86_64 > [3017180.958] Kernel command line: ro root=LABEL=/ rhgb quiet > [3017180.958] Build Date: 05 March 2018 12:19:47AM > [3017180.958] > [3017180.958] Current version of pixman: 0.34.0 > [3017180.958] Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > [3017180.958] Markers: (--) probed, (**) from config file, (==) default > setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [3017180.958] (++) Log file: "/home/bsferrazza/.xpra/Xvfb-10.log", Time: > Mon Mar 5 21:55:36 2018 > [3017180.961] (++) Using config file: "/home/tools/etc/X11/xorg.conf" > [3017180.961] (==) Using config directory: "/home/tools/etc/X11/xorg. > conf.d" > [3017180.961] (==) ServerLayout "dummy_layout" > [3017180.961] (**) |-->Screen "dummy_screen" (0) > [3017180.961] (**) | |-->Monitor "dummy_monitor" > [3017180.961] (**) | |-->Device "dummy_videocard" > [3017180.961] (**) |-->Input Device "dummy_mouse" > [3017180.961] (**) |-->Input Device "dummy_keyboard" > [3017180.961] (**) Option "DontVTSwitch" "true" > [3017180.961] (**) Option "AllowMouseOpenFail" "true" > [3017180.961] (**) Option "AutoAddDevices" "false" > [3017180.961] (**) Option "AutoEnableDevices" "false" > [3017180.961] (**) Not automatically adding devices > [3017180.961] (**) Not automatically enabling devices > [3017180.961] (==) Not automatically adding GPU devices > [3017180.961] (==) Max clients allowed: 256, resource mask: 0x1fffff > [3017180.961] (==) FontPath set to: > ${prefix}/share/fonts/X11/misc/, > ${prefix}/share/fonts/X11/TTF/, > ${prefix}/share/fonts/X11/OTF/, > ${prefix}/share/fonts/X11/Type1/, > ${prefix}/share/fonts/X11/100dpi/, > ${prefix}/share/fonts/X11/75dpi/ > [3017180.961] (**) ModulePath set to "/home/tools/lib/xorg/modules/" > [3017180.961] (II) Loader magic: 0x80db00 > [3017180.961] (II) Module ABI versions: > [3017180.961] X.Org ANSI C Emulation: 0.4 > [3017180.961] X.Org Video Driver: 23.0 > [3017180.961] X.Org XInput driver : 24.1 > [3017180.961] X.Org Server Extension : 10.0 > [3017180.971] (--) PCI:*(0:10:0:0) 102b:0534:1028:0600 rev 1, Mem @ > 0x90000000/16777216, 0x91800000/16384, 0x91000000/8388608 > [3017180.971] (II) Open ACPI successful (/var/run/acpid.socket) > [3017180.971] (II) LoadModule: "glx" > [3017180.976] (II) Loading /home/tools/lib/xorg/modules/ > extensions/libglx.so > [3017181.002] (II) Module glx: vendor="X.Org Foundation" > [3017181.002] compiled for 1.19.6, module version = 1.0.0 > [3017181.002] ABI class: X.Org Server Extension, version 10.0 > [3017181.002] (II) LoadModule: "dummy" > [3017181.008] (II) Loading /home/tools/lib/xorg/modules/ > drivers/dummy_drv.so > [3017181.009] (II) Module dummy: vendor="X.Org Foundation" > [3017181.009] compiled for 1.19.6, module version = 0.3.8 > [3017181.009] Module class: X.Org Video Driver > [3017181.009] ABI class: X.Org Video Driver, version 23.0 > [3017181.009] (II) LoadModule: "void" > [3017181.010] (WW) Warning, couldn't open module void > [3017181.010] (II) UnloadModule: "void" > [3017181.010] (II) Unloading void > [3017181.010] (EE) Failed to load module "void" (module does not exist, 0) > [3017181.010] (II) DUMMY: Driver for Dummy chipsets: dummy > [3017181.010] (WW) Falling back to old probe method for dummy > [3017181.010] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card > support > [3017181.010] (II) DUMMY(0): Chipset is a DUMMY > [3017181.010] (++) DUMMY(0): Depth 24, (--) framebuffer bpp 32 > [3017181.010] (==) DUMMY(0): RGB weight 888 > [3017181.010] (==) DUMMY(0): Default visual is TrueColor > [3017181.010] (==) DUMMY(0): Using gamma correction (1.0, 1.0, 1.0) > [3017181.010] (**) DUMMY(0): VideoRAM: 192000 kByte > [3017181.010] (--) DUMMY(0): Max Clock: 300000 kHz > : > : > [3017181.012] (++) DUMMY(0): DPI set to (96, 96) > [3017181.012] (II) Loading sub module "fb" > [3017181.012] (II) LoadModule: "fb" > [3017181.013] (II) Loading /home/tools/lib/xorg/modules/libfb.so > [3017181.013] (II) Module fb: vendor="X.Org Foundation" > [3017181.013] compiled for 1.19.6, module version = 1.0.0 > [3017181.013] ABI class: X.Org ANSI C Emulation, version 0.4 > [3017181.013] (II) Loading sub module "ramdac" > [3017181.013] (II) LoadModule: "ramdac" > [3017181.013] (II) Module "ramdac" already built-in > [3017181.013] (--) Depth 24 pixmap format is 32 bpp > [3017181.013] (II) DUMMY(0): Using 1904 scanlines of offscreen memory > [3017181.013] (==) DUMMY(0): Backing store enabled > [3017181.013] (==) DUMMY(0): Silken mouse enabled > [3017181.013] (WW) DUMMY(0): Option "ConstantDPI" is not used > [3017181.013] (==) RandR enabled > [3017181.014] (II) AIGLX: Screen 0 is not DRI2 capable > [3017181.014] (EE) AIGLX: reverting to software rendering > [3017181.020] (II) IGLX: enabled GLX_MESA_copy_sub_buffer > [3017181.021] (II) IGLX: Loaded and initialized swrast > [3017181.021] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > [3017181.131] (II) LoadModule: "void" > [3017181.133] (WW) Warning, couldn't open module void > [3017181.133] (II) UnloadModule: "void" > [3017181.133] (II) Unloading void > [3017181.133] (EE) Failed to load module "void" (module does not exist, 0) > [3017181.133] (EE) No input driver matching `void' > [3017181.133] (II) Falling back to input driver `libinput' > [3017181.133] (II) LoadModule: "libinput" > [3017181.134] (WW) Warning, couldn't open module libinput > [3017181.134] (II) UnloadModule: "libinput" > [3017181.134] (II) Unloading libinput > [3017181.134] (EE) Failed to load module "libinput" (module does not > exist, 0) > [3017181.134] (II) LoadModule: "void" > [3017181.136] (WW) Warning, couldn't open module void > [3017181.136] (II) UnloadModule: "void" > [3017181.136] (II) Unloading void > [3017181.136] (EE) Failed to load module "void" (module does not exist, 0) > [3017181.136] (EE) No input driver matching `void' > [3017181.136] (II) Falling back to input driver `libinput' > [3017181.136] (II) LoadModule: "libinput" > [3017181.137] (WW) Warning, couldn't open module libinput > [3017181.137] (II) UnloadModule: "libinput" > [3017181.137] (II) Unloading libinput > [3017181.137] (EE) Failed to load module "libinput" (module does not > exist, 0) > > > On Mon, Mar 5, 2018 at 1:25 PM, Ben Sferrazza > wrote: > >> 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 >> 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=>> > {'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 >>> > 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 >>> > from gtk import gdkgl, gtkgl >>> > File >>> > "/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/_ >>> _init__.py", >>> > line 21, in >>> > 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(> 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': > 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 > > 0xc9849a0)>>([('unix-domain', > 0x2ba857935d00>, '/home/bsferrazza/.xpra/l-server-13-100')]) >> 2018-03-05 20:25:44,798 init_sockets([('unix-domain', >> , >> '/home/bsferrazza/.xpra/l-server-13-100')]) will add unix-domain socket >> >> (/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 > > 0xc9849a0)>>([]) >> 2018-03-05 20:25:44,798 running > > 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 > 0x2ba84d7a52a8> >> 2018-03-05 20:25:44,802 poll() procinfo list: [ProcInfo({'returncode': >> None, 'name': 'xterm', 'process': > 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': , >> '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(..)=> {'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(..)=> {'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, ) >> 2018-03-05 21:16:09,763 poll() procinfo list: [ProcInfo({'returncode': >> None, 'name': 'xterm', 'process': > 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, >> ) >> 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 > _socketobject.connect of > 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 >>> >> >> > From antoine at nagafix.co.uk Tue Mar 6 04:07:14 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 6 Mar 2018 11:07:14 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: <814697f6-ca48-381e-3d09-df30056c957c@nagafix.co.uk> (..) >>> 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 You should modify (...)/etc/xpra/conf.d/55_server_x11.conf instead. To see which setting is being used, run "xpra showconfig | grep xvfb" > 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? Should be. > I'll have to give VirtualGL a try. These servers at work are headless > multi-Xeon CPU systems without much of a video card. Then no, VirtualGL won't help you there. > 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. Those video cards are there to drive a console output and nothing else, so a simple chipset can be seen as a positive thing. (..) > 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 _socketobject.connect of 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 This directory is for shared sockets with group access. Nothing to worry about, you can ignore the warning, create the directory with group access and add your user to that group, or just remove the directory from the list of "socket-dirs". >> 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! Ah. In that case, you may prefer building trunk which supports a native opengl backend that does not need pygtkgl. Use it with: --opengl=native Cheers Antoine > > >> >> Cheers >> Antoine >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Tue Mar 6 04:10:11 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 6 Mar 2018 11:10:11 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: <6ef9e1df-02e4-3d70-3d6c-35156684d3ce@nagafix.co.uk> On 06/03/18 05:41, Ben Sferrazza via shifter-users wrote: > Well this actually made me realize I never install the fonts to > /home/tools/share/X11/fonts/, so I did that and re-built Xorg server. So > now I can actually see the connection established by Xpra. Making some > progress. > > 2018-03-05 22:34:20,179 Handshake complete; enabling connection > > But it's immediately closed. (..) > File "/home/tools/lib/python/xpra/net/bytestreams.py", line 93, in > can_retry > raise ConnectionClosedException(e) > ConnectionClosedException: [Errno 32] Broken pipe It is likely that the connection has been closed by the other end. So you won't find the answer here, try the client debug output. Cheers Antoine From antoine at nagafix.co.uk Tue Mar 6 04:10:39 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 6 Mar 2018 11:10:39 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> On 06/03/18 05:02, Ben Sferrazza via shifter-users wrote: > Figured I'd add the Xorg log file, with the Modeline lines stripped out. > Not sure why it's trying to load libinput when it's using the dummy_mouse > and dummy_keyboard. > (..) > [3017181.009] (II) LoadModule: "void" > [3017181.010] (WW) Warning, couldn't open module void Are you sure that you are using the current xorg.conf from xpra? We have stopped using the "void" module a long time ago. (..) > [3017181.013] (WW) DUMMY(0): Option "ConstantDPI" is not used You may want to apply our "constant DPI" patch for better DPI support with applications that calculate a "hardware DPI". (..) > [3017181.136] (EE) No input driver matching `void' > [3017181.136] (II) Falling back to input driver `libinput' > [3017181.136] (II) LoadModule: "libinput" > [3017181.137] (WW) Warning, couldn't open module libinput > [3017181.137] (II) UnloadModule: "libinput" > [3017181.137] (II) Unloading libinput > [3017181.137] (EE) Failed to load module "libinput" (module does not exist, > 0) Using the current xorg.conf should work with an Xorg server with the dummy driver only, I don't think we require any other modules. Cheers Antoine From bsferrazza at avnera.com Tue Mar 6 04:52:18 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Mon, 5 Mar 2018 20:52:18 -0800 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: <814697f6-ca48-381e-3d09-df30056c957c@nagafix.co.uk> References: <814697f6-ca48-381e-3d09-df30056c957c@nagafix.co.uk> Message-ID: On Mon, Mar 5, 2018 at 8:07 PM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > (..) > >>> 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 > You should modify (...)/etc/xpra/conf.d/55_server_x11.conf instead. > To see which setting is being used, run "xpra showconfig | grep xvfb" > OK. I see. I deleted that line from the default xpra.conf file, and it starts up using the 55_server_x11.conf settings instead. So that looks good now. That of course uses the (...)/etc/xpra/xorg.conf file too, so no need to worry if I'm using the latest. Problem is, I'm not seeing anything happen after it says xpra is ready in the log file. Even when I attempt to connect with the client. Not connection detected. Time to turn my attention to the client logs like you said. > > 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? > Should be. > > > I'll have to give VirtualGL a try. These servers at work are headless > > multi-Xeon CPU systems without much of a video card. > Then no, VirtualGL won't help you there. > > > 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. > Those video cards are there to drive a console output and nothing else, > so a simple chipset can be seen as a positive thing. > (..) > > 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 > _socketobject.connect of > 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 > This directory is for shared sockets with group access. > Nothing to worry about, you can ignore the warning, create the directory > with group access and add your user to that group, or just remove the > directory from the list of "socket-dirs". > Well, sadly I don't have root access. If I can just ignore it, I will. > > >> 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! > Ah. In that case, you may prefer building trunk which supports a native > opengl backend that does not need pygtkgl. > Use it with: --opengl=native > OK great. I'll give that a try sometime in the next couple of days and report back. > > Cheers > Antoine > > > > > > > >> > >> Cheers > >> Antoine > >> > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From bsferrazza at avnera.com Tue Mar 6 04:55:46 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Mon, 5 Mar 2018 20:55:46 -0800 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> Message-ID: On Mon, Mar 5, 2018 at 8:10 PM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 06/03/18 05:02, Ben Sferrazza via shifter-users wrote: > > Figured I'd add the Xorg log file, with the Modeline lines stripped out. > > Not sure why it's trying to load libinput when it's using the dummy_mouse > > and dummy_keyboard. > > > (..) > > [3017181.009] (II) LoadModule: "void" > > [3017181.010] (WW) Warning, couldn't open module void > Are you sure that you are using the current xorg.conf from xpra? > We have stopped using the "void" module a long time ago. > I was using the one linked to on the Xdummy wiki page. I now just replaced it with (...)/etc/xpra/xorg.conf. No more void module errors, but I do see these. [3040183.094] (II) LoadModule: "mouse" [3040183.095] (WW) Warning, couldn't open module mouse [3040183.095] (II) UnloadModule: "mouse" [3040183.095] (II) Unloading mouse [3040183.095] (EE) Failed to load module "mouse" (module does not exist, 0) [3040183.095] (EE) No input driver matching `mouse' [3040183.095] (II) Falling back to input driver `libinput' [3040183.095] (II) LoadModule: "libinput" [3040183.096] (WW) Warning, couldn't open module libinput [3040183.096] (II) UnloadModule: "libinput" [3040183.096] (II) Unloading libinput [3040183.096] (EE) Failed to load module "libinput" (module does not exist, 0) [3040183.096] (II) LoadModule: "kbd" [3040183.098] (WW) Warning, couldn't open module kbd [3040183.098] (II) UnloadModule: "kbd" [3040183.098] (II) Unloading kbd [3040183.098] (EE) Failed to load module "kbd" (module does not exist, 0) [3040183.098] (EE) No input driver matching `kbd' [3040183.098] (II) Falling back to input driver `libinput' [3040183.098] (II) LoadModule: "libinput" [3040183.099] (WW) Warning, couldn't open module libinput [3040183.099] (II) UnloadModule: "libinput" [3040183.099] (II) Unloading libinput [3040183.099] (EE) Failed to load module "libinput" (module does not exist, 0) > (..) > > [3017181.013] (WW) DUMMY(0): Option "ConstantDPI" is not used > You may want to apply our "constant DPI" patch for better DPI support > with applications that calculate a "hardware DPI". > OK thanks for the suggestion. I see quite a few patches there as part of ticket 163. Any particular ones I should apply given the system I described in my first email? > (..) > > [3017181.136] (EE) No input driver matching `void' > > [3017181.136] (II) Falling back to input driver `libinput' > > [3017181.136] (II) LoadModule: "libinput" > > [3017181.137] (WW) Warning, couldn't open module libinput > > [3017181.137] (II) UnloadModule: "libinput" > > [3017181.137] (II) Unloading libinput > > [3017181.137] (EE) Failed to load module "libinput" (module does not > exist, > > 0) > Using the current xorg.conf should work with an Xorg server with the > dummy driver only, I don't think we require any other modules. > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Tue Mar 6 08:33:51 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 6 Mar 2018 15:33:51 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> Message-ID: <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> On 06/03/18 11:55, Ben Sferrazza via shifter-users wrote: > On Mon, Mar 5, 2018 at 8:10 PM, Antoine Martin via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: > >> On 06/03/18 05:02, Ben Sferrazza via shifter-users wrote: >>> Figured I'd add the Xorg log file, with the Modeline lines stripped out. >>> Not sure why it's trying to load libinput when it's using the dummy_mouse >>> and dummy_keyboard. >>> >> (..) >>> [3017181.009] (II) LoadModule: "void" >>> [3017181.010] (WW) Warning, couldn't open module void >> Are you sure that you are using the current xorg.conf from xpra? >> We have stopped using the "void" module a long time ago. >> > > I was using the one linked to on the Xdummy wiki page. I now just replaced > it with (...)/etc/xpra/xorg.conf. No more void module errors, but I do see > these. > > [3040183.094] (II) LoadModule: "mouse" > [3040183.095] (WW) Warning, couldn't open module mouse > [3040183.095] (II) UnloadModule: "mouse" > [3040183.095] (II) Unloading mouse > [3040183.095] (EE) Failed to load module "mouse" (module does not exist, 0) > [3040183.095] (EE) No input driver matching `mouse' > [3040183.095] (II) Falling back to input driver `libinput' > [3040183.095] (II) LoadModule: "libinput" > [3040183.096] (WW) Warning, couldn't open module libinput > [3040183.096] (II) UnloadModule: "libinput" > [3040183.096] (II) Unloading libinput > [3040183.096] (EE) Failed to load module "libinput" (module does not exist, > 0) > [3040183.096] (II) LoadModule: "kbd" > [3040183.098] (WW) Warning, couldn't open module kbd > [3040183.098] (II) UnloadModule: "kbd" > [3040183.098] (II) Unloading kbd > [3040183.098] (EE) Failed to load module "kbd" (module does not exist, 0) > [3040183.098] (EE) No input driver matching `kbd' > [3040183.098] (II) Falling back to input driver `libinput' > [3040183.098] (II) LoadModule: "libinput" > [3040183.099] (WW) Warning, couldn't open module libinput > [3040183.099] (II) UnloadModule: "libinput" > [3040183.099] (II) Unloading libinput > [3040183.099] (EE) Failed to load module "libinput" (module does not exist, > 0) Never mind, I've checked my latest log files and I see the same thing. We don't specify those devices but they must be default settings. >> (..) >>> [3017181.013] (WW) DUMMY(0): Option "ConstantDPI" is not used >> You may want to apply our "constant DPI" patch for better DPI support >> with applications that calculate a "hardware DPI". >> > > OK thanks for the suggestion. I see quite a few patches there as part of > ticket 163. Any particular ones I should apply given the system I described > in my first email? Assuming that you've built the latest 0.3.8 version of the dummy driver, then the only patch you need on top of that is the "constant dpi" patch: https://xpra.org/trac/attachment/ticket/163/0002-Constant-DPI.patch (note: this only benefits some applications - most notably Java ones) Cheers Antoine From bsferrazza at avnera.com Tue Mar 6 17:00:25 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Tue, 6 Mar 2018 09:00:25 -0800 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> Message-ID: On Tue, Mar 6, 2018 at 12:33 AM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 06/03/18 11:55, Ben Sferrazza via shifter-users wrote: > > On Mon, Mar 5, 2018 at 8:10 PM, Antoine Martin via shifter-users < > > shifter-users at lists.devloop.org.uk> wrote: > > > >> On 06/03/18 05:02, Ben Sferrazza via shifter-users wrote: > >>> Figured I'd add the Xorg log file, with the Modeline lines stripped > out. > >>> Not sure why it's trying to load libinput when it's using the > dummy_mouse > >>> and dummy_keyboard. > >>> > >> (..) > >>> [3017181.009] (II) LoadModule: "void" > >>> [3017181.010] (WW) Warning, couldn't open module void > >> Are you sure that you are using the current xorg.conf from xpra? > >> We have stopped using the "void" module a long time ago. > >> > > > > I was using the one linked to on the Xdummy wiki page. I now just > replaced > > it with (...)/etc/xpra/xorg.conf. No more void module errors, but I do > see > > these. > > > > [3040183.094] (II) LoadModule: "mouse" > > [3040183.095] (WW) Warning, couldn't open module mouse > > [3040183.095] (II) UnloadModule: "mouse" > > [3040183.095] (II) Unloading mouse > > [3040183.095] (EE) Failed to load module "mouse" (module does not exist, > 0) > > [3040183.095] (EE) No input driver matching `mouse' > > [3040183.095] (II) Falling back to input driver `libinput' > > [3040183.095] (II) LoadModule: "libinput" > > [3040183.096] (WW) Warning, couldn't open module libinput > > [3040183.096] (II) UnloadModule: "libinput" > > [3040183.096] (II) Unloading libinput > > [3040183.096] (EE) Failed to load module "libinput" (module does not > exist, > > 0) > > [3040183.096] (II) LoadModule: "kbd" > > [3040183.098] (WW) Warning, couldn't open module kbd > > [3040183.098] (II) UnloadModule: "kbd" > > [3040183.098] (II) Unloading kbd > > [3040183.098] (EE) Failed to load module "kbd" (module does not exist, 0) > > [3040183.098] (EE) No input driver matching `kbd' > > [3040183.098] (II) Falling back to input driver `libinput' > > [3040183.098] (II) LoadModule: "libinput" > > [3040183.099] (WW) Warning, couldn't open module libinput > > [3040183.099] (II) UnloadModule: "libinput" > > [3040183.099] (II) Unloading libinput > > [3040183.099] (EE) Failed to load module "libinput" (module does not > exist, > > 0) > Never mind, I've checked my latest log files and I see the same thing. > We don't specify those devices but they must be default settings. > >> (..) > >>> [3017181.013] (WW) DUMMY(0): Option "ConstantDPI" is not used > >> You may want to apply our "constant DPI" patch for better DPI support > >> with applications that calculate a "hardware DPI". > >> > > > > OK thanks for the suggestion. I see quite a few patches there as part of > > ticket 163. Any particular ones I should apply given the system I > described > > in my first email? > Assuming that you've built the latest 0.3.8 version of the dummy driver, > then the only patch you need on top of that is the "constant dpi" patch: > https://xpra.org/trac/attachment/ticket/163/0002-Constant-DPI.patch > (note: this only benefits some applications - most notably Java ones) > > Cheers > Antoine > > OK thanks. Xpra server is running as shown here. Its own log file doesn't seem to react to the client connecting from below. bash-4.4$ ps aux | grep xpra bsferra+ 30529 0.3 0.0 2049496 53696 ? S 16:39 0:03 /home/tools/bin/python /home/tools/bin/xpra start :100 --start-child=xterm --socket-dirs=~/.xpra -d all --start-via-proxy=no bsferra+ 30530 0.3 0.0 668540 149992 ? Ssl 16:39 0:03 /home/tools/bin/Xorg-for-Xpra-:100 -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/bsferrazza/.Xauthority -logfile /home/tools/var/run/xpra/Xorg.:100.log -configdir /home/tools/var/run/xpra/xorg.conf.d/30529 -config /home/tools/etc/xpra/xorg.conf -depth 24 :100 Here's the relevant output from the client. The 'no run-xpra' command found seems to be the most glaring. 2018-03-06 08:44:03,407 io_thread_loop(read, ) loop starting 2018-03-06 08:44:04,408 set_icon(None) using filename=C:\Program Files\Xpra\icons\xpra.ico 2018-03-06 08:44:04,408 set_icon_from_file(C:\Program Files\Xpra\icons\xpra.ico) tray_widget= 2018-03-06 08:44:04,409 LoadImage(C:\Program Files\Xpra\icons\xpra.ico) using image type=ICON 2018-03-06 08:44:04,410 LoadImage(C:\Program Files\Xpra\icons\xpra.ico)=24971835 2018-03-06 08:44:04,410 do_set_icon(24971835) 2018-03-06 08:44:04,410 make_nid(..)= tooltip='ssh/l-server-13/:100', app_id=0, actual flags=ICON, GUID 2018-03-06 08:44:04,413 make_nid(..)= tooltip='ssh/l-server-13/:100', app_id=0, actual flags=ICON, GUID 2018-03-06 08:44:04,610 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 15132, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] 2018-03-06 08:44:06,612 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 15132, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] 2018-03-06 08:44:08,613 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 15132, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] 2018-03-06 08:44:10,614 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 15132, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] 2018-03-06 08:44:12,616 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 15132, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] 2018-03-06 08:44:12,787 read_parse_thread_loop starting 2018-03-06 08:44:12,788 check_server_echo(0) last=True, server_ok=True (last_ping_echoed_time=0) 2018-03-06 08:44:12,788 process_gibberish(['gibberish', "invalid packet header byte C: '436164656e636520' read buffer='Cadence digital tool setup\\n' (27 bytes)", 'Cadence digital tool setup\n']) 2018-03-06 08:44:12,789 Cadence digital tool setup 2018-03-06 08:44:12,789 GTKXpraClient.quit(9) current exit_code=None 2018-03-06 08:44:12,789 UIXpraClient.cleanup() 2018-03-06 08:44:12,789 stop_sending_webcam() 2018-03-06 08:44:12,789 do_stop_sending_webcam() device=None 2018-03-06 08:44:12,789 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 15132, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] 2018-03-06 08:44:12,789 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 15132, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] 2018-03-06 08:44:12,789 cleanup_printing() printing=True 2018-03-06 08:44:12,789 cancel_send_printers_timer() send_printers_timer=None 2018-03-06 08:44:12,790 PRINTER_ENUM_VALUES: {'ICON4': 262144, 'ICON5': 327680, 'ICON6': 393216, 'ICON7': 458752, 'REMOTE': 16, 'NAME': 8, 'ICON2': 131072, 'ICON3': 196608, 'DEFAULT': 1, 'ICON8': 524288, 'CONNECTIONS': 4, 'ICON1': 65536, 'CONTAINER': 32768, 'SHARED': 32, 'LOCAL': 2, 'EXPAND': 16384, 'NETWORK': 64} 2018-03-06 08:44:12,791 PRINTER_FLAGS=LOCAL, SHARED+NETWORK+CONNECTIONS 2018-03-06 08:44:12,791 PRINTER_ENUMS=[['LOCAL'], ['SHARED', 'NETWORK', 'CONNECTIONS']] 2018-03-06 08:44:12,791 cleanup_printing= 2018-03-06 08:44:12,791 XpraClientBase.cleanup() protocol=Protocol(Pipe(ssh/l-server-13/:100)) 2018-03-06 08:44:12,791 calling 2018-03-06 08:44:12,791 Protocol.close() closed=False, connection=Pipe(ssh/l-server-13/:100) 2018-03-06 08:44:12,791 Protocol.close() calling 2018-03-06 08:44:12,791 Pipe(ssh/l-server-13/:100).close() close callback=, readable=', mode 'rb' at 0x000000001a5c5a50>, writeable=', mode 'wb' at 0x000000001a5c59c0> 2018-03-06 08:44:12,791 Pipe(ssh/l-server-13/:100).close() calling 2018-03-06 08:44:12,807 read thread: eof 2018-03-06 08:44:12,808 io_thread_loop(read, ) loop ended, closed=True 2018-03-06 08:44:12,807 Pipe(ssh/l-server-13/:100).close() done 2018-03-06 08:44:12,808 terminate_queue_threads() 2018-03-06 08:44:12,808 write thread: empty marker, exiting 2018-03-06 08:44:12,809 Protocol.close() closed=True, connection=None 2018-03-06 08:44:12,809 Protocol.close() done 2018-03-06 08:44:12,809 io_thread_loop(write, ) loop ended, closed=True 2018-03-06 08:44:12,809 cleanup done From antoine at nagafix.co.uk Tue Mar 6 17:24:13 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Mar 2018 00:24:13 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> Message-ID: > OK thanks. Xpra server is running as shown here. Its own log file doesn't > seem to react to the client connecting from below. That's because it never gets a connection from the client, see below. So, it seems that you're using SSH. I always advise to try with plain TCP or SSL first before introducing a transport intermediary like SSH. (..) > Here's the relevant output from the client. The 'no run-xpra' command found > seems to be the most glaring. If you started the server using the same user account, it should have placed a "run-xpra" script in one of the locations that the client will attempt to use. From your debug output, this will include: ~/.xpra/run-xpra $XDG_RUNTIME_DIR/xpra/run-xpra xpra /usr/local/bin/xpra Note that XDG_RUNTIME_DIR may not be set when logging in via ssh if you had to hack it previously. But ~/.xpra/run-xpra should exist anyway. I'm just mentioning for completeness. (..) > 2018-03-06 08:44:04,610 poll() procinfo list: [ProcInfo({'returncode': > None, 'name': 'ssh', 'process': 0x000000001a2d3250>, 'pid': 15132, 'dead': False, 'ignore': True, > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', > 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then > ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; > then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then > /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit (..) > 2018-03-06 08:44:12,788 process_gibberish(['gibberish', "invalid packet > header byte C: '436164656e636520' read buffer='Cadence digital tool > setup\\n' (27 bytes)", 'Cadence digital tool setup\n']) And here is your problem. Something in your user environment is printing out some text to the SSH terminal connection which xpra uses to communicate with the xpra server. When it sees that this isn't xpra's protocol, it drops the connection. Either clean this up from your user's login scripts or use TCP / SSL connections instead. Cheers Antoine From bsferrazza at avnera.com Tue Mar 6 17:46:41 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Tue, 6 Mar 2018 09:46:41 -0800 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> Message-ID: On Tue, Mar 6, 2018 at 9:24 AM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > > OK thanks. Xpra server is running as shown here. Its own log file doesn't > > seem to react to the client connecting from below. > That's because it never gets a connection from the client, see below. > So, it seems that you're using SSH. I always advise to try with plain > TCP or SSL first before introducing a transport intermediary like SSH. > OK. I thought as a regular user I wouldn't have access to bind to TCP ports. I at least know I can SSH into these machines. > > (..) > > Here's the relevant output from the client. The 'no run-xpra' command > found > > seems to be the most glaring. > If you started the server using the same user account, it should have > placed a "run-xpra" script in one of the locations that the client will > attempt to use. From your debug output, this will include: > ~/.xpra/run-xpra > $XDG_RUNTIME_DIR/xpra/run-xpra > xpra > /usr/local/bin/xpra > > Note that XDG_RUNTIME_DIR may not be set when logging in via ssh if you > had to hack it previously. But ~/.xpra/run-xpra should exist anyway. > I'm just mentioning for completeness. > OK, yes those files do indeed exist. > > (..) > > 2018-03-06 08:44:04,610 poll() procinfo list: [ProcInfo({'returncode': > > None, 'name': 'ssh', 'process': > 0x000000001a2d3250>, 'pid': 15132, 'dead': False, 'ignore': True, > > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', > > 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then > > ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; > > then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > > > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; > then > > /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; > exit > (..) > > > 2018-03-06 08:44:12,788 process_gibberish(['gibberish', "invalid packet > > header byte C: '436164656e636520' read buffer='Cadence digital tool > > setup\\n' (27 bytes)", 'Cadence digital tool setup\n']) > And here is your problem. > Something in your user environment is printing out some text to the SSH > terminal connection which xpra uses to communicate with the xpra server. > When it sees that this isn't xpra's protocol, it drops the connection. > > Either clean this up from your user's login scripts or use TCP / SSL > connections instead. I commented out the line that sources a tool setup script (for Cadence CAD software that echos back stuff) in my shell rc file. I can now launch an xterm window!! Thank you. I suppose I can always source that too setup script on demand when I actually need it, as opposed to sourcing it always in my shell's rc file. From bsferrazza at avnera.com Tue Mar 6 19:20:45 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Tue, 6 Mar 2018 11:20:45 -0800 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: <814697f6-ca48-381e-3d09-df30056c957c@nagafix.co.uk> References: <814697f6-ca48-381e-3d09-df30056c957c@nagafix.co.uk> Message-ID: On Mon, Mar 5, 2018 at 8:07 PM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > > > >> 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! > Ah. In that case, you may prefer building trunk which supports a native > opengl backend that does not need pygtkgl. > Use it with: --opengl=native > Sorry for the basic question, but is this still just a client option? It's not something I would pass as an argument when building on the server side, correct? From antoine at nagafix.co.uk Wed Mar 7 02:39:44 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Mar 2018 09:39:44 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> Message-ID: On 07/03/18 00:46, Ben Sferrazza via shifter-users wrote: > On Tue, Mar 6, 2018 at 9:24 AM, Antoine Martin via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: > >>> OK thanks. Xpra server is running as shown here. Its own log file doesn't >>> seem to react to the client connecting from below. >> That's because it never gets a connection from the client, see below. >> So, it seems that you're using SSH. I always advise to try with plain >> TCP or SSL first before introducing a transport intermediary like SSH. >> > > OK. I thought as a regular user I wouldn't have access to bind to TCP > ports. I at least know I can SSH into these machines. Only ports lower than 1024 require special privileges. See CAP_NET_BIND_SERVICE on Linux. >>> 2018-03-06 08:44:04,610 poll() procinfo list: [ProcInfo({'returncode': >>> None, 'name': 'ssh', 'process': >> 0x000000001a2d3250>, 'pid': 15132, 'dead': False, 'ignore': True, >>> 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', >>> 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then >>> ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; >>> then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > >>> /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; >> then >>> /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; >> exit >> (..) >> >>> 2018-03-06 08:44:12,788 process_gibberish(['gibberish', "invalid packet >>> header byte C: '436164656e636520' read buffer='Cadence digital tool >>> setup\\n' (27 bytes)", 'Cadence digital tool setup\n']) >> And here is your problem. >> Something in your user environment is printing out some text to the SSH >> terminal connection which xpra uses to communicate with the xpra server. >> When it sees that this isn't xpra's protocol, it drops the connection. >> >> Either clean this up from your user's login scripts or use TCP / SSL >> connections instead. > > > I commented out the line that sources a tool setup script (for Cadence CAD > software that echos back stuff) in my shell rc file. I can now launch an > xterm window!! Thank you. I suppose I can always source that too setup > script on demand when I actually need it, as opposed to sourcing it always > in my shell's rc file. Or you can source it and redirect its output to a file or /dev/null Cheers Antoine From antoine at nagafix.co.uk Wed Mar 7 02:41:23 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Mar 2018 09:41:23 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <814697f6-ca48-381e-3d09-df30056c957c@nagafix.co.uk> Message-ID: On 07/03/18 02:20, Ben Sferrazza via shifter-users wrote: > On Mon, Mar 5, 2018 at 8:07 PM, Antoine Martin via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: > >> >> >>>> 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! >> Ah. In that case, you may prefer building trunk which supports a native >> opengl backend that does not need pygtkgl. >> Use it with: --opengl=native >> > > Sorry for the basic question, but is this still just a client option? It's > not something I would pass as an argument when building on the server side, > correct? Yes, as per the man page, the "opengl" option is an "option for attach". There is no such option when building. Cheers Antoine