[pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime

[paul.szabo at sydney.edu.au]

Dear Mike,

>> Maybe the issue is
>>   X Generic Event Extension
>>   http://www.x.org/releases/X11R7.7/doc/xextproto/geproto.html
>> of variable length, as yet un-supported by nxproxy?

Pre-empting anything below: I have now added code to nxproxy to
correctly handle (support) "X Generic Event Extension" messages,
and nautilus runs happy. - I will now test for a few more days,
clean up my code (removing the debug lines), then post the patches.

---

Seems that the issues I had with sequence numbers were a result
of nxproxy mis-interpreting the data stream: my GenEvt patches
seem to have "cured" those complaints.

---

> the question here again is if nautilus crashes
>    (a) in nxagent scenarios
>    (b) in nxproxy -S + Xvfb/Xephyr scenarios

I do not use nxagent, have no need for it.
I do not use Xvfb or Xephyr, but use the Xorg server.

> Do you test nautilus in some desktop shell (e.g. GNOMEv3) or do you 
> launch nautilus as a standalone (aka rootless, seamless) application?
>
> If server-side applications bind to nxproxy -S directly, then the code
> path (very roughly speaking) should be:
>
>    (1) nautilus
>    (1.1) libcairo
>    (1.2) lib-X.Org's client extensions (e.g. libXext, libXrandr, etc.)
>    (2) nxproxy -S
>    (3) nxproxy -C
>    (4) X.org server on client-side

What I have is: on the "thin client" I run:
  Xorg -query loginserver
  DISPLAY=:0 nxproxy -S
then log in to loginserver without any nxproxy involvement.

On loginserver I have GDM2 running with XDMCP enabled. At login I run
some session (maybe gnome or xfce or fluxbox, or something homegrown).
For now, manually (in an xterm) I run
  nxproxy -C link=1m connect=thinclient
and then use things like
  DISPLAY=:8 nautilus
(or "DISPLAY=:8 xterm" and run further things from there).

My plan, once nxproxy is "stable", is to run "nxproxy -C" within
/etc/gdm/Xsession and set the new DISPLAY there, so the whole login
session will go through nxproxy.

> Also, nautilus may request some extension not supported on our 
> client-side system. Or request an extension version that's not 
> available. ...

I have no idea what extensions the Xorg server, or clients like
nautilus, may handle.

My feeling is that nxproxy should be "transparent": if things work
without it (whatever both nautilus and Xorg handle), then nxproxy
should allow it unchanged. If nxproxy wants to be smart and make sense
of the X protocol (and achieve a better result than e.g. "ssh -C -X")
then it should be so (smart and actually understand the X protocol).

Cheers, Paul

Paul Szabo   psz at maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia