[winswitch] Xpra GL and gtkglext woes

[Antoine Martin]

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'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?
(..)
> 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 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 below 1024 are restricted:
https://unix.stackexchange.com/questions/10735/

(..)
>>>> 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