[winswitch] Xpra GL and gtkglext woes

[Ben Sferrazza]

On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin <antoine at nagafix.co.uk>
wrote:

> On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote:
> > 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?
> > 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?
> > 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..)
> > 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.
> > 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.
> > 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.


> > 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
>
> > 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,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,067 251.9GB of system memory
> For real?
>

It's a 48-core server here at work.


> (..)
> > 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,308 updateprop(title, ~) previous value=xterm
> Nothing after that which means that the server never received a
> connection from the client.
>
>
> > *Client Log:*
> (..)
> > 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: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


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