Discussion:
[winswitch] Xpra GL and gtkglext woes
Ben Sferrazza via shifter-users
2018-03-05 17:38:31 UTC
Permalink
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 <gtk.gdk.Display object
at 0x2ae82f5ea050 (GdkDisplayX11 at 0x1b3be1f0)>, 12582913
2018-03-05 17:04:40,441 XError: XError: 3 processing CreateNotify
Traceback (most recent call last):
File "xpra/x11/gtk2/gdk_bindings.pyx", line 1062, in
xpra.x11.gtk2.gdk_bindings.parse_xevent
File "xpra/x11/gtk2/gdk_bindings.pyx", line 914, in
xpra.x11.gtk2.gdk_bindings._gw
XError: XError: 3
2018-03-05 17:04:40,442 Some window in our event disappeared before we
could handle the event 16/CreateNotify using ('xpra-create-event', None);
so I'm just ignoring it instead. python event=<X11:CreateNotify
{'delivered_to': '0x299', 'send_event': 0, 'serial': '0x36a', 'type': 16,
'display': ':100'}>

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 <module>
from xpra.client.gl.gtk_base.gtk_compat import MODE_RGBA, MODE_ALPHA,
MODE_RGB, MODE_DOUBLE, MODE_SINGLE, MODE_DEPTH
File "/home/tools/lib/python/xpra/client/gl/gtk_base/gtk_compat.py", line
59, in <module>
from gtk import gdkgl, gtkgl
File
"/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/__init__.py",
line 21, in <module>
from _gdkgl import *
ImportError:
/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/_gdkgl.so:
undefined symbol: gdk_window_is_gl_capable

When I run strings on that _gdkgl.so, I get the following

bash-4.4$ strings _gdkgl.so | grep gdk_window_is_gl_capable
gdk_window_is_gl_capable
_wrap_gdk_window_is_gl_capable
_wrap_gdk_window_is_gl_capable

and the function is defined in the following include file

/home/tools/include/gtkglext-1.0/gdk/gdkglwindow.h

bash-4.4$ grep gdk_window_is_gl_capable gdkglwindow.h
gboolean gdk_window_is_gl_capable (GdkWindow *window);

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
Antoine Martin via shifter-users
2018-03-05 19:50:05 UTC
Permalink
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
I have built Mesa, and am using the Xdummy xorg.conf. All seems well, but
the Xpra client never showed the --start-child app of konsole. It had
errors like this.
2018-03-05 17:04:40,440 x_event_filter event=('xpra-create-event',
None)/CreateNotify window=0x299
2018-03-05 17:04:40,440 cannot get gdk window for <gtk.gdk.Display object
at 0x2ae82f5ea050 (GdkDisplayX11 at 0x1b3be1f0)>, 12582913
2018-03-05 17:04:40,441 XError: XError: 3 processing CreateNotify
File "xpra/x11/gtk2/gdk_bindings.pyx", line 1062, in
xpra.x11.gtk2.gdk_bindings.parse_xevent
File "xpra/x11/gtk2/gdk_bindings.pyx", line 914, in
xpra.x11.gtk2.gdk_bindings._gw
XError: XError: 3
2018-03-05 17:04:40,442 Some window in our event disappeared before we
could handle the event 16/CreateNotify using ('xpra-create-event', None);
so I'm just ignoring it instead. python event=<X11:CreateNotify
{'delivered_to': '0x299', 'send_event': 0, 'serial': '0x36a', 'type': 16,
'display': ':100'}>
Error 3 is BadWindow. This usually means that the window got destroyed
before we could get hold of it. (X11 is asynchronous)
I assume that you got this error in your server log with some debug
flags enabled, right?
Post by Ben Sferrazza via shifter-users
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)
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
But now I get
this mysterious ImportError
File "/home/tools/lib/python/xpra/scripts/main.py", line 175, in main
return run_mode(script_file, err, options, args, mode, defaults)
File "/home/tools/lib/python/xpra/scripts/main.py", line 1517, in run_mode
return run_glcheck(options)
File "/home/tools/lib/python/xpra/scripts/main.py", line 2723, in
run_glcheck
from xpra.client.gl.gtk_base.gtkgl_check import check_support
File "/home/tools/lib/python/xpra/client/gl/gtk_base/gtkgl_check.py",
line 35, in <module>
from xpra.client.gl.gtk_base.gtk_compat import MODE_RGBA, MODE_ALPHA,
MODE_RGB, MODE_DOUBLE, MODE_SINGLE, MODE_DEPTH
File "/home/tools/lib/python/xpra/client/gl/gtk_base/gtk_compat.py", line
59, in <module>
from gtk import gdkgl, gtkgl
File
"/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/__init__.py",
line 21, in <module>
from _gdkgl import *
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.
Post by Ben Sferrazza via shifter-users
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
Post by Ben Sferrazza via shifter-users
Ben
_______________________________________________
shifter-users mailing list
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
Ben Sferrazza via shifter-users
2018-03-05 21:25:25 UTC
Permalink
On Mon, Mar 5, 2018 at 11:50 AM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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
Post by Ben Sferrazza via shifter-users
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.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
I have built Mesa, and am using the Xdummy xorg.conf. All seems well, but
the Xpra client never showed the --start-child app of konsole. It had
errors like this.
2018-03-05 17:04:40,440 x_event_filter event=('xpra-create-event',
None)/CreateNotify window=0x299
2018-03-05 17:04:40,440 cannot get gdk window for <gtk.gdk.Display object
at 0x2ae82f5ea050 (GdkDisplayX11 at 0x1b3be1f0)>, 12582913
2018-03-05 17:04:40,441 XError: XError: 3 processing CreateNotify
File "xpra/x11/gtk2/gdk_bindings.pyx", line 1062, in
xpra.x11.gtk2.gdk_bindings.parse_xevent
File "xpra/x11/gtk2/gdk_bindings.pyx", line 914, in
xpra.x11.gtk2.gdk_bindings._gw
XError: XError: 3
2018-03-05 17:04:40,442 Some window in our event disappeared before we
could handle the event 16/CreateNotify using ('xpra-create-event', None);
so I'm just ignoring it instead. python event=<X11:CreateNotify
{'delivered_to': '0x299', 'send_event': 0, 'serial': '0x36a', 'type': 16,
'display': ':100'}>
Error 3 is BadWindow. This usually means that the window got destroyed
before we could get hold of it. (X11 is asynchronous)
I assume that you got this error in your server log with some debug
flags enabled, right?
correct. I start xpra using '-d all'

xpra start :100 --start-child=xterm --socket-dirs=~/.xpra -d all
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
But now I get
this mysterious ImportError
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
Post by Ben Sferrazza via shifter-users
return run_glcheck(options)
File "/home/tools/lib/python/xpra/scripts/main.py", line 2723, in
run_glcheck
from xpra.client.gl.gtk_base.gtkgl_check import check_support
File "/home/tools/lib/python/xpra/client/gl/gtk_base/gtkgl_check.py",
line 35, in <module>
from xpra.client.gl.gtk_base.gtk_compat import MODE_RGBA,
MODE_ALPHA,
Post by Ben Sferrazza via shifter-users
MODE_RGB, MODE_DOUBLE, MODE_SINGLE, MODE_DEPTH
File "/home/tools/lib/python/xpra/client/gl/gtk_base/gtk_compat.py",
line
Post by Ben Sferrazza via shifter-users
59, in <module>
from gtk import gdkgl, gtkgl
File
"/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/__init__.py",
line 21, in <module>
from _gdkgl import *
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/"
Post by Antoine Martin via shifter-users
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.
Post by Ben Sferrazza via shifter-users
Perhaps the issue of not getting a window drawn is unrelated to the
ImportError, but I'd like to fix both of these issues. Thank you for any
help in solving this!
Is the window not being drawn, or not being shown at all?
Are you sure that the application (konsole in this case) is still
running and hasn't just crashed?
The best way to debug this is to launch an xterm instead, then run your
applications from there. Or maybe even with gdb if it does crash.
konsole is just the KDE terminal program. But good point. Changing it to
xterm seems to suggest I'm not even connecting. I am prompted for my
password and the Xpra client (Windows) disappears. Seems to be running as
per taskmgr, but the tray icon goes away.

Here's where the child process is executed.

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

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

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

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

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

2018-03-05 21:16:04,755 get_enabled_encoders(['rencode', 'bencode',
'yaml']) enabled=['yaml', 'rencode', 'bencode']
2018-03-05 21:16:04,799 netifaces loaded sucessfully
2018-03-05 21:16:04,799 successfully loaded socket C library from libc.so.6
2018-03-05 21:16:04,804 failed to connect using <bound method
_socketobject.connect of <socket._socketobject object at
0x2b9f9143e520>>/run/xpra/system
Traceback (most recent call last):
File "/home/tools/lib/python/xpra/scripts/main.py", line 1910, in
_socket_connect
sock.connect(endpoint)
File "/home/tools/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
error: [Errno 2] No such file or directory
Warning: cannot use the system proxy for 'start' subcommand,
failed to connect to '/run/xpra/system':
[Errno 2] No such file or directory
Post by Antoine Martin via shifter-users
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!
Post by Antoine Martin via shifter-users
Cheers
Antoine
Ben Sferrazza via shifter-users
2018-03-05 22:02:34 UTC
Permalink
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)
Post by Ben Sferrazza via shifter-users
On Mon, Mar 5, 2018 at 11:50 AM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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
Post by Ben Sferrazza via shifter-users
works well, even having built Xorg, GTK+2/3, and GUI applications. I
made
Post by Ben Sferrazza via shifter-users
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.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
I have built Mesa, and am using the Xdummy xorg.conf. All seems well,
but
Post by Ben Sferrazza via shifter-users
the Xpra client never showed the --start-child app of konsole. It had
errors like this.
2018-03-05 17:04:40,440 x_event_filter event=('xpra-create-event',
None)/CreateNotify window=0x299
2018-03-05 17:04:40,440 cannot get gdk window for <gtk.gdk.Display
object
Post by Ben Sferrazza via shifter-users
at 0x2ae82f5ea050 (GdkDisplayX11 at 0x1b3be1f0)>, 12582913
2018-03-05 17:04:40,441 XError: XError: 3 processing CreateNotify
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);
Post by Ben Sferrazza via shifter-users
so I'm just ignoring it instead. python event=<X11:CreateNotify
16,
Post by Ben Sferrazza via shifter-users
'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
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
But now I get
this mysterious ImportError
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
Post by Ben Sferrazza via shifter-users
return run_glcheck(options)
File "/home/tools/lib/python/xpra/scripts/main.py", line 2723, in
run_glcheck
from xpra.client.gl.gtk_base.gtkgl_check import check_support
File "/home/tools/lib/python/xpra/client/gl/gtk_base/gtkgl_check.py",
line 35, in <module>
from xpra.client.gl.gtk_base.gtk_compat import MODE_RGBA,
MODE_ALPHA,
Post by Ben Sferrazza via shifter-users
MODE_RGB, MODE_DOUBLE, MODE_SINGLE, MODE_DEPTH
File "/home/tools/lib/python/xpra/client/gl/gtk_base/gtk_compat.py",
line
Post by Ben Sferrazza via shifter-users
59, in <module>
from gtk import gdkgl, gtkgl
File
"/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/_
_init__.py",
Post by Ben Sferrazza via shifter-users
line 21, in <module>
from _gdkgl import *
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/"
Post by Antoine Martin via shifter-users
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.
Post by Ben Sferrazza via shifter-users
Perhaps the issue of not getting a window drawn is unrelated to the
ImportError, but I'd like to fix both of these issues. Thank you for any
help in solving this!
Is the window not being drawn, or not being shown at all?
Are you sure that the application (konsole in this case) is still
running and hasn't just crashed?
The best way to debug this is to launch an xterm instead, then run your
applications from there. Or maybe even with gdb if it does crash.
konsole is just the KDE terminal program. But good point. Changing it to
xterm seems to suggest I'm not even connecting. I am prompted for my
password and the Xpra client (Windows) disappears. Seems to be running as
per taskmgr, but the tray icon goes away.
Here's where the child process is executed.
2018-03-05 20:25:44,790 exec_start_commands() start=[],
start_child=['xterm']
2018-03-05 20:25:44,790 start_child('xterm', 'xterm', False, None, True,
None, {})
2018-03-05 20:25:44,791 threaded_init() start
2018-03-05 20:25:44,796 add_process(<subprocess.Popen object at
0x2ba85fca5cd0>, xterm, ['xterm'], False, False) pid=7293
2018-03-05 20:25:44,797 pid(['xterm'])=7293
2018-03-05 20:25:44,797 started command 'xterm' with pid 7293
None, 'name': 'xterm', 'process': <subprocess.Popen object at
None, 'command': ['xterm'], 'forget': False})]
2018-03-05 20:25:44,797 guess_session_name() commands=['xterm']
2018-03-05 20:25:44,797 <bound method XpraServer.init_sockets of
<XpraServer object at 0x2ba85a41b460 (xpra+x11+server+XpraServer at
0xc9849a0)>>([('unix-domain', <socket._socketobject object at
0x2ba857935d00>, '/home/bsferrazza/.xpra/l-server-13-100')])
2018-03-05 20:25:44,798 init_sockets([('unix-domain',
<socket._socketobject object at 0x2ba857935d00>, '/home/bsferrazza/.xpra/l-server-13-100')])
will add unix-domain socket <socket._socketobject object at 0x2ba857935d00>
(/home/bsferrazza/.xpra/l-server-13-100)
2018-03-05 20:25:44,798 added unix socket path: /home/bsferrazza/.xpra/l-
server-13-100
['/home/bsferrazza/.xpra/l-server-13-100']
2018-03-05 20:25:44,798 <bound method XpraServer.init_when_ready of
<XpraServer object at 0x2ba85a41b460 (xpra+x11+server+XpraServer at
0xc9849a0)>>([])
2018-03-05 20:25:44,798 running <bound method XpraServer.run of
<XpraServer object at 0x2ba85a41b460 (xpra+x11+server+XpraServer at
0xc9849a0)>>
2018-03-05 20:25:44,799 xpra X11 version 2.2.4-r18312 64-bit
2018-03-05 20:25:44,801 uid=10345 (bsferrazza), gid=1001 (eng)
2018-03-05 20:25:44,801 running with pid 6769 on Linux CentOS 5.11 Final
2018-03-05 20:25:44,802 connected to X11 display :100 with 24 bit colors
2018-03-05 20:25:44,802 do_run() calling <function gtk_main at
0x2ba84d7a52a8>
None, 'name': 'xterm', 'process': <subprocess.Popen object at
None, 'command': ['xterm'], 'forget': False})]
2018-03-05 20:25:44,803 check() alive=[ProcInfo({'returncode': None,
'name': 'xterm', 'process': <subprocess.Popen object at 0x2ba85fca5cd0>,
['xterm'], 'forget': False})], quit callback=None
2018-03-05 20:25:44,803 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x400001
2018-03-05 20:25:44,803 parse_event(..)=<X11:PropertyNotify
'_NET_WM_NAME', 'serial': '0x3a', 'type': 28, 'display': ':100'}>
2018-03-05 20:25:44,804 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.8ms
2018-03-05 20:25:44,804 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x400001
2018-03-05 20:25:44,804 parse_event(..)=<X11:PropertyNotify
'WM_NAME', 'serial': '0x3b', 'type': 28, 'display': ':100'}>
2018-03-05 20:25:44,804 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.6ms
2018-03-05 20:25:44,805 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x400001
The bottom of the log file, before and even after attempting a connection
still just shows this.
2018-03-05 21:16:09,763 sigchld(17, <frame object at 0x2acc79900238>)
None, 'name': 'xterm', 'process': <subprocess.Popen object at
None, 'command': ['xterm'], 'forget': False})]
2018-03-05 21:16:09,763 reap() calling os.waitpid(-1, 'WNOHANG')
2018-03-05 21:16:09,763 reap() waitpid=0
2018-03-05 21:16:09,764 add_listen_socket(unix-domain,
<socket._socketobject object at 0x2acc8633ad00>)
info=/home/bsferrazza/.xpra/l-server-13-100
2018-03-05 21:16:09,764 reset_server_timeout(True) server_idle_timeout=0,
server_idle_timer=None
2018-03-05 21:16:09,764 xpra is ready.
2018-03-05 21:16:09,764 org.xpra.Server.Event(ready, [])
2018-03-05 21:16:09,764 server-event: ('ready',)
So it's as though it's not even aware of the attempt client connection?
It's probably unrelated but I receive this error immediately when starting
Xpra. This again is run as non-root. I have XDG_RUNTIME_DIR set to a path
in my home directory. So I'm not sure why it's still attempting to access
/run/xpra/system
2018-03-05 21:16:04,755 get_enabled_encoders(['rencode', 'bencode',
'yaml']) enabled=['yaml', 'rencode', 'bencode']
2018-03-05 21:16:04,799 netifaces loaded sucessfully
2018-03-05 21:16:04,799 successfully loaded socket C library from libc.so.6
2018-03-05 21:16:04,804 failed to connect using <bound method
_socketobject.connect of <socket._socketobject object at
0x2b9f9143e520>>/run/xpra/system
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,
[Errno 2] No such file or directory
Post by Antoine Martin via shifter-users
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!
Post by Antoine Martin via shifter-users
Cheers
Antoine
Ben Sferrazza via shifter-users
2018-03-05 22:41:27 UTC
Permalink
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: <class 'socket.error'>, 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=<bound method WindowVideoSource.get_best_encoding_video
of WindowVideoSource(1 : (499, 316))>
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 <bound method
SocketConnection.close of unix-domain
socket:/home/bsferrazza/.xpra/l-server-13-100>
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 <gtk.IconTheme object at 0x2b630536bf50
(GtkIconTheme at 0x13f99b00)>.lookup_icon(xterm-color)=None
2018-03-05 22:34:20,535 <gtk.IconTheme object at 0x2b630536bf50
(GtkIconTheme at 0x13f99b00)>.lookup_icon(xterm)=None
2018-03-05 22:34:20,535 <gtk.IconTheme object at 0x2b630536bf50
(GtkIconTheme at 0x13f99b00)>.lookup_icon(xterm_48x48)=None
2018-03-05 22:34:20,535 <gtk.IconTheme object at 0x2b630536bf50
(GtkIconTheme at 0x13f99b00)>.lookup_icon(application-x-xterm)=None
2018-03-05 22:34:20,535 <gtk.IconTheme object at 0x2b630536bf50
(GtkIconTheme at 0x13f99b00)>.lookup_icon(xterm-symbolic)=None
2018-03-05 22:34:20,535 <gtk.IconTheme object at 0x2b630536bf50
(GtkIconTheme at 0x13f99b00)>.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
Post by Ben Sferrazza via shifter-users
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.
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
${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] 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
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)
Post by Ben Sferrazza via shifter-users
On Mon, Mar 5, 2018 at 11:50 AM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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
Post by Ben Sferrazza via shifter-users
works well, even having built Xorg, GTK+2/3, and GUI applications. I
made
Post by Ben Sferrazza via shifter-users
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.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
I have built Mesa, and am using the Xdummy xorg.conf. All seems well,
but
Post by Ben Sferrazza via shifter-users
the Xpra client never showed the --start-child app of konsole. It had
errors like this.
2018-03-05 17:04:40,440 x_event_filter event=('xpra-create-event',
None)/CreateNotify window=0x299
2018-03-05 17:04:40,440 cannot get gdk window for <gtk.gdk.Display
object
Post by Ben Sferrazza via shifter-users
at 0x2ae82f5ea050 (GdkDisplayX11 at 0x1b3be1f0)>, 12582913
2018-03-05 17:04:40,441 XError: XError: 3 processing CreateNotify
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);
Post by Ben Sferrazza via shifter-users
so I'm just ignoring it instead. python event=<X11:CreateNotify
16,
Post by Ben Sferrazza via shifter-users
'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
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
But now I get
this mysterious ImportError
File "/home/tools/lib/python/xpra/scripts/main.py", line 175, in
main
Post by Ben Sferrazza via shifter-users
return run_mode(script_file, err, options, args, mode, defaults)
File "/home/tools/lib/python/xpra/scripts/main.py", line 1517, in
run_mode
Post by Ben Sferrazza via shifter-users
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",
Post by Ben Sferrazza via shifter-users
line 35, in <module>
from xpra.client.gl.gtk_base.gtk_compat import MODE_RGBA,
MODE_ALPHA,
Post by Ben Sferrazza via shifter-users
MODE_RGB, MODE_DOUBLE, MODE_SINGLE, MODE_DEPTH
File "/home/tools/lib/python/xpra/client/gl/gtk_base/gtk_compat.py",
line
Post by Ben Sferrazza via shifter-users
59, in <module>
from gtk import gdkgl, gtkgl
File
"/home/tools/lib/python2.7/site-packages/gtk-2.0/gtk/gdkgl/_
_init__.py",
Post by Ben Sferrazza via shifter-users
line 21, in <module>
from _gdkgl import *
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/"
Post by Antoine Martin via shifter-users
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.
Post by Ben Sferrazza via shifter-users
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
Post by Ben Sferrazza via shifter-users
help in solving this!
Is the window not being drawn, or not being shown at all?
Are you sure that the application (konsole in this case) is still
running and hasn't just crashed?
The best way to debug this is to launch an xterm instead, then run your
applications from there. Or maybe even with gdb if it does crash.
konsole is just the KDE terminal program. But good point. Changing it to
xterm seems to suggest I'm not even connecting. I am prompted for my
password and the Xpra client (Windows) disappears. Seems to be running as
per taskmgr, but the tray icon goes away.
Here's where the child process is executed.
2018-03-05 20:25:44,790 exec_start_commands() start=[],
start_child=['xterm']
2018-03-05 20:25:44,790 start_child('xterm', 'xterm', False, None, True,
None, {})
2018-03-05 20:25:44,791 threaded_init() start
2018-03-05 20:25:44,796 add_process(<subprocess.Popen object at
0x2ba85fca5cd0>, xterm, ['xterm'], False, False) pid=7293
2018-03-05 20:25:44,797 pid(['xterm'])=7293
2018-03-05 20:25:44,797 started command 'xterm' with pid 7293
None, 'name': 'xterm', 'process': <subprocess.Popen object at
None, 'command': ['xterm'], 'forget': False})]
2018-03-05 20:25:44,797 guess_session_name() commands=['xterm']
2018-03-05 20:25:44,797 <bound method XpraServer.init_sockets of
<XpraServer object at 0x2ba85a41b460 (xpra+x11+server+XpraServer at
0xc9849a0)>>([('unix-domain', <socket._socketobject object at
0x2ba857935d00>, '/home/bsferrazza/.xpra/l-server-13-100')])
2018-03-05 20:25:44,798 init_sockets([('unix-domain',
<socket._socketobject object at 0x2ba857935d00>,
'/home/bsferrazza/.xpra/l-server-13-100')]) will add unix-domain socket
<socket._socketobject object at 0x2ba857935d00>
(/home/bsferrazza/.xpra/l-server-13-100)
/home/bsferrazza/.xpra/l-server-13-100
['/home/bsferrazza/.xpra/l-server-13-100']
2018-03-05 20:25:44,798 <bound method XpraServer.init_when_ready of
<XpraServer object at 0x2ba85a41b460 (xpra+x11+server+XpraServer at
0xc9849a0)>>([])
2018-03-05 20:25:44,798 running <bound method XpraServer.run of
<XpraServer object at 0x2ba85a41b460 (xpra+x11+server+XpraServer at
0xc9849a0)>>
2018-03-05 20:25:44,799 xpra X11 version 2.2.4-r18312 64-bit
2018-03-05 20:25:44,801 uid=10345 (bsferrazza), gid=1001 (eng)
2018-03-05 20:25:44,801 running with pid 6769 on Linux CentOS 5.11 Final
2018-03-05 20:25:44,802 connected to X11 display :100 with 24 bit colors
2018-03-05 20:25:44,802 do_run() calling <function gtk_main at
0x2ba84d7a52a8>
None, 'name': 'xterm', 'process': <subprocess.Popen object at
None, 'command': ['xterm'], 'forget': False})]
2018-03-05 20:25:44,803 check() alive=[ProcInfo({'returncode': None,
'name': 'xterm', 'process': <subprocess.Popen object at 0x2ba85fca5cd0>,
['xterm'], 'forget': False})], quit callback=None
2018-03-05 20:25:44,803 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x400001
2018-03-05 20:25:44,803 parse_event(..)=<X11:PropertyNotify
'_NET_WM_NAME', 'serial': '0x3a', 'type': 28, 'display': ':100'}>
2018-03-05 20:25:44,804 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.8ms
2018-03-05 20:25:44,804 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x400001
2018-03-05 20:25:44,804 parse_event(..)=<X11:PropertyNotify
'WM_NAME', 'serial': '0x3b', 'type': 28, 'display': ':100'}>
2018-03-05 20:25:44,804 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.6ms
2018-03-05 20:25:44,805 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x400001
The bottom of the log file, before and even after attempting a connection
still just shows this.
2018-03-05 21:16:09,763 sigchld(17, <frame object at 0x2acc79900238>)
None, 'name': 'xterm', 'process': <subprocess.Popen object at
None, 'command': ['xterm'], 'forget': False})]
2018-03-05 21:16:09,763 reap() calling os.waitpid(-1, 'WNOHANG')
2018-03-05 21:16:09,763 reap() waitpid=0
2018-03-05 21:16:09,764 add_listen_socket(unix-domain,
<socket._socketobject object at 0x2acc8633ad00>)
info=/home/bsferrazza/.xpra/l-server-13-100
2018-03-05 21:16:09,764 reset_server_timeout(True) server_idle_timeout=0,
server_idle_timer=None
2018-03-05 21:16:09,764 xpra is ready.
2018-03-05 21:16:09,764 org.xpra.Server.Event(ready, [])
2018-03-05 21:16:09,764 server-event: ('ready',)
So it's as though it's not even aware of the attempt client connection?
It's probably unrelated but I receive this error immediately when
starting Xpra. This again is run as non-root. I have XDG_RUNTIME_DIR set to
a path in my home directory. So I'm not sure why it's still attempting to
access /run/xpra/system
2018-03-05 21:16:04,755 get_enabled_encoders(['rencode', 'bencode',
'yaml']) enabled=['yaml', 'rencode', 'bencode']
2018-03-05 21:16:04,799 netifaces loaded sucessfully
2018-03-05 21:16:04,799 successfully loaded socket C library from libc.so.6
2018-03-05 21:16:04,804 failed to connect using <bound method
_socketobject.connect of <socket._socketobject object at
0x2b9f9143e520>>/run/xpra/system
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,
[Errno 2] No such file or directory
Post by Antoine Martin via shifter-users
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!
Post by Antoine Martin via shifter-users
Cheers
Antoine
Antoine Martin via shifter-users
2018-03-06 04:10:11 UTC
Permalink
Post by Ben Sferrazza via shifter-users
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.
(..)
Post by Ben Sferrazza via shifter-users
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
Antoine Martin via shifter-users
2018-03-06 04:10:39 UTC
Permalink
Post by Ben Sferrazza via shifter-users
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.
(..)
Post by Ben Sferrazza via shifter-users
[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.
(..)
Post by Ben Sferrazza via shifter-users
[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".
(..)
Post by Ben Sferrazza via shifter-users
[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
Ben Sferrazza via shifter-users
2018-03-06 04:55:46 UTC
Permalink
On Mon, Mar 5, 2018 at 8:10 PM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
(..)
Post by Ben Sferrazza via shifter-users
[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)
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
[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?
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
[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,
Post by Ben Sferrazza via shifter-users
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
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
Antoine Martin via shifter-users
2018-03-06 08:33:51 UTC
Permalink
Post by Ben Sferrazza via shifter-users
On Mon, Mar 5, 2018 at 8:10 PM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
(..)
Post by Ben Sferrazza via shifter-users
[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.
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
[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
Ben Sferrazza via shifter-users
2018-03-06 17:00:25 UTC
Permalink
On Tue, Mar 6, 2018 at 12:33 AM, Antoine Martin via shifter-users <
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
On Mon, Mar 5, 2018 at 8:10 PM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Figured I'd add the Xorg log file, with the Modeline lines stripped
out.
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Not sure why it's trying to load libinput when it's using the
dummy_mouse
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
and dummy_keyboard.
(..)
Post by Ben Sferrazza via shifter-users
[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
Post by Ben Sferrazza via shifter-users
it with (...)/etc/xpra/xorg.conf. No more void module errors, but I do
see
Post by Ben Sferrazza via shifter-users
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)
Post by Ben Sferrazza via shifter-users
[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,
Post by Ben Sferrazza via shifter-users
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,
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
[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
Post by Ben Sferrazza via shifter-users
in my first email?
Assuming that you've built the latest 0.3.8 version of the dummy driver,
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, <bound method Protocol._read
of Protocol(Pipe(ssh/l-server-13/:100))>) 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=<xpra.platform.win32.win32_NotifyIcon.win32NotifyIcon object at
0x000000001a6db210>
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(..)=<xpra.platform.win32.win32_NotifyIcon.NOTIFYICONDATA object at
0x000000001a86c950> tooltip='ssh/l-server-13/:100', app_id=0, actual
flags=ICON, GUID
2018-03-06 08:44:04,413
make_nid(..)=<xpra.platform.win32.win32_NotifyIcon.NOTIFYICONDATA object at
0x000000001a86c950> 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': <subprocess.Popen object at
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
1; fi'], 'forget': False})]
2018-03-06 08:44:06,612 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'ssh', 'process': <subprocess.Popen object at
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
1; fi'], 'forget': False})]
2018-03-06 08:44:08,613 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'ssh', 'process': <subprocess.Popen object at
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
1; fi'], 'forget': False})]
2018-03-06 08:44:10,614 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'ssh', 'process': <subprocess.Popen object at
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
1; fi'], 'forget': False})]
2018-03-06 08:44:12,616 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'ssh', 'process': <subprocess.Popen object at
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
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': <subprocess.Popen object at
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
1; fi'], 'forget': False})]
2018-03-06 08:44:12,789 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'ssh', 'process': <subprocess.Popen object at
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
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=<function cleanup_printing at
0x000000001a8e6cf8>
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 <bound method Protocol.close of
Protocol(Pipe(ssh/l-server-13/:100))>
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 <bound method
TwoFileConnection.close of Pipe(ssh/l-server-13/:100)>
2018-03-06 08:44:12,791 Pipe(ssh/l-server-13/:100).close() close
callback=<function stop_tunnel at 0x000000001a2cc410>, readable=<open file
'<fdopen>', mode 'rb' at 0x000000001a5c5a50>, writeable=<open file
'<fdopen>', mode 'wb' at 0x000000001a5c59c0>
2018-03-06 08:44:12,791 Pipe(ssh/l-server-13/:100).close() calling
<function stop_tunnel at 0x000000001a2cc410>
2018-03-06 08:44:12,807 read thread: eof
2018-03-06 08:44:12,808 io_thread_loop(read, <bound method Protocol._read
of Protocol(None)>) 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, <bound method Protocol._write
of Protocol(None)>) loop ended, closed=True
2018-03-06 08:44:12,809 cleanup done
Antoine Martin via shifter-users
2018-03-06 17:24:13 UTC
Permalink
This post might be inappropriate. Click to display it.
Ben Sferrazza via shifter-users
2018-03-06 17:46:41 UTC
Permalink
On Tue, Mar 6, 2018 at 9:24 AM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
Here's the relevant output from the client. The 'no run-xpra' command
found
Post by Ben Sferrazza via shifter-users
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
~/.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.
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
None, 'name': 'ssh', 'process': <subprocess.Popen object at
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
Post by Ben Sferrazza via shifter-users
/usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found";
exit
(..)
Post by Ben Sferrazza via shifter-users
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.
Antoine Martin via shifter-users
2018-03-07 02:39:44 UTC
Permalink
Post by Ben Sferrazza via shifter-users
On Tue, Mar 6, 2018 at 9:24 AM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
None, 'name': 'ssh', 'process': <subprocess.Popen object at
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
Post by Ben Sferrazza via shifter-users
/usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found";
exit
(..)
Post by Ben Sferrazza via shifter-users
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
Ben Sferrazza via shifter-users
2018-08-28 20:23:41 UTC
Permalink
Hi. I'm including my previous correspondence below, as it will at least
offer some history about my setup and prior issues.

I stopped using Xpra a few months ago due to numerous bugs that made it
unusable (this is using a Linux server and Windows client).

1. windows get stuck with on-top focus
2. disappearing mouse cursor when using X11-only no-toolkit apps that use
inverted black mouse pointer after clicking on something
3. some windows don't show window bar until resized (e.g. gvim always gets
placed in upper-left without window bar)
4. dialog box black bars (appears to be trying to add scrollbars?).
5. windows are all blank (white) when returning into work after several
hours (requires restarting client)
6. flickering clipboard icon in systray

I'm inclined to give Xpra another chance, with the newer versions, and can
hopefully provide actual debugging log information for these bugs to be
fixed (if they haven't already).

But I'm now not even able to connect to the server from the client using
version 2.3.3. It reports Connection Lost immediately. I can ssh into the
same host without issue. And have made sure that the shell rc file no
longer outputs anything, which was the source of my issue a few months ago.
I have included the relevant sections of the server log and client log
below.

*Server Log:*
2018-08-28 18:44:12,058 add_listen_socket(unix-domain,
<socket._socketobject object at 0x2b6ceb374f30>)
info=/home/bsferrazza/.local/run/xpra/l-server-13-100
2018-08-28 18:44:12,058 add_listen_socket(unix-domain,
<socket._socketobject object at 0x2b6ceb374fa0>)
info=/home/bsferrazza/.xpra/l-server-13-100
2018-08-28 18:44:12,059 reset_server_timeout(True) server_idle_timeout=0,
server_idle_timer=None
2018-08-28 18:44:12,059 add_process(<subprocess.Popen object at
0x2b6cf2e9eb10>, xterm, ['xterm'], True, False) pid=17703
2018-08-28 18:44:12,059 xpra is ready.
2018-08-28 18:44:12,059 pid(['xterm'])=17703
2018-08-28 18:44:12,060 org.xpra.Server.Event(ready, [])
2018-08-28 18:44:12,060 VideoHelper.init()
2018-08-28 18:44:12,061 server-event: ('ready',)
2018-08-28 18:44:12,061 VideoHelper.init() initialized=False
2018-08-28 18:44:12,061 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'xterm', 'process': <subprocess.Popen object at
0x2b6cf2e9eb10>, 'pid': 17703, 'dead': False, 'ignore': True, 'callback':
None, 'command': ['xterm'], 'forget': False})]
2018-08-28 18:44:12,061 init_video_encoders_options()
2018-08-28 18:44:12,062 will try video encoders: x264, vpx
2018-08-28 18:44:12,062 guess_session_name() commands=['xterm']
2018-08-28 18:44:12,062 modules for x264: enc_x264
2018-08-28 18:44:12,062 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'xterm', 'process': <subprocess.Popen object at
0x2b6cf2e9eb10>, 'pid': 17703, 'dead': False, 'ignore': True, 'callback':
None, 'command': ['xterm'], 'forget': False})]
2018-08-28 18:44:12,063 init_video_encoder_option(enc_x264)
2018-08-28 18:44:12,063 check() alive=[], quit callback=<bound method
XpraServer.reaper_exit of <XpraServer object at 0x2b6ced9f70a0
(xpra+x11+server+XpraServer at 0x7570e60)>>
2018-08-28 18:44:12,063 module=<module 'xpra.codecs.enc_x264.encoder' from
'/home/tools/lib/python/xpra/codecs/enc_x264/encoder.so'>
2018-08-28 18:44:12,064 enc_x264.init_module()
2018-08-28 18:44:12,064 x264 encodings=h264
2018-08-28 18:44:12,064 x264 input colorspaces for h264: BGRX, YUV422P,
YUV420P, BGRA, YUV444P
2018-08-28 18:44:12,064 modules for vpx: enc_vpx
2018-08-28 18:44:12,064 init_video_encoder_option(enc_vpx)
2018-08-28 18:44:12,065 module=<module 'xpra.codecs.vpx.encoder' from
'/home/tools/lib/python/xpra/codecs/vpx/encoder.so'>
2018-08-28 18:44:12,065 vpx_codec_version_str()=v1.7.0
2018-08-28 18:44:12,065 vpx.encoder.init_module() info={'vp9.max-size':
(8192, 4096), 'generation': 3, 'vp8.colorspaces': ['YUV420P'], 'version':
'v1.7.0', 'abi_version': 14, 'encodings': ['vp8', 'vp9'], 'vp8.max-size':
(8192, 4096), 'build_config': '--prefix=/home/tools --enable-shared
--disable-static', 'vp9.colorspaces': ['YUV420P', 'YUV444P']}
2018-08-28 18:44:12,065 supported codecs: ['vp8', 'vp9']
2018-08-28 18:44:12,065 supported colorspaces: {'vp9': ['YUV420P',
'YUV444P'], 'vp8': ['YUV420P']}
2018-08-28 18:44:12,065 vpx encodings=vp8, vp9
2018-08-28 18:44:12,065 vpx input colorspaces for vp8: YUV420P
2018-08-28 18:44:12,066 vpx input colorspaces for vp9: YUV420P, YUV444P
2018-08-28 18:44:12,066 found 3 video encoders: h264, vp9, vp8
2018-08-28 18:44:12,066 init_csc_options()
2018-08-28 18:44:12,066 will try csc modules:
2018-08-28 18:44:12,066 csc specs:
2018-08-28 18:44:12,066 init_video_decoders_options()
2018-08-28 18:44:12,066 will try video decoders:
2018-08-28 18:44:12,066 found 0 video decoders:
2018-08-28 18:44:12,067 VideoHelper.init() done
2018-08-28 18:44:12,067 init_encodings() adding video encodings: ('h264',
'vp9', 'vp8')
2018-08-28 18:44:12,067 found lossless mode for encoding h264 with
video_spec(x264) and colorspace YUV444P
2018-08-28 18:44:12,067 allowed encodings=['h264', 'vp9', 'vp8', 'mpeg4',
'mpeg4+mp4', 'h264+mp4', 'vp8+webm', 'vp9+webm', 'png', 'png/P', 'png/L',
'webp', 'rgb', 'rgb24', 'rgb32', 'jpeg', 'h265', 'jpeg2000'],
encodings=['rgb', 'h264', 'vp9', 'vp8', 'png', 'png/L', 'png/P', 'jpeg',
'webp'], core encodings=['rgb24', 'rgb32', 'h264', 'vp9', 'vp8', 'png',
'png/L', 'png/P', 'jpeg', 'webp'], lossless encodings=['rgb24', 'rgb32',
'png', 'png/L', 'png/P', 'webp']
2018-08-28 18:44:12,067 251.9GB of system memory
2018-08-28 18:44:12,068 threaded_init() end
2018-08-28 18:44:12,080 x_event_filter event=('xpra-create-event',
None)/CreateNotify window=0x299
2018-08-28 18:44:12,082 parse_event(..)=<X11:CreateNotify {'delivered_to':
'0x299', 'send_event': '0', 'height': '1', 'width': '1', 'window':
'0x60000d', 'serial': '0x3b1', 'type': '16', 'display': ':100'}>
2018-08-28 18:44:12,082 x_event_filter event=('xpra-create-event',
None)/CreateNotify took 1.4ms
2018-08-28 18:44:12,082 x_event_filter event=(None,
'child-configure-request-event')/ConfigureRequest window=0x299
2018-08-28 18:44:12,082 parse_event(..)=<X11:ConfigureRequest
{'delivered_to': '0x299', 'send_event': '0', 'type': '23', 'detail': '0',
'height': '316', 'width': '484', 'window': '0x60000d', 'above': '0', 'y':
'0', 'x': '0', 'serial': '0x3b5', 'border_width': '1', 'value_mask': '12',
'display': ':100'}>
2018-08-28 18:44:12,083
do_child_configure_request_event(<X11:ConfigureRequest {'delivered_to':
'0x299', 'send_event': '0', 'type': '23', 'detail': '0', 'height': '316',
'width': '484', 'window': '0x60000d', 'above': '0', 'y': '0', 'x': '0',
'serial': '0x3b5', 'border_width': '1', 'value_mask': '12', 'display':
':100'}>) value_mask=Width|Height, reconfigure on withdrawn window
2018-08-28 18:44:12,083 updated window geometry for window 0x60000d from
(0, 0, 1, 1) to (0, 0, 484, 316)
2018-08-28 18:44:12,083 x_event_filter event=(None,
'child-configure-request-event')/ConfigureRequest took 1.2ms
2018-08-28 18:44:12,083 x_event_filter event=('xpra-configure-event',
None)/ConfigureNotify window=0x299
2018-08-28 18:44:12,084 parse_event(..)=<X11:ConfigureNotify
{'delivered_to': '0x299', 'send_event': '0', 'height': '316', 'width':
'484', 'window': '0x60000d', 'above': '4194344', 'y': '0', 'x': '0',
'serial': '0x3bb', 'border_width': '0', 'type': '22', 'display': ':100'}>
2018-08-28 18:44:12,084 x_event_filter event=('xpra-configure-event',
None)/ConfigureNotify took 0.4ms
2018-08-28 18:44:12,099 x_event_filter event=(None,
'child-map-request-event')/MapRequest window=0x299
2018-08-28 18:44:12,099 parse_event(..)=<X11:MapRequest {'delivered_to':
'0x299', 'send_event': '0', 'window': '0x60000d', 'serial': '0x3c2',
'type': '20', 'display': ':100'}>
2018-08-28 18:44:12,100 Found a potential client
2018-08-28 18:44:12,100 _manage_client(<gtk.gdk.Window object at
0x2b6cf2e92dc0 (GdkWindow at 0x78cd000)>)
2018-08-28 18:44:12,100 new window 0x60000d
2018-08-28 18:44:12,101 read_initial_X11_properties() window
2018-08-28 18:44:12,101 Window.read_initial_X11_properties()
2018-08-28 18:44:12,101 read _NET_WM_STATE=None
2018-08-28 18:44:12,101 updateprop(state, frozenset([])) previous value=None
2018-08-28 18:44:12,101 not sending notify(state) (setup done=False,
managed=False)
2018-08-28 18:44:12,101 read_initial_X11_properties() core
2018-08-28 18:44:12,102 initial X11 properties: xid=0x60000d, depth=24
2018-08-28 18:44:12,102 updateprop(depth, 24) previous value=None
2018-08-28 18:44:12,102 not sending notify(depth) (setup done=False,
managed=False)
2018-08-28 18:44:12,102 updateprop(xid, 6291469) previous value=None
2018-08-28 18:44:12,102 not sending notify(xid) (setup done=False,
managed=False)
2018-08-28 18:44:12,102 updateprop(has-alpha, False) previous value=None
2018-08-28 18:44:12,102 not sending notify(has-alpha) (setup done=False,
managed=False)
2018-08-28 18:44:12,102 updateprop(allowed-actions,
['_NET_WM_ACTION_CLOSE', '_NET_WM_ACTION_MOVE', '_NET_WM_ACTION_RESIZE',
'_NET_WM_ACTION_FULLSCREEN', '_NET_WM_ACTION_MINIMIZE',
'_NET_WM_ACTION_SHADE', '_NET_WM_ACTION_STICK',
'_NET_WM_ACTION_MAXIMIZE_HORZ', '_NET_WM_ACTION_MAXIMIZE_VERT',
'_NET_WM_ACTION_CHANGE_DESKTOP', '_NET_WM_ACTION_ABOVE',
'_NET_WM_ACTION_BELOW']) previous value=None
2018-08-28 18:44:12,102 not sending notify(allowed-actions) (setup
done=False, managed=False)
2018-08-28 18:44:12,102 displayHasXShape()=True
2018-08-28 18:44:12,103 read_shape for window 0x60000d: extents=((0, 0, 0,
484, 316), (0, 0, 0, 484, 316))
2018-08-28 18:44:12,103 read_shape for window 0x60000d: none enabled
2018-08-28 18:44:12,103 updateprop(shape, {}) previous value=None
2018-08-28 18:44:12,103 not sending notify(shape) (setup done=False,
managed=False)
2018-08-28 18:44:12,103 initial X11_properties: querying ['_NET_WM_PID',
'WM_CLIENT_MACHINE', 'WM_NAME', '_NET_WM_NAME', 'WM_PROTOCOLS', 'WM_CLASS',
'WM_WINDOW_ROLE', 'WM_TRANSIENT_FOR', '_NET_WM_WINDOW_TYPE',
'_NET_WM_DESKTOP', '_NET_WM_FULLSCREEN_MONITORS',
'_NET_WM_BYPASS_COMPOSITOR', '_NET_WM_STRUT', '_NET_WM_STRUT_PARTIAL',
'_NET_WM_WINDOW_OPACITY', 'WM_HINTS', '_GTK_APP_MENU_OBJECT_PATH',
'_GTK_APPLICATION_ID', '_GTK_UNIQUE_BUS_NAME',
'_GTK_APPLICATION_OBJECT_PATH', '_GTK_APP_MENU_OBJECT_PATH',
'_GTK_WINDOW_OBJECT_PATH', 'WM_HINTS', 'WM_NORMAL_HINTS',
'_MOTIF_WM_HINTS', 'WM_ICON_NAME', '_NET_WM_ICON_NAME', '_NET_WM_ICON',
'_NET_WM_STRUT', '_NET_WM_STRUT_PARTIAL']
2018-08-28 18:44:12,103 _NET_WM_PID=17703
2018-08-28 18:44:12,104 updateprop(pid, 17703) previous value=None
2018-08-28 18:44:12,104 not sending notify(pid) (setup done=False,
managed=False)
2018-08-28 18:44:12,104 WM_CLIENT_MACHINE=l-server-13
2018-08-28 18:44:12,104 updateprop(client-machine, l-server-13) previous
value=None
2018-08-28 18:44:12,104 not sending notify(client-machine) (setup
done=False, managed=False)
2018-08-28 18:44:12,105 _NET_WM_NAME=None
2018-08-28 18:44:12,105 WM_NAME=xterm
2018-08-28 18:44:12,105 updateprop(title, xterm) previous value=None
2018-08-28 18:44:12,105 not sending notify(title) (setup done=False,
managed=False)
2018-08-28 18:44:12,105 wm_name changed
2018-08-28 18:44:12,105 WM_PROTOCOLS=['WM_DELETE_WINDOW']
2018-08-28 18:44:12,105 updateprop(protocols, ['WM_DELETE_WINDOW'])
previous value=None
2018-08-28 18:44:12,106 not sending notify(protocols) (setup done=False,
managed=False)
2018-08-28 18:44:12,106 XGetClassHint(0x60000d) classhints: xterm, XTerm
2018-08-28 18:44:12,106 WM_CLASS=('xterm', 'XTerm')
2018-08-28 18:44:12,106 updateprop(class-instance, ('xterm', 'XTerm'))
previous value=None
2018-08-28 18:44:12,106 not sending notify(class-instance) (setup
done=False, managed=False)
2018-08-28 18:44:12,106 WM_WINDOW_ROLE=None
2018-08-28 18:44:12,106 updateprop(role, None) previous value=None
2018-08-28 18:44:12,106 not sending notify(role) (setup done=False,
managed=False)
2018-08-28 18:44:12,107 WM_TRANSIENT_FOR=None
2018-08-28 18:44:12,107 updateprop(transient-for, None) previous value=None
2018-08-28 18:44:12,107 not sending notify(transient-for) (setup
done=False, managed=False)
2018-08-28 18:44:12,107 _NET_WM_WINDOW_TYPE=None
2018-08-28 18:44:12,107 get(override-redirect, False) returning default
value=False
2018-08-28 18:44:12,107 guessed window type=_NET_WM_WINDOW_TYPE_NORMAL
2018-08-28 18:44:12,108 updateprop(window-type, ['NORMAL']) previous
value=None
2018-08-28 18:44:12,108 not sending notify(window-type) (setup done=False,
managed=False)
2018-08-28 18:44:12,108 _NET_WM_DESKTOP=UNSET for window 0x60000d
2018-08-28 18:44:12,108 updateprop(workspace, 65535) previous value=None
2018-08-28 18:44:12,108 not sending notify(workspace) (setup done=False,
managed=False)
2018-08-28 18:44:12,109 _NET_WM_FULLSCREEN_MONITORS=None
2018-08-28 18:44:12,109 updateprop(fullscreen-monitors, None) previous
value=None
2018-08-28 18:44:12,109 not sending notify(fullscreen-monitors) (setup
done=False, managed=False)
2018-08-28 18:44:12,109 _NET_WM_BYPASS_COMPOSITOR=0
2018-08-28 18:44:12,109 updateprop(bypass-compositor, 0) previous value=None
2018-08-28 18:44:12,109 not sending notify(bypass-compositor) (setup
done=False, managed=False)
2018-08-28 18:44:12,109 _NET_WM_STRUT_PARTIAL=None
2018-08-28 18:44:12,110 _NET_WM_STRUT=None
2018-08-28 18:44:12,110 updateprop(strut, None) previous value=None
2018-08-28 18:44:12,110 not sending notify(strut) (setup done=False,
managed=False)
2018-08-28 18:44:12,110 _NET_WM_WINDOW_OPACITY=-1
2018-08-28 18:44:12,110 updateprop(opacity, -1) previous value=None
2018-08-28 18:44:12,110 not sending notify(opacity) (setup done=False,
managed=False)
2018-08-28 18:44:12,110 updateprop(group-leader, None) previous value=None
2018-08-28 18:44:12,110 not sending notify(group-leader) (setup done=False,
managed=False)
2018-08-28 18:44:12,111 updateprop(attention-requested, False) previous
value=None
2018-08-28 18:44:12,111 not sending notify(attention-requested) (setup
done=False, managed=False)
2018-08-28 18:44:12,111 wm_hints.input = 1
2018-08-28 18:44:12,111 updateprop(can-focus, True) previous value=None
2018-08-28 18:44:12,111 not sending notify(can-focus) (setup done=False,
managed=False)
2018-08-28 18:44:12,111 _GTK_APP_MENU_OBJECT_PATH=None
2018-08-28 18:44:12,111 _GTK_APPLICATION_ID=None
2018-08-28 18:44:12,112 _GTK_APPLICATION_OBJECT_PATH=None
2018-08-28 18:44:12,112 _GTK_UNIQUE_BUS_NAME=None
2018-08-28 18:44:12,112 _GTK_WINDOW_OBJECT_PATH=None
2018-08-28 18:44:12,112 updateprop(menu, {}) previous value=None
2018-08-28 18:44:12,112 not sending notify(menu) (setup done=False,
managed=False)
2018-08-28 18:44:12,112 WM_NORMAL_HINTS={'min_size': (10, 17),
'win_gravity': 1, 'resize_inc': (6, 13), 'base_size': (4, 4), 'size': (484,
316)}
2018-08-28 18:44:12,113 updateprop(size-hints, {'base-size': (4, 4),
'minimum-size': (10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484,
316)}) previous value=None
2018-08-28 18:44:12,113 not sending notify(size-hints) (setup done=False,
managed=False)
2018-08-28 18:44:12,113 Missing property _MOTIF_WM_HINTS (motif-hints)
2018-08-28 18:44:12,113 _MOTIF_WM_HINTS=None
2018-08-28 18:44:12,113 _NET_WM_ICON_NAME=None
2018-08-28 18:44:12,113 WM_ICON_NAME=xterm
2018-08-28 18:44:12,114 updateprop(icon-title, xterm) previous value=None
2018-08-28 18:44:12,114 not sending notify(icon-title) (setup done=False,
managed=False)
2018-08-28 18:44:12,114 _NET_WM_ICON changed on 0x60000d, re-reading
2018-08-28 18:44:12,114 icon is now None, pixmap=None
2018-08-28 18:44:12,114 initial X11 position and size: requested((0, 0,
484, 316), {'base-size': (4, 4), 'minimum-size': (10, 17), 'gravity': 1,
'increment': (6, 13), 'size': (484, 316)})=(0, 0, 484, 316)
2018-08-28 18:44:12,114 get_wm_state(modal)
state_names=('_NET_WM_STATE_MODAL',)
2018-08-28 18:44:12,115 WindowDamageHandler.__init__(0x60000d, True)
2018-08-28 18:44:12,115 invalidating named pixmap, contents handle=None
2018-08-28 18:44:12,115 damage handle(0x60000d)=0x40002c
2018-08-28 18:44:12,115 displayHasXShape()=True
2018-08-28 18:44:12,116 setup_property_sync()
2018-08-28 18:44:12,116 sync_allowed_actions: setting
_NET_WM_ALLOWED_ACTIONS=['_NET_WM_ACTION_CLOSE', '_NET_WM_ACTION_MOVE',
'_NET_WM_ACTION_RESIZE', '_NET_WM_ACTION_FULLSCREEN',
'_NET_WM_ACTION_MINIMIZE', '_NET_WM_ACTION_SHADE', '_NET_WM_ACTION_STICK',
'_NET_WM_ACTION_MAXIMIZE_HORZ', '_NET_WM_ACTION_MAXIMIZE_VERT',
'_NET_WM_ACTION_CHANGE_DESKTOP', '_NET_WM_ACTION_ABOVE',
'_NET_WM_ACTION_BELOW'] on 0x60000d
2018-08-28 18:44:12,116 sync_frame: frame(0x60000d)=None
2018-08-28 18:44:12,117 get(override-redirect, False) returning default
value=False
2018-08-28 18:44:12,117 get(tray, False) returning default value=False
2018-08-28 18:44:12,117 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 0, 0)
on 0x60000d
2018-08-28 18:44:12,117 sync_state: setting _NET_WM_STATE=frozenset([]) on
0x60000d
2018-08-28 18:44:12,117 get(iconic, None) using get_property=False
2018-08-28 18:44:12,118 _handle_iconic_update: set_state(1)
2018-08-28 18:44:12,118 setup() corral_window=0x40002d
2018-08-28 18:44:12,118 setup() adding to save set
2018-08-28 18:44:12,118 setup() reparenting
2018-08-28 18:44:12,119 setup() geometry
2018-08-28 18:44:12,119 setup() hints={'base-size': (4, 4), 'minimum-size':
(10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)}
size=484x316
2018-08-28 18:44:12,119 updateprop(geometry, (0, 0, 484, 316)) unchanged
2018-08-28 18:44:12,119 setup() resizing windows to 484x316
2018-08-28 18:44:12,120 adding window WindowModel(0x60000d)
2018-08-28 18:44:12,120 add_new_window_common(WindowModel(0x60000d))
watching for dynamic properties: ['title', 'command', 'shape',
'class-instance', 'protocols', 'attention-requested', 'menu', 'workspace',
'opacity', 'fullscreen', 'focused', 'maximized', 'above', 'below',
'shaded', 'skip-taskbar', 'skip-pager', 'sticky', 'size-hints',
'icon-title', 'icon', 'decorations', 'modal', 'iconic']
2018-08-28 18:44:12,120 get(tray, False) returning default value=False
2018-08-28 18:44:12,121 Discovered new ordinary window:
WindowModel(0x60000d) (geometry=(0, 0, 484, 316))
2018-08-28 18:44:12,121 ownership_election() winner=None, old owner=None,
candidates=[(-1, DesktopManager(1))]
2018-08-28 18:44:12,121 x_event_filter event=(None,
'child-map-request-event')/MapRequest took 22.1ms
2018-08-28 18:44:12,121 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x60000d
2018-08-28 18:44:12,122 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x60000d', 'send_event': '0', 'window': '0x60000d',
'atom': '_NET_WM_ALLOWED_ACTIONS', 'serial': '0x40d', 'type': '28',
'display': ':100'}>
2018-08-28 18:44:12,122 Property changed on 0x60000d:
_NET_WM_ALLOWED_ACTIONS
2018-08-28 18:44:12,122 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.7ms
2018-08-28 18:44:12,122 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x60000d
2018-08-28 18:44:12,122 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x60000d', 'send_event': '0', 'window': '0x60000d',
'atom': '_NET_FRAME_EXTENTS', 'serial': '0x411', 'type': '28', 'display':
':100'}>
2018-08-28 18:44:12,122 Property changed on 0x60000d: _NET_FRAME_EXTENTS
2018-08-28 18:44:12,123 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.6ms
2018-08-28 18:44:12,123 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x60000d
2018-08-28 18:44:12,123 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x60000d', 'send_event': '0', 'window': '0x60000d',
'atom': '_NET_WM_STATE', 'serial': '0x413', 'type': '28', 'display':
':100'}>
2018-08-28 18:44:12,123 Property changed on 0x60000d: _NET_WM_STATE
2018-08-28 18:44:12,123 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.6ms
2018-08-28 18:44:12,123 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x60000d
2018-08-28 18:44:12,124 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x60000d', 'send_event': '0', 'window': '0x60000d',
'atom': 'WM_STATE', 'serial': '0x415', 'type': '28', 'display': ':100'}>
2018-08-28 18:44:12,124 Property changed on 0x60000d: WM_STATE
2018-08-28 18:44:12,124 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.6ms
2018-08-28 18:44:12,124 x_event_filter event=('xpra-create-event',
None)/CreateNotify window=0x299
2018-08-28 18:44:12,124 parse_event(..)=<X11:CreateNotify {'delivered_to':
'0x299', 'send_event': '0', 'height': '316', 'width': '484', 'window':
'0x40002d', 'serial': '0x417', 'type': '16', 'display': ':100'}>
2018-08-28 18:44:12,124 x_event_filter event=('xpra-create-event',
None)/CreateNotify took 0.3ms
2018-08-28 18:44:12,125 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x40002d
2018-08-28 18:44:12,125 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x40002d', 'send_event': '0', 'window': '0x40002d',
'atom': '_NET_WM_NAME', 'serial': '0x419', 'type': '28', 'display': ':100'}>
2018-08-28 18:44:12,125 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.4ms
2018-08-28 18:44:12,125 x_event_filter event=('xpra-reparent-event',
None)/ReparentNotify window=0x60000d
2018-08-28 18:44:12,125 parse_event(..)=<X11:ReparentNotify
{'delivered_to': '0x60000d', 'send_event': '0', 'window': '0x60000d',
'serial': '0x420', 'type': '21', 'display': ':100'}>
2018-08-28 18:44:12,126 invalidating named pixmap, contents handle=None
2018-08-28 18:44:12,126 x_event_filter event=('xpra-reparent-event',
None)/ReparentNotify took 0.5ms
2018-08-28 18:44:12,126 x_event_filter event=('xpra-reparent-event',
None)/ReparentNotify window=0x299
2018-08-28 18:44:12,126 parse_event(..)=<X11:ReparentNotify
{'delivered_to': '0x299', 'send_event': '0', 'window': '0x60000d',
'serial': '0x420', 'type': '21', 'display': ':100'}>
2018-08-28 18:44:12,126 x_event_filter event=('xpra-reparent-event',
None)/ReparentNotify took 0.4ms
2018-08-28 18:44:12,126 x_event_filter event=('xpra-map-event',
'xpra-child-map-event')/MapNotify window=0x60000d
2018-08-28 18:44:12,126 parse_event(..)=<X11:MapNotify {'delivered_to':
'0x60000d', 'send_event': '0', 'override_redirect': '0', 'window':
'0x60000d', 'serial': '0x425', 'type': '19', 'display': ':100'}>
2018-08-28 18:44:12,127 x_event_filter event=('xpra-map-event',
'xpra-child-map-event')/MapNotify took 0.3ms
2018-08-28 18:44:12,127 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x60000d
2018-08-28 18:44:12,127 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x60000d', 'send_event': '0', 'window': '0x60000d',
'atom': '_XPRA_WID', 'serial': '0x42d', 'type': '28', 'display': ':100'}>
2018-08-28 18:44:12,127 Property changed on 0x60000d: _XPRA_WID
2018-08-28 18:44:12,127 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 0.6ms
2018-08-28 18:44:12,305 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x60000d
2018-08-28 18:44:12,305 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x60000d', 'send_event': '0', 'window': '0x60000d',
'atom': 'WM_ICON_NAME', 'serial': '0x448', 'type': '28', 'display': ':100'}>
2018-08-28 18:44:12,306 Property changed on 0x60000d: WM_ICON_NAME
2018-08-28 18:44:12,306 _NET_WM_ICON_NAME=None
2018-08-28 18:44:12,306 WM_ICON_NAME=~
2018-08-28 18:44:12,307 updateprop(icon-title, ~) previous value=xterm
2018-08-28 18:44:12,307 updating metadata on WindowModel(0x60000d):
<GParamBoxed 'icon-title'>
2018-08-28 18:44:12,307 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 2.0ms
2018-08-28 18:44:12,307 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify window=0x60000d
2018-08-28 18:44:12,307 parse_event(..)=<X11:PropertyNotify
{'delivered_to': '0x60000d', 'send_event': '0', 'window': '0x60000d',
'atom': 'WM_NAME', 'serial': '0x448', 'type': '28', 'display': ':100'}>
2018-08-28 18:44:12,308 Property changed on 0x60000d: WM_NAME
2018-08-28 18:44:12,308 _NET_WM_NAME=None
2018-08-28 18:44:12,308 WM_NAME=~
2018-08-28 18:44:12,308 updateprop(title, ~) previous value=xterm
2018-08-28 18:44:12,308 updating metadata on WindowModel(0x60000d):
<GParamBoxed 'title'>
2018-08-28 18:44:12,308 wm_name changed
2018-08-28 18:44:12,308 x_event_filter event=('xpra-property-notify-event',
None)/PropertyNotify took 1.4ms


*Client Log:*
2018-08-28 11:37:54,084 LoadImage(C:\Program Files\Xpra\icons\xpra.ico)
using image type=ICON
2018-08-28 11:37:54,086 LoadImage(C:\Program
Files\Xpra\icons\xpra.ico)=3408641
2018-08-28 11:37:54,087 do_set_icon(0x340301)
2018-08-28 11:37:54,088
make_nid(..)=<xpra.platform.win32.win32_NotifyIcon.NOTIFYICONDATA object at
0x000000001862ff80> tooltip='ssh://***@l-server-13/:100', app_id=0,
actual flags=ICON, GUID
2018-08-28 11:37:54,090
make_nid(..)=<xpra.platform.win32.win32_NotifyIcon.NOTIFYICONDATA object at
0x000000001862ff80> tooltip='ssh://***@l-server-13/:100', app_id=0,
actual flags=ICON, GUID
2018-08-28 11:37:55,166 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'ssh', 'process': <subprocess.Popen object at
0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True,
'callback': None, 'command': ['plink', '-ssh', '-agent', '-l',
'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra 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-08-28 11:37:57,167 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'ssh', 'process': <subprocess.Popen object at
0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True,
'callback': None, 'command': ['plink', '-ssh', '-agent', '-l',
'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra 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-08-28 11:37:58,987 read_parse_thread_loop starting
2018-08-28 11:37:58,987 read thread: eof
2018-08-28 11:37:58,989 parse thread: empty marker, exiting
2018-08-28 11:37:58,992 io_thread_loop(read, <bound method Protocol._read
of Protocol(Pipe(ssh://***@l-server-13/:100))>) loop ended,
closed=False
2018-08-28 11:37:58,993 Protocol.close() closed=False,
connection=Pipe(ssh://***@l-server-13/:100)
2018-08-28 11:37:58,996 Protocol.close() calling <bound method
TwoFileConnection.close of Pipe(ssh://***@l-server-13/:100)>
2018-08-28 11:37:58,998 Pipe(ssh://***@l-server-13/:100).close()
close callback=<function stop_tunnel at 0x000000001861fde8>, readable=<open
file '<fdopen>', mode 'rb' at 0x000000001862f810>, writeable=<open file
'<fdopen>', mode 'wb' at 0x000000001862f9c0>
2018-08-28 11:37:59,003 Pipe(ssh://***@l-server-13/:100).close()
calling <function stop_tunnel at 0x000000001861fde8>
2018-08-28 11:37:59,003 Pipe(ssh://***@l-server-13/:100).close() done
2018-08-28 11:37:59,004 terminate_queue_threads()
2018-08-28 11:37:59,005 write thread: empty marker, exiting
2018-08-28 11:37:59,005 Protocol.close() done
2018-08-28 11:37:59,005 Protocol.close() closed=True, connection=None
2018-08-28 11:37:59,006 check_server_echo(0) last=True, server_ok=True
(last_ping_echoed_time=0)
2018-08-28 11:37:59,006 io_thread_loop(write, <bound method Protocol._write
of Protocol(None)>) loop ended, closed=True
2018-08-28 11:37:59,006 Error: failed to receive anything, not an xpra
server?
2018-08-28 11:37:59,010 could also be the wrong protocol, username,
password or port
2018-08-28 11:37:59,010 or the session was not found
2018-08-28 11:37:59,010 Connection lost
2018-08-28 11:37:59,011 GTKXpraClient.quit(1) current exit_code=None
2018-08-28 11:37:59,012 UIXpraClient.cleanup()
2018-08-28 11:37:59,012 poll() procinfo list: [ProcInfo({'returncode':
None, 'name': 'ssh', 'process': <subprocess.Popen object at
0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True,
'callback': None, 'command': ['plink', '-ssh', '-agent', '-l',
'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra 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})]
Post by Ben Sferrazza via shifter-users
On Tue, Mar 6, 2018 at 9:24 AM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
OK thanks. Xpra server is running as shown here. Its own log file
doesn't
Post by Ben Sferrazza via shifter-users
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.
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
Here's the relevant output from the client. The 'no run-xpra' command
found
Post by Ben Sferrazza via shifter-users
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
~/.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.
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
None, 'name': 'ssh', 'process': <subprocess.Popen object at
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
Post by Ben Sferrazza via shifter-users
/usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found";
exit
(..)
Post by Ben Sferrazza via shifter-users
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.
Antoine Martin via shifter-users
2018-08-29 03:42:03 UTC
Permalink
Post by Ben Sferrazza via shifter-users
Hi. I'm including my previous correspondence below, as it will at least
offer some history about my setup and prior issues.
I stopped using Xpra a few months ago due to numerous bugs that made it
unusable (this is using a Linux server and Windows client).
1. windows get stuck with on-top focus
Which windows from which applications?
Post by Ben Sferrazza via shifter-users
2. disappearing mouse cursor when using X11-only no-toolkit apps that use
inverted black mouse pointer after clicking on something
Do you have a specific application we can use to reproduce the problem?
Post by Ben Sferrazza via shifter-users
3. some windows don't show window bar until resized (e.g. gvim always gets
placed in upper-left without window bar)
Some applications do weird things with their geometry sometimes, gvim is
one of those. That said, I've just tried it and it worked fine and it
does seem to request to be placed in the top left corner.
Please provide more details so we can reproduce the window bar problem.
(ie: server os and version, gvim version, etc..)
Post by Ben Sferrazza via shifter-users
4. dialog box black bars (appears to be trying to add scrollbars?).
Can you provide example applications we can use to reproduce the problem?
I've never seen that anywhere except when X11 windows are smaller than
the minimal window size on mswindows, then we have to pad it with something.
Post by Ben Sferrazza via shifter-users
5. windows are all blank (white) when returning into work after several
hours (requires restarting client)
That's a known "feature" of some opengl drivers, they clear the video
memory when the system goes into idle or suspended state.
We try to detect that (slowing down the refresh rate) and then refresh
the screen when the session resumes, but that doesn't always fix things.
You should not need to restart the client: minimizing the windows and
restoring them should be enough.
Alternatively, turn off opengl in the client - the client performance
will be much lower.
Post by Ben Sferrazza via shifter-users
6. flickering clipboard icon in systray
That's a very obvious sign that something is not right and something is
constantly requesting the clipboard contents. This will cause
unnecessary traffic and instability. Try to figure out what is causing
this and stop it. Usually, this is caused by clipboard managers or other
clipboard synchronization tools (synergy, virtualbox, etc).
Post by Ben Sferrazza via shifter-users
I'm inclined to give Xpra another chance, with the newer versions, and can
hopefully provide actual debugging log information for these bugs to be
fixed (if they haven't already).
Bugs that are reproducible are usually fixed pretty quickly.
Unfortunately, I have not seen any of the problems you have reported
above, so the chances that newer versions have already fixed those
issues are slim.
For more generic bug reporting and debugging guidelines, see:
https://xpra.org/trac/wiki/ReportingBugs
Post by Ben Sferrazza via shifter-users
But I'm now not even able to connect to the server from the client using
version 2.3.3. It reports Connection Lost immediately. I can ssh into the
same host without issue. And have made sure that the shell rc file no
longer outputs anything, which was the source of my issue a few months ago.
I have included the relevant sections of the server log and client log
below.
*Server Log:*
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,059 add_process(<subprocess.Popen object at
0x2b6cf2e9eb10>, xterm, ['xterm'], True, False) pid=17703
2018-08-28 18:44:12,059 xpra is ready.
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,067 251.9GB of system memory
For real?
(..)
Post by Ben Sferrazza via shifter-users
(10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)}
size=484x316
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,308 updateprop(title, ~) previous value=xterm
Nothing after that which means that the server never received a
connection from the client.
Post by Ben Sferrazza via shifter-users
*Client Log:*
(..)
Post by Ben Sferrazza via shifter-users
None, 'name': 'ssh', 'process': <subprocess.Popen object at
0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True,
'callback': None, 'command': ['plink', '-ssh', '-agent', '-l',
'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra 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})]
None, 'name': 'ssh', 'process': <subprocess.Popen object at
0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True,
'callback': None, 'command': ['plink', '-ssh', '-agent', '-l',
'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra 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-08-28 11:37:58,987 read_parse_thread_loop starting
2018-08-28 11:37:58,987 read thread: eof
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 11:37:59,006 Error: failed to receive anything, not an xpra
server?
2018-08-28 11:37:59,010 could also be the wrong protocol, username,
password or port
2018-08-28 11:37:59,010 or the session was not found
(..)
The client got an EOF from the ssh command it tried to run.
(the long and ugly "run-xpra" line above)
That usually means that the session was not found, or that none of the
"xpra" or "run-xpra" executable scripts are available and executable.

You can try running it by hand from a putty session.
I would also try to connect from a *nix client to see if the problem is
likely to be client side or server side.

This can also be caused by non-bash login shells (ie: csh, tcsh):
https://xpra.org/trac/ticket/1892
The latest 2.4 beta builds include a new ssh backend, which you can
enable using "--ssh=paramiko" and this will give you more details using
"--debug=ssh". It should also support all types of login shells, unlike
putty. More details here:
https://xpra.org/trac/ticket/1646
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
OK thanks. Xpra server is running as shown here. Its own log file
doesn't
Post by Ben Sferrazza via shifter-users
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 below 1024 are restricted:
https://unix.stackexchange.com/questions/10735/

(..)
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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.
You can also keep the line that sources it and just redirect the output
to stderr:
source yourscript.sh 1>&2

Cheers,
Antoine
Ben Sferrazza via shifter-users
2018-08-29 17:27:33 UTC
Permalink
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Hi. I'm including my previous correspondence below, as it will at least
offer some history about my setup and prior issues.
I stopped using Xpra a few months ago due to numerous bugs that made it
unusable (this is using a Linux server and Windows client).
1. windows get stuck with on-top focus
Which windows from which applications?
Post by Ben Sferrazza via shifter-users
2. disappearing mouse cursor when using X11-only no-toolkit apps that use
inverted black mouse pointer after clicking on something
Do you have a specific application we can use to reproduce the problem?
Post by Ben Sferrazza via shifter-users
3. some windows don't show window bar until resized (e.g. gvim always
gets
Post by Ben Sferrazza via shifter-users
placed in upper-left without window bar)
Some applications do weird things with their geometry sometimes, gvim is
one of those. That said, I've just tried it and it worked fine and it
does seem to request to be placed in the top left corner.
Please provide more details so we can reproduce the window bar problem.
(ie: server os and version, gvim version, etc..)
Post by Ben Sferrazza via shifter-users
4. dialog box black bars (appears to be trying to add scrollbars?).
Can you provide example applications we can use to reproduce the problem?
I've never seen that anywhere except when X11 windows are smaller than
the minimal window size on mswindows, then we have to pad it with something.
Post by Ben Sferrazza via shifter-users
5. windows are all blank (white) when returning into work after several
hours (requires restarting client)
That's a known "feature" of some opengl drivers, they clear the video
memory when the system goes into idle or suspended state.
We try to detect that (slowing down the refresh rate) and then refresh
the screen when the session resumes, but that doesn't always fix things.
You should not need to restart the client: minimizing the windows and
restoring them should be enough.
Alternatively, turn off opengl in the client - the client performance
will be much lower.
Post by Ben Sferrazza via shifter-users
6. flickering clipboard icon in systray
That's a very obvious sign that something is not right and something is
constantly requesting the clipboard contents. This will cause
unnecessary traffic and instability. Try to figure out what is causing
this and stop it. Usually, this is caused by clipboard managers or other
clipboard synchronization tools (synergy, virtualbox, etc).
I'll certainly provide you with more details once I'm re-connected using
Xpra 2.3.3, and we can hopefully debug the issues I was experiencing.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
I'm inclined to give Xpra another chance, with the newer versions, and
can
Post by Ben Sferrazza via shifter-users
hopefully provide actual debugging log information for these bugs to be
fixed (if they haven't already).
Bugs that are reproducible are usually fixed pretty quickly.
Unfortunately, I have not seen any of the problems you have reported
above, so the chances that newer versions have already fixed those
issues are slim.
https://xpra.org/trac/wiki/ReportingBugs
Post by Ben Sferrazza via shifter-users
But I'm now not even able to connect to the server from the client using
version 2.3.3. It reports Connection Lost immediately. I can ssh into the
same host without issue. And have made sure that the shell rc file no
longer outputs anything, which was the source of my issue a few months
ago.
Post by Ben Sferrazza via shifter-users
I have included the relevant sections of the server log and client log
below.
*Server Log:*
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,059 add_process(<subprocess.Popen object at
0x2b6cf2e9eb10>, xterm, ['xterm'], True, False) pid=17703
2018-08-28 18:44:12,059 xpra is ready.
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,067 251.9GB of system memory
For real?
It's a 48-core server here at work.
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,119 setup() hints={'base-size': (4, 4),
(10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)}
size=484x316
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,308 updateprop(title, ~) previous value=xterm
Nothing after that which means that the server never received a
connection from the client.
Post by Ben Sferrazza via shifter-users
*Client Log:*
(..)
Post by Ben Sferrazza via shifter-users
None, 'name': 'ssh', 'process': <subprocess.Popen object at
0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True,
'callback': None, 'command': ['plink', '-ssh', '-agent', '-l',
'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra
initenv;if
Post by Ben Sferrazza via shifter-users
[ -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 [
Post by Ben Sferrazza via shifter-users
-x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo
"no run-xpra command found"; exit 1; fi'], 'forget': False})]
None, 'name': 'ssh', 'process': <subprocess.Popen object at
0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True,
'callback': None, 'command': ['plink', '-ssh', '-agent', '-l',
'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra
initenv;if
Post by Ben Sferrazza via shifter-users
[ -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 [
Post by Ben Sferrazza via shifter-users
-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-08-28 11:37:58,987 read_parse_thread_loop starting
2018-08-28 11:37:58,987 read thread: eof
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 11:37:59,006 Error: failed to receive anything, not an xpra
server?
2018-08-28 11:37:59,010 could also be the wrong protocol, username,
password or port
2018-08-28 11:37:59,010 or the session was not found
(..)
The client got an EOF from the ssh command it tried to run.
(the long and ugly "run-xpra" line above)
That usually means that the session was not found, or that none of the
"xpra" or "run-xpra" executable scripts are available and executable.
You can try running it by hand from a putty session.
I would also try to connect from a *nix client to see if the problem is
likely to be client side or server side.
https://xpra.org/trac/ticket/1892
The latest 2.4 beta builds include a new ssh backend, which you can
enable using "--ssh=paramiko" and this will give you more details using
"--debug=ssh". It should also support all types of login shells, unlike
https://xpra.org/trac/ticket/1646
OK, we do unfortunately use tcsh here because of some Cadence (EE EDA
software) tools that have a bunch of csh scripts for setting up licenses
and other things. When I struggled with getting Xpra to connect a few
months ago, the culprit was some output to stdout from my .cshrc file.
Though that's been suppressed. I'll give some of the suggestions you
mentioned a try and report back.

Thanks,
Ben
Ben Sferrazza via shifter-users
2018-08-29 23:04:27 UTC
Permalink
While I was debugging the issue yesterday, I figured I'd update my Xorg X
server to the latest version, 1.20.1. This seems to have broken things when
loading the Xdummy module, as the ABI versions no longer match.

Is the dummy_drv part of Xpra? Is there a possibility for this to be
updated? For now I just rolled back to X server 1.19.6 and everything works.

[904276.126] (II) LoadModule: "glx"
[904276.130] (II) Loading /home/tools/lib/xorg/modules/extensions/libglx.so
[904276.155] (II) Module glx: vendor="X.Org Foundation"
[904276.155] compiled for 1.19.6, module version = 1.0.0
[904276.155] ABI class: X.Org Server Extension, version 10.0
[904276.155] (II) LoadModule: "dummy"
[904276.162] (II) Loading /home/tools/lib/xorg/modules/drivers/dummy_drv.so
[904276.162] (II) Module dummy: vendor="X.Org Foundation"
[904276.162] compiled for 1.19.6, module version = 0.3.8
[904276.162] Module class: X.Org Video Driver
[904276.162] ABI class: X.Org Video Driver, version 23.0
[904276.162] (WW) dummy: module ABI major version (23) doesn't match the
server's version (24)

*So, I installed the latest MS Windows beta and explicitly used paramiko as
the ssh client. This solved my issue and can now connect to my Xpra server
running on Linux*. This was not an issue in Xpra 2.2, so I imagine
something in 2.3 changed the way it interfaces with the shell?

Thanks,
Ben
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Hi. I'm including my previous correspondence below, as it will at least
offer some history about my setup and prior issues.
I stopped using Xpra a few months ago due to numerous bugs that made it
unusable (this is using a Linux server and Windows client).
1. windows get stuck with on-top focus
Which windows from which applications?
Post by Ben Sferrazza via shifter-users
2. disappearing mouse cursor when using X11-only no-toolkit apps that
use
Post by Ben Sferrazza via shifter-users
inverted black mouse pointer after clicking on something
Do you have a specific application we can use to reproduce the problem?
Post by Ben Sferrazza via shifter-users
3. some windows don't show window bar until resized (e.g. gvim always
gets
Post by Ben Sferrazza via shifter-users
placed in upper-left without window bar)
Some applications do weird things with their geometry sometimes, gvim is
one of those. That said, I've just tried it and it worked fine and it
does seem to request to be placed in the top left corner.
Please provide more details so we can reproduce the window bar problem.
(ie: server os and version, gvim version, etc..)
Post by Ben Sferrazza via shifter-users
4. dialog box black bars (appears to be trying to add scrollbars?).
Can you provide example applications we can use to reproduce the problem?
I've never seen that anywhere except when X11 windows are smaller than
the minimal window size on mswindows, then we have to pad it with something.
Post by Ben Sferrazza via shifter-users
5. windows are all blank (white) when returning into work after several
hours (requires restarting client)
That's a known "feature" of some opengl drivers, they clear the video
memory when the system goes into idle or suspended state.
We try to detect that (slowing down the refresh rate) and then refresh
the screen when the session resumes, but that doesn't always fix things.
You should not need to restart the client: minimizing the windows and
restoring them should be enough.
Alternatively, turn off opengl in the client - the client performance
will be much lower.
Post by Ben Sferrazza via shifter-users
6. flickering clipboard icon in systray
That's a very obvious sign that something is not right and something is
constantly requesting the clipboard contents. This will cause
unnecessary traffic and instability. Try to figure out what is causing
this and stop it. Usually, this is caused by clipboard managers or other
clipboard synchronization tools (synergy, virtualbox, etc).
I'll certainly provide you with more details once I'm re-connected using
Xpra 2.3.3, and we can hopefully debug the issues I was experiencing.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
I'm inclined to give Xpra another chance, with the newer versions, and
can
Post by Ben Sferrazza via shifter-users
hopefully provide actual debugging log information for these bugs to be
fixed (if they haven't already).
Bugs that are reproducible are usually fixed pretty quickly.
Unfortunately, I have not seen any of the problems you have reported
above, so the chances that newer versions have already fixed those
issues are slim.
https://xpra.org/trac/wiki/ReportingBugs
Post by Ben Sferrazza via shifter-users
But I'm now not even able to connect to the server from the client using
version 2.3.3. It reports Connection Lost immediately. I can ssh into
the
Post by Ben Sferrazza via shifter-users
same host without issue. And have made sure that the shell rc file no
longer outputs anything, which was the source of my issue a few months
ago.
Post by Ben Sferrazza via shifter-users
I have included the relevant sections of the server log and client log
below.
*Server Log:*
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,059 add_process(<subprocess.Popen object at
0x2b6cf2e9eb10>, xterm, ['xterm'], True, False) pid=17703
2018-08-28 18:44:12,059 xpra is ready.
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,067 251.9GB of system memory
For real?
It's a 48-core server here at work.
Post by Antoine Martin via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,119 setup() hints={'base-size': (4, 4),
(10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)}
size=484x316
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 18:44:12,308 updateprop(title, ~) previous value=xterm
Nothing after that which means that the server never received a
connection from the client.
Post by Ben Sferrazza via shifter-users
*Client Log:*
(..)
Post by Ben Sferrazza via shifter-users
None, 'name': 'ssh', 'process': <subprocess.Popen object at
0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True,
'callback': None, 'command': ['plink', '-ssh', '-agent', '-l',
'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra
initenv;if
Post by Ben Sferrazza via shifter-users
[ -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 [
Post by Ben Sferrazza via shifter-users
-x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo
"no run-xpra command found"; exit 1; fi'], 'forget': False})]
None, 'name': 'ssh', 'process': <subprocess.Popen object at
0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True,
'callback': None, 'command': ['plink', '-ssh', '-agent', '-l',
'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra
initenv;if
Post by Ben Sferrazza via shifter-users
[ -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 [
Post by Ben Sferrazza via shifter-users
-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-08-28 11:37:58,987 read_parse_thread_loop starting
2018-08-28 11:37:58,987 read thread: eof
(..)
Post by Ben Sferrazza via shifter-users
2018-08-28 11:37:59,006 Error: failed to receive anything, not an xpra
server?
2018-08-28 11:37:59,010 could also be the wrong protocol, username,
password or port
2018-08-28 11:37:59,010 or the session was not found
(..)
The client got an EOF from the ssh command it tried to run.
(the long and ugly "run-xpra" line above)
That usually means that the session was not found, or that none of the
"xpra" or "run-xpra" executable scripts are available and executable.
You can try running it by hand from a putty session.
I would also try to connect from a *nix client to see if the problem is
likely to be client side or server side.
https://xpra.org/trac/ticket/1892
The latest 2.4 beta builds include a new ssh backend, which you can
enable using "--ssh=paramiko" and this will give you more details using
"--debug=ssh". It should also support all types of login shells, unlike
https://xpra.org/trac/ticket/1646
OK, we do unfortunately use tcsh here because of some Cadence (EE EDA
software) tools that have a bunch of csh scripts for setting up licenses
and other things. When I struggled with getting Xpra to connect a few
months ago, the culprit was some output to stdout from my .cshrc file.
Though that's been suppressed. I'll give some of the suggestions you
mentioned a try and report back.
Thanks,
Ben
Ben Sferrazza via shifter-users
2018-08-30 00:15:23 UTC
Permalink
This post might be inappropriate. Click to display it.
Antoine Martin via shifter-users
2018-03-06 04:07:14 UTC
Permalink
(..)
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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"
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
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.
(..)
Post by Ben Sferrazza via shifter-users
It's probably unrelated but I receive this error immediately when starting
Xpra. This again is run as non-root. I have XDG_RUNTIME_DIR set to a path
in my home directory. So I'm not sure why it's still attempting to access
/run/xpra/system
2018-03-05 21:16:04,755 get_enabled_encoders(['rencode', 'bencode',
'yaml']) enabled=['yaml', 'rencode', 'bencode']
2018-03-05 21:16:04,799 netifaces loaded sucessfully
2018-03-05 21:16:04,799 successfully loaded socket C library from libc.so.6
2018-03-05 21:16:04,804 failed to connect using <bound method
_socketobject.connect of <socket._socketobject object at
0x2b9f9143e520>>/run/xpra/system
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,
[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".
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
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
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Cheers
Antoine
_______________________________________________
shifter-users mailing list
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
Ben Sferrazza via shifter-users
2018-03-06 04:52:18 UTC
Permalink
On Mon, Mar 5, 2018 at 8:07 PM, Antoine Martin via shifter-users <
Post by Ben Sferrazza via shifter-users
(..)
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
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 \
Post by Ben Sferrazza via shifter-users
-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.
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
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.
Post by Ben Sferrazza via shifter-users
An lspci -v | grep VGA
returns
0a:00.0 VGA compatible controller: Matrox Electronics Systems Ltd.
G200eR2
Post by Ben Sferrazza via shifter-users
(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.
(..)
Post by Ben Sferrazza via shifter-users
It's probably unrelated but I receive this error immediately when
starting
Post by Ben Sferrazza via shifter-users
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
Post by Ben Sferrazza via shifter-users
2018-03-05 21:16:04,804 failed to connect using <bound method
_socketobject.connect of <socket._socketobject object at
0x2b9f9143e520>>/run/xpra/system
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,
[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.
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
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.
Post by Ben Sferrazza via shifter-users
Cheers
Antoine
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Cheers
Antoine
_______________________________________________
shifter-users mailing list
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
Ben Sferrazza via shifter-users
2018-03-06 19:20:45 UTC
Permalink
On Mon, Mar 5, 2018 at 8:07 PM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
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?
Antoine Martin via shifter-users
2018-03-07 02:41:23 UTC
Permalink
Post by Ben Sferrazza via shifter-users
On Mon, Mar 5, 2018 at 8:07 PM, Antoine Martin via shifter-users <
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
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
Antoine Martin via shifter-users
2018-08-30 04:06:32 UTC
Permalink
Post by Ben Sferrazza via shifter-users
Now that I've established a connection again with Xpra server 2.3.3, I
can try to address some of the issues I was/am experiencing. I haven't
used it enough to encounter the first two issues, which were the most
debilitating and largely made it unusable for me before (the stuck focus
issue and the disappearing mouse cursor). Once I can re-create those
I'll have more to offer.
Post by Ben Sferrazza via shifter-users
Hi. I'm including my previous correspondence below, as it will at
least
Post by Ben Sferrazza via shifter-users
offer some history about my setup and prior issues.
I stopped using Xpra a few months ago due to numerous bugs that
made it
Post by Ben Sferrazza via shifter-users
unusable (this is using a Linux server and Windows client).
1. windows get stuck with on-top focus
Which windows from which applications?
This was by far the most egregious bug. It seemed to happen at random
and affected all applications. Considering I do a lot of work in a
terminal, chances are it was a terminal such as xfce4-terminal. I will
report back once this occurs again. My only solution was to minimize the
window, rather than simply clicking on another window to give it focus.
This does ring a bell, but I don't think I ever saw it myself.
https://xpra.org/trac/ticket/713
https://xpra.org/trac/ticket/1381

This could be a platform specific bug (ie: affecting mswindows clients)
in which case the newer Python3 GTK3 builds may fare better.
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
2. disappearing mouse cursor when using X11-only no-toolkit apps
that use
Post by Ben Sferrazza via shifter-users
inverted black mouse pointer after clicking on something
Do you have a specific application we can use to reproduce the problem?
Unfortunately the application I encountered this issue with the most was
Cadence's Simvision, a digital simulation waveform viewer that's part of
their CAD/EDA software suite. The only observation I had was that it is
an application which does not make use of a modern toolkit, such as GTK.
Perhaps it's using Motif? When you click on a menu the mouse cursor
inverts to a right-pointing black cursor, which is a cursor internal to
the program and is not replaced by the client's cursor. That's when the
menu items would disappear. I've attached a screenshot of it working,
which required using an actual camera, as the inverted black cursor is
not picked up by the Windows print screen function.
There were bugs in the cursor code on mswindows, including some fixed
quite recently, those could have caused the problems you describe - it
should now revert to the default cursor in case of failure.
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
3. some windows don't show window bar until resized (e.g. gvim
always gets
Post by Ben Sferrazza via shifter-users
placed in upper-left without window bar)
Some applications do weird things with their geometry sometimes, gvim is
one of those. That said, I've just tried it and it worked fine and it
does seem to request to be placed in the top left corner.
Please provide more details so we can reproduce the window bar problem.
(ie: server os and version, gvim version, etc..)
This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra
2.3.3 on Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT
2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior.
It corrects itself once I do any resizing of the window (which must
initiate a redraw event). Perhaps Xpra could force a redraw event after
opening the window?
I bet it's not a redraw event but a window "configure notification" that
gvim is waiting for. If I can reproduce this, it should be fixable. We
can synthesize an event if needed.
What's the server version? CentOS 7.5?
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
4. dialog box black bars (appears to be trying to add scrollbars?).
Can you provide example applications we can use to reproduce the
problem?
I've never seen that anywhere except when X11 windows are smaller than
the minimal window size on mswindows, then we have to pad it with
something.
Perhaps that's all it is.
Sadly, it's not. From the screenshot you attached, this looks like a
different problem.
Post by Ben Sferrazza via shifter-users
Certainly not a big deal, and just a cosmetic
annoyance. I've attached an example of this issue from a dialog box that
pops up using diffuse. Perhaps this would be too much work, but a
slightly more pleasing visual than black bars would be to sample the
color of the edge pixels and use this color (or an average of samples)
to extend the window to the minimum size.
Fixing the problem might be easier. (it looks similar to the gvim
problem - the application gets the window geometry wrong)
Do you have a sample application I can use to reproduce it?
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
5. windows are all blank (white) when returning into work after
several
Post by Ben Sferrazza via shifter-users
hours (requires restarting client)
That's a known "feature" of some opengl drivers, they clear the video
memory when the system goes into idle or suspended state.
We try to detect that (slowing down the refresh rate) and then refresh
the screen when the session resumes, but that doesn't always fix things.
You should not need to restart the client: minimizing the windows and
restoring them should be enough.
Alternatively, turn off opengl in the client - the client performance
will be much lower.
OK, the next time this occurs I'll try to simply minimize the windows.
 
Post by Ben Sferrazza via shifter-users
6. flickering clipboard icon in systray
That's a very obvious sign that something is not right and something is
constantly requesting the clipboard contents. This will cause
unnecessary traffic and instability. Try to figure out what is causing
this and stop it. Usually, this is caused by clipboard managers or other
clipboard synchronization tools (synergy, virtualbox, etc).
Hmm. I don't have anything running like that. No VNC session,
VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly
nothing is currently connected to it. It seems to flicker at a rate of
once every 4 seconds or so.
OK, then it's not so bad that it will cause instability.
Some clipboard managers request the clipboard contents as soon as
they're available, swamping the system with clipboard events.
If you wish, you can confirm the rate of change by running the client
with: "--debug=clipboard"
Post by Ben Sferrazza via shifter-users
It seems periodic, in the mathematical sense
of the word. My PC at work is a standard issue Dell box. It has the
typical Dell bloatware and some Symantec security software (not much
control over this), but can't think of anything that could be
potentially interfering with the clipboard. Any suggestions how to
determine the cause?
Sorry, I don't know how. The API we use to interact with the clipboard
does not offer any information about the application which set or
queried the clipboard. Some third party tools may exist to monitor the
system at this level.

Cheers,
Antoine
Post by Ben Sferrazza via shifter-users
Thanks,
Ben
Ben Sferrazza via shifter-users
2018-08-30 18:05:00 UTC
Permalink
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Now that I've established a connection again with Xpra server 2.3.3, I
can try to address some of the issues I was/am experiencing. I haven't
used it enough to encounter the first two issues, which were the most
debilitating and largely made it unusable for me before (the stuck focus
issue and the disappearing mouse cursor). Once I can re-create those
I'll have more to offer.
Post by Ben Sferrazza via shifter-users
Hi. I'm including my previous correspondence below, as it will at
least
Post by Ben Sferrazza via shifter-users
offer some history about my setup and prior issues.
I stopped using Xpra a few months ago due to numerous bugs that
made it
Post by Ben Sferrazza via shifter-users
unusable (this is using a Linux server and Windows client).
1. windows get stuck with on-top focus
Which windows from which applications?
This was by far the most egregious bug. It seemed to happen at random
and affected all applications. Considering I do a lot of work in a
terminal, chances are it was a terminal such as xfce4-terminal. I will
report back once this occurs again. My only solution was to minimize the
window, rather than simply clicking on another window to give it focus.
This does ring a bell, but I don't think I ever saw it myself.
https://xpra.org/trac/ticket/713
https://xpra.org/trac/ticket/1381
This could be a platform specific bug (ie: affecting mswindows clients)
in which case the newer Python3 GTK3 builds may fare better.
Yes, those tickets describe the exact same behavior I'm experiencing (or at
least was with Xpra 2.2) using the Windows client and Linux server. I'll
give one of the Python3 builds a shot. Is there a particular build that you
think would be the most stable (with the understanding that I likely need
2.4 and the paramiko ssh client given the tcsh issues I was experiencing)?
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
2. disappearing mouse cursor when using X11-only no-toolkit apps
that use
Post by Ben Sferrazza via shifter-users
inverted black mouse pointer after clicking on something
Do you have a specific application we can use to reproduce the
problem?
Post by Ben Sferrazza via shifter-users
Unfortunately the application I encountered this issue with the most was
Cadence's Simvision, a digital simulation waveform viewer that's part of
their CAD/EDA software suite. The only observation I had was that it is
an application which does not make use of a modern toolkit, such as GTK.
Perhaps it's using Motif? When you click on a menu the mouse cursor
inverts to a right-pointing black cursor, which is a cursor internal to
the program and is not replaced by the client's cursor. That's when the
menu items would disappear. I've attached a screenshot of it working,
which required using an actual camera, as the inverted black cursor is
not picked up by the Windows print screen function.
There were bugs in the cursor code on mswindows, including some fixed
quite recently, those could have caused the problems you describe - it
should now revert to the default cursor in case of failure.
OK that's great to hear. I'll keep an eye out to see if this bug occurs
with the newer builds
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
3. some windows don't show window bar until resized (e.g. gvim
always gets
Post by Ben Sferrazza via shifter-users
placed in upper-left without window bar)
Some applications do weird things with their geometry sometimes,
gvim is
Post by Ben Sferrazza via shifter-users
one of those. That said, I've just tried it and it worked fine and it
does seem to request to be placed in the top left corner.
Please provide more details so we can reproduce the window bar
problem.
Post by Ben Sferrazza via shifter-users
(ie: server os and version, gvim version, etc..)
This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra
2.3.3 on Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT
2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior.
It corrects itself once I do any resizing of the window (which must
initiate a redraw event). Perhaps Xpra could force a redraw event after
opening the window?
I bet it's not a redraw event but a window "configure notification" that
gvim is waiting for. If I can reproduce this, it should be fixable. We
can synthesize an event if needed.
What's the server version? CentOS 7.5?
Actually the primary machine I use it on is CentOS 5.11 (unfortunately
needed apparently to support an older version of Cadence IC5). Though I did
build an entirely bootstrapped toolchain on this machine, so its using the
latest glibc (2.19) for the older kernel it uses (2.6.18), as well as the
latest versions binutils and gcc. Xpra and all of its dependencies were
built against this toolchain. However, I did just run Xpra 2.3.3 on a
CentOS 7 machine we have here at work and with that same version of Gvim
(8.0.586) I experience the same issue of it going to the top left corner
and not showing the title bar until the window is resized.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
4. dialog box black bars (appears to be trying to add scrollbars?).
Can you provide example applications we can use to reproduce the
problem?
I've never seen that anywhere except when X11 windows are smaller
than
Post by Ben Sferrazza via shifter-users
the minimal window size on mswindows, then we have to pad it with
something.
Perhaps that's all it is.
Sadly, it's not. From the screenshot you attached, this looks like a
different problem.
Post by Ben Sferrazza via shifter-users
Certainly not a big deal, and just a cosmetic
annoyance. I've attached an example of this issue from a dialog box that
pops up using diffuse. Perhaps this would be too much work, but a
slightly more pleasing visual than black bars would be to sample the
color of the edge pixels and use this color (or an average of samples)
to extend the window to the minimum size.
Fixing the problem might be easier. (it looks similar to the gvim
problem - the application gets the window geometry wrong)
Do you have a sample application I can use to reproduce it?
It was happening using diffuse (the graphical diff tool). If I'm comparing
two files and edit one of them outside of diffuse, diffuse will pop up a
dialog asking if you'd like to reload the file since it detected a change.
That small dialog was showing the black borders. However, I'm not seeing
the same issue again. Though there is another issue that could perhaps be
masking this. For some reason, many of my GTK applications (diffuse, gvim,
etc) are not using the window decorations and icons I have chosen when
using Xpra. This was working just fine in Xpra 2.2, and the correct theme
and icons are shown when I VNC into the same machine. Oddly enough, Emacs
does use the correct decorations even with the latest Xpra.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
5. windows are all blank (white) when returning into work after
several
Post by Ben Sferrazza via shifter-users
hours (requires restarting client)
That's a known "feature" of some opengl drivers, they clear the video
memory when the system goes into idle or suspended state.
We try to detect that (slowing down the refresh rate) and then
refresh
Post by Ben Sferrazza via shifter-users
the screen when the session resumes, but that doesn't always fix
things.
Post by Ben Sferrazza via shifter-users
You should not need to restart the client: minimizing the windows and
restoring them should be enough.
Alternatively, turn off opengl in the client - the client performance
will be much lower.
OK, the next time this occurs I'll try to simply minimize the windows.
Post by Ben Sferrazza via shifter-users
6. flickering clipboard icon in systray
That's a very obvious sign that something is not right and something
is
Post by Ben Sferrazza via shifter-users
constantly requesting the clipboard contents. This will cause
unnecessary traffic and instability. Try to figure out what is
causing
Post by Ben Sferrazza via shifter-users
this and stop it. Usually, this is caused by clipboard managers or
other
Post by Ben Sferrazza via shifter-users
clipboard synchronization tools (synergy, virtualbox, etc).
Hmm. I don't have anything running like that. No VNC session,
VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly
nothing is currently connected to it. It seems to flicker at a rate of
once every 4 seconds or so.
OK, then it's not so bad that it will cause instability.
Some clipboard managers request the clipboard contents as soon as
they're available, swamping the system with clipboard events.
If you wish, you can confirm the rate of change by running the client
with: "--debug=clipboard"
Post by Ben Sferrazza via shifter-users
It seems periodic, in the mathematical sense
of the word. My PC at work is a standard issue Dell box. It has the
typical Dell bloatware and some Symantec security software (not much
control over this), but can't think of anything that could be
potentially interfering with the clipboard. Any suggestions how to
determine the cause?
Sorry, I don't know how. The API we use to interact with the clipboard
does not offer any information about the application which set or
queried the clipboard. Some third party tools may exist to monitor the
system at this level.
Is there a way to turn off the flickering, just to avoid the annoyance of
it? Also, it seems the newer versions of Xpra place a small Xpra icon
imposed on top of a window's regular icon. Is there a way to turn off this
feature, as it's difficult for me to see the original icon, since it's
resized smaller.

Thanks,
Ben
Ben Sferrazza via shifter-users
2018-08-30 18:20:12 UTC
Permalink
Tried the Python3 builds of the Xpra 2.4 Windows client and unfortunately
it has a lot of graphics artifacts (ghosting when moving a terminal, some
applications being completely washed out and illegible, etc). I'll continue
to use the standard 2.4 build for the time being.
Post by Ben Sferrazza via shifter-users
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Now that I've established a connection again with Xpra server 2.3.3, I
can try to address some of the issues I was/am experiencing. I haven't
used it enough to encounter the first two issues, which were the most
debilitating and largely made it unusable for me before (the stuck focus
issue and the disappearing mouse cursor). Once I can re-create those
I'll have more to offer.
Post by Ben Sferrazza via shifter-users
Hi. I'm including my previous correspondence below, as it will at
least
Post by Ben Sferrazza via shifter-users
offer some history about my setup and prior issues.
I stopped using Xpra a few months ago due to numerous bugs that
made it
Post by Ben Sferrazza via shifter-users
unusable (this is using a Linux server and Windows client).
1. windows get stuck with on-top focus
Which windows from which applications?
This was by far the most egregious bug. It seemed to happen at random
and affected all applications. Considering I do a lot of work in a
terminal, chances are it was a terminal such as xfce4-terminal. I will
report back once this occurs again. My only solution was to minimize the
window, rather than simply clicking on another window to give it focus.
This does ring a bell, but I don't think I ever saw it myself.
https://xpra.org/trac/ticket/713
https://xpra.org/trac/ticket/1381
This could be a platform specific bug (ie: affecting mswindows clients)
in which case the newer Python3 GTK3 builds may fare better.
Yes, those tickets describe the exact same behavior I'm experiencing (or
at least was with Xpra 2.2) using the Windows client and Linux server. I'll
give one of the Python3 builds a shot. Is there a particular build that you
think would be the most stable (with the understanding that I likely need
2.4 and the paramiko ssh client given the tcsh issues I was experiencing)?
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
2. disappearing mouse cursor when using X11-only no-toolkit apps
that use
Post by Ben Sferrazza via shifter-users
inverted black mouse pointer after clicking on something
Do you have a specific application we can use to reproduce the
problem?
Post by Ben Sferrazza via shifter-users
Unfortunately the application I encountered this issue with the most was
Cadence's Simvision, a digital simulation waveform viewer that's part of
their CAD/EDA software suite. The only observation I had was that it is
an application which does not make use of a modern toolkit, such as GTK.
Perhaps it's using Motif? When you click on a menu the mouse cursor
inverts to a right-pointing black cursor, which is a cursor internal to
the program and is not replaced by the client's cursor. That's when the
menu items would disappear. I've attached a screenshot of it working,
which required using an actual camera, as the inverted black cursor is
not picked up by the Windows print screen function.
There were bugs in the cursor code on mswindows, including some fixed
quite recently, those could have caused the problems you describe - it
should now revert to the default cursor in case of failure.
OK that's great to hear. I'll keep an eye out to see if this bug occurs
with the newer builds
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
3. some windows don't show window bar until resized (e.g. gvim
always gets
Post by Ben Sferrazza via shifter-users
placed in upper-left without window bar)
Some applications do weird things with their geometry sometimes,
gvim is
Post by Ben Sferrazza via shifter-users
one of those. That said, I've just tried it and it worked fine and
it
Post by Ben Sferrazza via shifter-users
does seem to request to be placed in the top left corner.
Please provide more details so we can reproduce the window bar
problem.
Post by Ben Sferrazza via shifter-users
(ie: server os and version, gvim version, etc..)
This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra
2.3.3 on Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT
2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior.
It corrects itself once I do any resizing of the window (which must
initiate a redraw event). Perhaps Xpra could force a redraw event after
opening the window?
I bet it's not a redraw event but a window "configure notification" that
gvim is waiting for. If I can reproduce this, it should be fixable. We
can synthesize an event if needed.
What's the server version? CentOS 7.5?
Actually the primary machine I use it on is CentOS 5.11 (unfortunately
needed apparently to support an older version of Cadence IC5). Though I did
build an entirely bootstrapped toolchain on this machine, so its using the
latest glibc (2.19) for the older kernel it uses (2.6.18), as well as the
latest versions binutils and gcc. Xpra and all of its dependencies were
built against this toolchain. However, I did just run Xpra 2.3.3 on a
CentOS 7 machine we have here at work and with that same version of Gvim
(8.0.586) I experience the same issue of it going to the top left corner
and not showing the title bar until the window is resized.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
4. dialog box black bars (appears to be trying to add
scrollbars?).
Post by Ben Sferrazza via shifter-users
Can you provide example applications we can use to reproduce the
problem?
I've never seen that anywhere except when X11 windows are smaller
than
Post by Ben Sferrazza via shifter-users
the minimal window size on mswindows, then we have to pad it with
something.
Perhaps that's all it is.
Sadly, it's not. From the screenshot you attached, this looks like a
different problem.
Post by Ben Sferrazza via shifter-users
Certainly not a big deal, and just a cosmetic
annoyance. I've attached an example of this issue from a dialog box that
pops up using diffuse. Perhaps this would be too much work, but a
slightly more pleasing visual than black bars would be to sample the
color of the edge pixels and use this color (or an average of samples)
to extend the window to the minimum size.
Fixing the problem might be easier. (it looks similar to the gvim
problem - the application gets the window geometry wrong)
Do you have a sample application I can use to reproduce it?
It was happening using diffuse (the graphical diff tool). If I'm comparing
two files and edit one of them outside of diffuse, diffuse will pop up a
dialog asking if you'd like to reload the file since it detected a change.
That small dialog was showing the black borders. However, I'm not seeing
the same issue again. Though there is another issue that could perhaps be
masking this. For some reason, many of my GTK applications (diffuse, gvim,
etc) are not using the window decorations and icons I have chosen when
using Xpra. This was working just fine in Xpra 2.2, and the correct theme
and icons are shown when I VNC into the same machine. Oddly enough, Emacs
does use the correct decorations even with the latest Xpra.
Post by Antoine Martin via shifter-users
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
5. windows are all blank (white) when returning into work after
several
Post by Ben Sferrazza via shifter-users
hours (requires restarting client)
That's a known "feature" of some opengl drivers, they clear the
video
Post by Ben Sferrazza via shifter-users
memory when the system goes into idle or suspended state.
We try to detect that (slowing down the refresh rate) and then
refresh
Post by Ben Sferrazza via shifter-users
the screen when the session resumes, but that doesn't always fix
things.
Post by Ben Sferrazza via shifter-users
You should not need to restart the client: minimizing the windows
and
Post by Ben Sferrazza via shifter-users
restoring them should be enough.
Alternatively, turn off opengl in the client - the client
performance
Post by Ben Sferrazza via shifter-users
will be much lower.
OK, the next time this occurs I'll try to simply minimize the windows.
Post by Ben Sferrazza via shifter-users
6. flickering clipboard icon in systray
That's a very obvious sign that something is not right and
something is
Post by Ben Sferrazza via shifter-users
constantly requesting the clipboard contents. This will cause
unnecessary traffic and instability. Try to figure out what is
causing
Post by Ben Sferrazza via shifter-users
this and stop it. Usually, this is caused by clipboard managers or
other
Post by Ben Sferrazza via shifter-users
clipboard synchronization tools (synergy, virtualbox, etc).
Hmm. I don't have anything running like that. No VNC session,
VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly
nothing is currently connected to it. It seems to flicker at a rate of
once every 4 seconds or so.
OK, then it's not so bad that it will cause instability.
Some clipboard managers request the clipboard contents as soon as
they're available, swamping the system with clipboard events.
If you wish, you can confirm the rate of change by running the client
with: "--debug=clipboard"
Post by Ben Sferrazza via shifter-users
It seems periodic, in the mathematical sense
of the word. My PC at work is a standard issue Dell box. It has the
typical Dell bloatware and some Symantec security software (not much
control over this), but can't think of anything that could be
potentially interfering with the clipboard. Any suggestions how to
determine the cause?
Sorry, I don't know how. The API we use to interact with the clipboard
does not offer any information about the application which set or
queried the clipboard. Some third party tools may exist to monitor the
system at this level.
Is there a way to turn off the flickering, just to avoid the annoyance of
it? Also, it seems the newer versions of Xpra place a small Xpra icon
imposed on top of a window's regular icon. Is there a way to turn off this
feature, as it's difficult for me to see the original icon, since it's
resized smaller.
Thanks,
Ben
Antoine Martin via shifter-users
2018-08-31 09:06:07 UTC
Permalink
Post by Ben Sferrazza via shifter-users
Tried the Python3 builds of the Xpra 2.4 Windows client and
unfortunately it has a lot of graphics artifacts (ghosting when moving a
terminal, some applications being completely washed out and illegible,
etc). I'll continue to use the standard 2.4 build for the time being.
Oh! The GTK3 port is meant to be almost complete... (at least for the
client, the server will need a lot more work)
This could be because of transparency issues. (I have no idea why a
terminal applications would use an alpha channel but some do..)
Was this with xfce_terminal again?
Did you have OpenGL enabled or disabled? (see systray menu toggle)
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
This was by far the most egregious bug. It seemed to happen at
random
Post by Ben Sferrazza via shifter-users
and affected all applications.
(..)
Post by Ben Sferrazza via shifter-users
This does ring a bell, but I don't think I ever saw it myself.
https://xpra.org/trac/ticket/713
https://xpra.org/trac/ticket/1381
This could be a platform specific bug (ie: affecting mswindows clients)
in which case the newer Python3 GTK3 builds may fare better.
Yes, those tickets describe the exact same behavior I'm experiencing
(or at least was with Xpra 2.2) using the Windows client and Linux
server. I'll give one of the Python3 builds a shot. Is there a
particular build that you think would be the most stable (with the
understanding that I likely need 2.4 and the paramiko ssh client
given the tcsh issues I was experiencing)?
Usually the latest, especially if you need the paramiko goodness.
(though I have had to revert some unrelated changes today)
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
     > 3. some windows don't show window bar until resized
(e.g. gvim
Post by Ben Sferrazza via shifter-users
     always gets
     > placed in upper-left without window bar)
(..)
Post by Ben Sferrazza via shifter-users
Actually the primary machine I use it on is CentOS 5.11
(unfortunately needed apparently to support an older version of
Cadence IC5). Though I did build an entirely bootstrapped toolchain
on this machine, so its using the latest glibc (2.19) for the older
kernel it uses (2.6.18), as well as the latest versions binutils and
gcc. Xpra and all of its dependencies were built against this
toolchain.
Wow. That's a *lot* of work!
Have you considered installing a CentOS 5 chroot inside a CentOS 7 host
and just sharing the X11 display between the two?
(ie: /tmp/.X11-unix/X100)
Post by Ben Sferrazza via shifter-users
However, I did just run Xpra 2.3.3 on a CentOS 7 machine
we have here at work and with that same version of Gvim (8.0.586) I
experience the same issue of it going to the top left corner and not
showing the title bar until the window is resized.
Will test and report back.
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
     > 4. dialog box black bars (appears to be trying to add
scrollbars?).
(..)
Post by Ben Sferrazza via shifter-users
Do you have a sample application I can use to reproduce it?
It was happening using diffuse (the graphical diff tool). If I'm
comparing two files and edit one of them outside of diffuse, diffuse
will pop up a dialog asking if you'd like to reload the file since
it detected a change. That small dialog was showing the black
borders. However, I'm not seeing the same issue again. Though there
is another issue that could perhaps be masking this. For some
reason, many of my GTK applications (diffuse, gvim, etc) are not
using the window decorations and icons I have chosen when using
Xpra.
How and where did you modify these settings?
Post by Ben Sferrazza via shifter-users
This was working just fine in Xpra 2.2, and the correct theme
and icons are shown when I VNC into the same machine. Oddly enough,
Emacs does use the correct decorations even with the latest Xpra.
Ah, the everlasting joy of themes and xsettings.
You may want to try --xsettings=no

(..)
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
     > 6. flickering clipboard icon in systray
Is there a way to turn off the flickering, just to avoid the
annoyance of it?
There is now, in 2.4:
http://xpra.org/trac/changeset/20251
To use it:
XPRA_CLIPBOARD_NOTIFY=0 xpra attach ...
Post by Ben Sferrazza via shifter-users
Also, it seems the newer versions of Xpra place a
small Xpra icon imposed on top of a window's regular icon. Is there
a way to turn off this feature, as it's difficult for me to see the
original icon, since it's resized smaller.
This should turn it off:
XPRA_ICON_OVERLAY=0 xpra attach ...
More details on the feature here:
http://xpra.org/trac/ticket/1707

Cheers,
Antoine
Antoine Martin via shifter-users
2018-09-01 09:05:59 UTC
Permalink
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
Tried the Python3 builds of the Xpra 2.4 Windows client and
unfortunately it has a lot of graphics artifacts (ghosting when
moving a
Post by Ben Sferrazza via shifter-users
terminal, some applications being completely washed out and illegible,
etc). I'll continue to use the standard 2.4 build for the time being.
Oh! The GTK3 port is meant to be almost complete... (at least for the
client, the server will need a lot more work)
This could be because of transparency issues. (I have no idea why a
terminal applications would use an alpha channel but some do..)
Was this with xfce_terminal again?
Did you have OpenGL enabled or disabled? (see systray menu toggle)
OK. I'm still on 2.3.3 for the server. I had tried the latest 2.4 Python
3 beta for Windows but had those issues. You're right that the terminal
background transparency was the cause for its ghosting (not sure if
there's a way to actually have the transparency work, as that would be
pretty cool). But still had washed out colors with the Cadence
applications I've mentioned (picture attached). OpenGL was disabled
(showing as n/a on the client) and have attached a picture of the
session information. Perhaps I should try getting OpenGL enabled?
Transparency normally works just fine, bar some platform quirks:
https://www.xpra.org/trac/ticket/1570
ie: we just don't use OpenGL on mswindows for windows with transparency
because it cannot be done with GTK3:
https://www.xpra.org/trac/ticket/1682

The visual artifacts you are seeing could be something caused by the
outdated libraries or bugs in CentOS 5.11, this is an unusual /
unsupported setup you have after all.

Anyway, you can turn off transparency completely on the server or on the
client with:
XPRA_ALPHA=0 xpra start ...
or
XPRA_ALPHA=0 xpra attach ..
Post by Ben Sferrazza via shifter-users
Post by Ben Sferrazza via shifter-users
This was working just fine in Xpra 2.2, and the correct theme
     and icons are shown when I VNC into the same machine. Oddly
enough,
Post by Ben Sferrazza via shifter-users
     Emacs does use the correct decorations even with the latest Xpra.
Ah, the everlasting joy of themes and xsettings.
You may want to try --xsettings=no
(..)
Post by Ben Sferrazza via shifter-users
         >     > 6. flickering clipboard icon in systray
     Is there a way to turn off the flickering, just to avoid the
     annoyance of it?
http://xpra.org/trac/changeset/20251
XPRA_CLIPBOARD_NOTIFY=0 xpra attach ...
Nice. I don't see a r20251 download yet in the beta builds, but look
forward to it.
Done.

Regarding your other points:
* seeing that no-one else has reported the "window stuck on top" focus
issue for a while, I am going to assume that this has been fixed until
someone can give me steps to reproduce the problem.
* the latest beta 2.4 builds work with any login shell (including csh
and tcsh) both with the new paramiko backend and even the plink.exe one,
I will try to backport these fixes to the 2.3 branch.
* gvim position and menu bar issues: I have failed to reproduce any of
the problems you describe using a stock CentOS 7.5 server with a MS
Windows 7, CentOS 7 and Fedora clients. I have tried both 2.3.3 and 2.4
beta builds at both ends.
I even tried it on a CentOS 6.x server with xpra 1.0.12, which does
place the window in the top left corner, but only with a 1.0 client.

I believe that covers all the points in your original email.
You should have fixes or workarounds for all the issues that can be
reproduced - let me know if I have missed something.

Cheers,
Antoine

Loading...