[winswitch] Xpra GL and gtkglext woes

[Ben Sferrazza]

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


On Wed, Aug 29, 2018 at 10:27 AM Ben Sferrazza <bsferrazza at avnera.com>
wrote:

>
>
> 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
>