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 p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
