On Sat, May 2, 2015 at 5:52 PM, Mihai Moldovan <ionic@ionic.de> wrote:
On 02.05.2015 03:08 AM, Ulrich Sibiller wrote:
Well, nxproxy isn't doing anything but calling some nx-library functions. Most of the stuff is done by the nxagent. You can see that by calling nxagent without nxproxy. I now have everything that's needed in the nxagent code (in only one file: randr/rrxinerama.c) except periodical updates (they are currently done only on demand). But even that could be added to the agent.
What I don't understand here is how this functionality could be moved to nxagent only. As nxagent is running remotely, it cannot possibly know the client's screen dimensions. This information must be passed to nxagent somehow -- currently x2goclient is doing it, but nxproxy is more predestined for this task as you already mentioned.
Maybe I'm misunderstanding something, though.
nxagent is derived from Xnest and acts as a server (for the clients in the session) and a client (to the real X server) at the same time. Both parts are implemented in the agent. The agent communicates with the real X server over normal X11 calls. So you can either run nxagent as an Xnest replacement (run e.g. nxagent :77) or as an remote client to real Xserver. From nxagent view there's no difference between the two modes.
Depending on the configured DISPLAY variable the X11 calls are either sent directly to the real Xserver or compressed/cached using the nx-libs and set to a remote X server. nxproxy justs sets up the communication from the real server side to the nxagent via some calls to the nx-libs. The libs only take care of compression and caching. All other logic resides in the nxagent code. Also the code to open the NX window on the client side is in the agent. So you can simply access the variable holding the pointer to that window structure and examine the window using normal Xlib calls. nxagent passes these calls to the nx-libs. These take care of the nx optimizations (possibly answering the call from the cache) and pass them to nxproxy's nx-libs. They sent the call to the real X server and pass back the answer.
Meanwhile I have found out that it is even simpler to get the geometry of the NX windows: In nxagentOptions you can find those values in X,Y,Width and Height. So there are no additional roundtrips needed to get that information.
In rootless mode the client side X server has xinerama and the client side window manager should handle that.
Yeah, but need client side resolution and server side resolution not match?
I do not know currently how that's handled internally. But when I open a rootless session here (nxagent -ac -R :77) on my Xinerama setup with two screens consisting of 1920x1200 + 1920x1080 Width and Height of the (invisible) NX window is 2880 x 900 (you can see this with xwininfo -id 0x4a0001a; so it's 75% of the complete desktop space). Opening an xterm on display 77 and maximizing it does not change the dimension of the NX window even if the xterm's height is now greater than 900. Maybe this has something to do with compositing, I don't know.
Btw, why do you need to know the position of nxproxy's window? I would have thought it doesn't really matter?
The task was to setup xinerama within the session in way that maximizing windows in there will respect the monitor borders of the real X server. So if you have an NX window that overlaps two real screens and you maximize a window in the session it should be fully visible on one of your monitors without crossing the borders. For this to work I need to map the configured xinerama setup to the NX session. And to do it is essential to know where that window is located in relation to the original xinerama setup.
We can work out something better if you like.
Good approach.
Have you tested my code?
Uli