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...
On Wed, May 6, 2015 at 3:45 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi Ulrich, (Re-Cc:ing x2go-dev)
Can't someone add a Reply-To field for the mailing list?
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.
ok.
-> 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 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.
(b) desktop sessions in nxagent don't recognize client-side monitor (Xinerama) layout
Yes, they cannot know without my code.
- 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
But not in xdpyinfo because that is disabled in my code. Please verify.
(b.1) desktop sessions had no clue about monitor borders (no Xineramalayout) -> 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?
(b.2) desktop session knew about Xinerama and the desktop splittingworked 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 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 again if - after moving - you resize the window a bit?
-> this was observed on my PC at work (i386 system, Debianjessie)
Oh, 32bit, long time no see ;-)
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
agreed
o 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!
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.
Uli
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 <mike.gabriel@das-netzwerkteam.de> 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.
- 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
But 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 Xineramalayout) -> 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 splittingworked 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, Debianjessie)
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 upstream
agreed
o 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 completely
o 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: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Mike Gabriel -
Ulrich Sibiller