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

[Mike Gabriel]

Hi Paul,

On  Fr 07 Nov 2014 10:50:33 CET, paul.szabo wrote:

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


AWESOME!!! Looking forward to that/those patch/es.

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

ok...

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

OT here: Note that I plan to package MDM (the GDM2 fork in Linux Mint)  
for Debian. Depending on the cooperation upstream (Linux Mint) I may  
simply use their MDM version or even fork MDM (as MATE Display Manager  
then, or something similar).

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

/me nods on the above.

Thanks for your great and persevering work on this!
Mike


-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.alioth.debian.org/pipermail/pkg-x2go-devel/attachments/20141107/0487f2eb/attachment.sig>