Hi Ulrich, (Re-Cc:ing x2go-dev)
On Di 05 Mai 2015 23:51:16 CEST, Ulrich Sibiller wrote:
On Tue, May 5, 2015 at 12:04 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
please cherry-pick this commit [1] onto your branch. It removes the libNX_Xinerama part from NX
OK, done, also issued PR.
I tested nxagent now. I tested two things (see below). For both tests
I modified /usr/bin/x2gostartagent, so that NX_XINERAMA_CONF gets
explicitly set to auto. I also removed all LD_LIBRARY_PATH related
stuff from /usr/bin/x2goruncommand.
I built NX agent from
https://github.com/sunweaver/nx-libs/tree/pr/libxinerama-cleanup (top
commit hash cd8e2d5295e43098c8afbdab5591d9e46eb7c751 [1]). This build
does _not_ contain your patches.-> expectexd results: (a) rootless applications in nxagent don't recognize the
client-side monitor (Xinerama) layout (b) desktop sessions in nxagent don't recognize the client-side monitor (Xinerama) layout-> observed results: (a) rootless session were already Xinerama aware... (????) (b) desktop sessions in nxagent don't recognize client-side monitor (Xinerama) layout
I built NX agent from
https://github.com/sunweaver/nx-libs/commits/feature/new-xinerama-3.6.x (top
commit hash 15cccc136b6b9740ba558e02da918ad843795995). This build does
contain your patches.-> observed results (a) rootless sessions are Xinerama (b.1) desktop sessions had no clue about monitor borders (no
Xinerama layout) -> this was an nxagent built and launched on my notebook
(amd64 system, Debian jessie) (b.2) desktop session knew about Xinerama and the desktop
splitting worked fine on resize events (changing the X2Go session window size) -> moving the X2Go desktop session window across the
client-side desktop should triggering a Xinerama resizing (or rather the
end of movement) -> this was observed on my PC at work (i386 system, Debian jessie)
I have no clue why my notebook failed to provide Xinerama inside NX
agent, but maybe this should be investigated, once if have tackled the
issues you addressed below.
[1]
https://github.com/sunweaver/nx-libs/commit/cd8e2d5295e43098c8afbdab5591d9e4...
[2]
https://github.com/sunweaver/nx-libs/commit/15cccc136b6b9740ba558e02da918ad8...
I will have my dual head workstation around tomorrow and then test your code.
You may meanwhile (if time allows) also test your code with [1] applied on top.
Seems to work (you might need to change the code a litte to force usage of the _auto parts when testing with x2goclient).
However, I am not sure that this implementation represents final solution. As you might have noticed my changes are included in the RandrRextension code. At first I did this simply because that is the code path that is used when Xinerama requests are issued. Meanwhile I found this (in
http://www.x.org/archive/X11R7.7/doc/randrproto/randrproto.txt):
11.2 Xinerama
Xinerama provides a mechanism for describing the relationship between the overall screen display and monitors placed within that area. As such, it provides the query functionality of RandR 1.2 without any of the configuration functionality. Applications using Xinerama to discover monitor geometry can continue to do so, with the caveat that they will not be informed of changes when they occur. However, Xinerama configuration data will be updated, so applications selecting for RandR notification and re-querying the configuration with the Xinerama extension will get updated information. It is probably better to view RandR as a superset of Xinerama at this point and use it in preference to Xinerama where both are present.
So basically the way to go is to let nxagent setup RandR in a way that the RandR extension itself will work without nx specific changes. I have been playing around with that approach yesterday and could it get to work (kind of, with lots of problems). I will have a look at this again soon.
If I succeed in this approach (which I am not sure about) this would mean:
- my current code would be obsolete
- Xinerama extension could be dropped completely
- RandR extension could stay unchanged (well, except for the existing changes introduced by nx) from the X11 distribution
- all relevant code is to be found in the nxagent directory.
The description above also contains a hint how to avoid having to issue an X request to the real X server whenever some inside client issues Xinerama requests: Use RandR for that and register nxagent to be notified of Xinerama/RandR changes. This way another roundtrip would be eliminated.
Does that sound reasonable?
Well, the more I think things through, every NX'ish speciality in the
current NX code tree has to be moved into Xserver/hw/nxagent for two
reasons:
o propose as few NX-specific patches as possible to X.Org upstream o every code snippet from NoMachine is licensed as GPLv2 and has to be removed from the xorg-server and lib<Xlib+extension> libraries.
Thus, same for your Xinerama patches, I guess. And if it is possible
to register an event that informs about Xinerama changes, the better.
And if it saves us some more roundtrips, again even better.
So, basically, also because of the issue about having to propose this
or that patch to X.Org upstream: the more of your code that you can
move into the hw/nxagent dir, the better!!!
Greets, Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...