Hi Ulrich, sorry for the late reply, the last two days have been crazy on its own...
On Do 07 Mai 2015 00:21:58 CEST, Ulrich Sibiller wrote:
On Wed, May 6, 2015 at 3:45 PM, Mike Gabriel <[email protected]> wrote:Hi Ulrich, (Re-Cc:ing x2go-dev)Can't someone add a Reply-To field for the mailing list?
This is not recommended by mailing list gurus, as it is a religious issue, see for further opinion forming [1].
-> 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... (????)Regarding window maximizing that's logical, because that is done by your local window manager that of course knows the xinerama. But I
Ah, ok. Got that.
doubt that the application itself is xinerama aware. Please verify by opening a rootless xterm and running "xdpyinfo -ext XINERAMA | grep head" in it. You should not see any output. Compare to same command run in a local xterm.
I still need to do that next week, won't get to it anymore before leaving home. I will also be away from keyboard at the weekend mostly.
(b) desktop sessions in nxagent don't recognize client-side monitor (Xinerama) layoutYes, they cannot know without my code.
Sure. This was expected.
2. 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 XineramaBut not in xdpyinfo because that is disabled in my code. Please verify.
This I still have to test and verify. Pending...
(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)Does xdpyinfo -ext XINERAMA -display :0 report anything on the nodebook?
This I still have to test, as well. I put a reminder for Monday into my calendar.
(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)Hmm, everytime a xdpyinfo request regarding xinerama is sent to the nxagent the xinerama data gets fetched from the real X server and therefor must be up-to-date. Moving the nxagent window obviously does not send any xinerama request to the nxagent. The window manager in
Exactly.
the session seems to cache the previous xinerama results because the root size has not changed. Can you verify with another window manager in the session? Which one did you use for that test? Does it work
Postponing to Monday.
again if - after moving - you resize the window a bit?
Yeah, I tested that. After moving a resize event will sort things out and Xinerama borders inside the session are aligned again with my physical monitor setup.
-> this was observed on my PC at work (i386 system, Debian jessie)Oh, 32bit, long time no see ;-)
hehe...
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 upstreamagreedo every code snippet from NoMachine is licensed as GPLv2 and has to be removed from the xorg-server and lib<Xlib+extension> libraries.So does that mean the current release has some license issues? Please tell me more!
The short version is this:X.Org is licensed under MIT/X11. It is allowed to have a hw-driver that has another license, but in libX11 & co. and in xorg-server, every bit of code must comply to MIT/X11 license (this really is the short version, so maybe inaccurate).
When NoMachine forked NX, the did something nasty, but legal. They licensed nxcomp under GPL-2 (strictly 2) and linked parts of nx-X11 against it. So they had to relincese the MIT/X11 stuff under GPL-2 (strict 2), as well.
Thus, when bringing patches upstream (X.Org upstream that is), we will not be able to use NoMachine originated code snippets (because they used another, stricter license).
Two solutions: o drop NoMachine patches introduced into nx-X11 completelyo move the NoMachine code into hw/nxagent/ (which can stay licensed under GPL-2)
o rewrite code that cannot be moved into hw/nxagent nor dropped
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!!!agreed.
Maybe you find some time to work on Xinerama. I wish I had more time for testing your code, I will try to free myself for that next week.
Greets + a good weekend! Mike [1] http://www.gnu.org/software/mailman/mailman-admin/node11.html -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: [email protected], http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgp46uqX0pvh2.pgp
Description: Digitale PGP-Signatur
_______________________________________________ x2go-dev mailing list [email protected] http://lists.x2go.org/listinfo/x2go-dev
