On Thu, Apr 30, 2015 at 5:18 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
However, I am still unsure about the correct solution here. Some questions that arise:
- do we need a switch to disable that lookup? Why is xinerama disabled by default when configuring new x2go sessions?
In nxagent, there is +xinerama and -xinerama as cmdline option (or {-|+} extension Xinerama). IMHO these typical XServer options should be usable for nxagent. Is that possible?
I had already tried them, but they seem to be broken currently. This is probably because the XINERAMA extension is provided via the randr extension in the current code. If you run nxagent -extension RANDR then XINERAMA will be disabled, too.
The reasons for Xinerama being off by default in X2Go Client:
o when new features get added, the default is the previous situation until the new feature is tested well enough
Good strategy.
o old servers may not have Xinerama support, yet (at the time of releasing the feature in X2Go Client)
In this case the we take that as xinerama configuration with a single large screen. The nxagent will always know about xinerama.
o Xinerama in X2Go has been buggy again and again (due to packaging issues in the various distros that nx-libs is packaged for; due to bugs in X2Go Client when creating xinerama.conf)
Yes, I have noticed that. And I doubt that my changes will be perfect on the first shot...
IMHO, Xinerama enabled should be the default for nx-libs 3.6.x. Esp. if it does not require a xinerama.conf file anymore (i.e., an interaction by the remote session client).
When X11 did the transition from 6.9 to 7.0 they did not add a single feature. Maybe the even did omit bugfixes. The only difference between those two is the source code structure and the build process. So I think all those cleanup things you are doing should not be mixed with code changes, do you?
- do we need a notification from the nxproxy when the xinerama setup changes during connection?
Yes. In general, the geometry of an X2Go desktop session window (and thus the "Xinerama borders" inside) can change.
I have seen x2goclient already has that feature when I was doing the test you describe below. And those tests reveal that I need to intersect the client geometry with the xinerama information. For this to work I need to know the position of the nxproxy window (not the size, I think, RANDR has that information) . My code is currently located in the nxagent. How can I find out the position of the nxproxy window from the server side?
Apart from that I think the client side code for updating that information should move from x2goclient to nxproxy. This way all products using NX will benefit.
Use cases that should work:
o rootless session mode (single applications, running in nxagent, being nxproxied to the client should be aware of the client-side Xserver's Xinerama settings), the nxagent session should be notified by geometry changes of the client-side Xserver
I think in rootless mode the nxagent should always cover the whole desktop. I am not sure if this is valid currently, but it really should. If that is the case this test should succeed. I will check again.
Question: should application windows be de-maximized on geometry changes? Or re-maximized? Or ...?
This is something the window manager within the session must handle. All window managers supporting randr should already be aware of geometry changes. In rootless mode the client side window manager will take care of that.
o fullscreen desktop session mode (the Xinerama settings of the client-side Xserver should be available inside the fullscreen desktop session running in nxagent), the nxagent session should be notified by geometry changes of the client-side Xserver
Fullscreen working currently, since I fetch that information directly from the client-side X server on every request .
Note: as you don't have access to the client-side Xserver controls (except from an outside shell with xrandr cmdline tool), geometry changes in this use case are probably really rare.
On my Thinkpad I can press Fn+F7 to cycle through several screen configurations which will change the number of screen and therefore will influence the xinerama setup. So this is quite normal.
o windowed desktop session mode (tricky, see below)
The most tricky part may be nxagent's windowed desktop sessions. This little
Yes, that case is tricky as it needs intersection. And here I have the mentioned problem: I need to know the position of the nxproxy window on the client-side X server
- xinerama is integrated into xrandr (in programs/Xserver/randr/rrxinerama.c; the file I mentioned yesterday is compiled and included, but not used apparently). Does hooking in there produce any side effects? Currently clients asking nxagent for xinerama info get the values from the real server but there are internal structures that are not updated.
Not sure about this without looking into the code any deeper. Basically, NoMachine also patched libXrandr heavily in an NX. Partially for backporting xrandr 1.2 proto version (IIRC), but possible also for some NX specific
BTW: I think we really need at least xrandr 1.3. to be able to add resolutions on the fly.
stuff (haven't looked any close so far). So maybe the xrandr implementation in programs/Xserver/randr also depends on the patched libNX_Xrandr.
Hmm, I haven't looked at the patched lib yet. The patched randr server code mainly does one think: replace dixLookupWindow() by SecurityLookupWindow().
But in general I would expect the libraries are NOT providing server functions put are provided for clients to use them. Isn't that the case? My local X server here on ubuntu 14.04 opens some X libraries but not libXinerama or libXrandr:
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
- is there a need to keep the current solution with LD_LIBRARY_PATH ? (I'd say no)
No, it was only used for enabling Xinerama support in X2Go sessions. If nxagent can be compiled against libXinerama from X.Org and the Xinerama magic resided in programs/Xserver/**, then setting LD_LIBRARY_PATH can be dropped completely from X2Go/NX.
OK.
I think until that problem with the client window position is solved I will implement the halfway solution that still refers to $NX_XINERAMA_CONFIG but will work without the LD_LIBRARY_PATH hack.
Uli