[X2Go-Dev] improve Xinerama

[Ulrich Sibiller]

On Sat, May 2, 2015 at 5:52 PM, Mihai Moldovan <ionic at 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