Am 29.04.2015 00:37 schrieb "Mike Gabriel" <mike.gabriel@das-netzwerkteam.de>:
Hi Uli,
(any reason for going off-list?)
Stupid Gmail client in Android...
Well, I haven't thought about moving that code yet, but this would be a step in the right direction. It would solve all of the problems I mentioned in my first mail. But I still think the real solution would be to redirect xinerama requests to the real X server. Generally libnxcomp can handle all kinds of X11 requests so that redirection should not be too complicated. Caching/optimization can be implemented at a later time.
Ok. I missed that. (Had a full day with customer tasks etc. and could only fly over mails today).
If you are available for coding, maybe you feel like working on the
Xinerama change?
I am currently looking into this.
So cool!!!
I have a working version right now that asks the real X server for xinerama data. I have to do some code cleanup and will then put that to github.
However, I am still unsure about the correct solution here. Some questions that arise: programs/Xserver/randr/rrxinerama.c; the file I mentioned yesterday is
- do we need a switch to disable that lookup? Why is xinerama disabled by default when configuring new x2go sessions?
- do we need a notification from the nxproxy when the xinerama setup changes during connection?
- xinerama is integrated into xrandr (in
compiled and included, but not used apparently). Does hooking in there produce any side effects? Currently clients asking nxagent for xinerama info get the values from the real server but there are internal structures that are not updated.
- is there a need to keep the current solution with LD_LIBRARY_PATH ? (I'd say no)
Uli
Hi Ulrich,
On Do 30 Apr 2015 03:10:40 CEST, Ulrich Sibiller wrote:
If you are available for coding, maybe you feel like working on the
Xinerama change?
I am currently looking into this.
So cool!!!
I have a working version right now that asks the real X server for xinerama data. I have to do some code cleanup and will then put that to github.
Very nice!
However, I am still unsure about the correct solution here. Some questions that arise:
- do we need a switch to disable that lookup? Why is xinerama disabled by default when configuring new x2go sessions?
In nxagent, there is +xinerama and -xinerama as cmdline option (or
{-|+} extension Xinerama). IMHO these typical XServer options should
be usable for nxagent. Is that possible?
The reasons for Xinerama being off by default in X2Go Client:
o when new features get added, the default is the previous situation until the new feature is tested well enough o old servers may not have Xinerama support, yet (at the time of releasing the feature in X2Go Client) o Xinerama in X2Go has been buggy again and again (due to packaging issues in the various distros that nx-libs is packaged for; due to bugs in X2Go Client when creating xinerama.conf)
IMHO, Xinerama enabled should be the default for nx-libs 3.6.x. Esp.
if it does not require a xinerama.conf file anymore (i.e., an
interaction by the remote session client).
- do we need a notification from the nxproxy when the xinerama setup changes during connection?
Yes. In general, the geometry of an X2Go desktop session window (and
thus the "Xinerama borders" inside) can change.
Use cases that should work:
o rootless session mode (single applications, running in nxagent, being nxproxied to the client should be aware of the client-side Xserver's Xinerama settings), the nxagent session should be notified by geometry changes of the client-side Xserver
Question: should application windows be de-maximized on geometry
changes? Or re-maximized? Or ...?o fullscreen desktop session mode (the Xinerama settings of the client-side Xserver should be available inside the fullscreen desktop session running in nxagent), the nxagent session should be notified by geometry changes of the client-side Xserver
Note: as you don't have access to the client-side Xserver controls
(except from an outside shell with xrandr cmdline tool), geometry
changes in this use case are probably really rare.o windowed desktop session mode (tricky, see below)
The most tricky part may be nxagent's windowed desktop sessions. This
little experiment should work with the new implementation:
o launch a desktop session with 1024x768, e.g. MATE desktop
o move this window, so that parts of it are on the primary screen,
the rest is on the secondary screen
o open a terminal (or whatever) in the MATE desktop session in nxagent
o move the terminal to the nxagent session area that is on the
primary monitor
(or the secondary) and maximize that terminal window there
o the terminal window should only be maximized to the part of the nxagent
session that resides on the primary monitor
o now unmaximize o and move the nxagent window around (or resize it), change the "Xinerama border" inside the nxagent session
o try the above terminal experiment again, the terminal window should maximize to the new "Xinerama border" that resulted from nxagent window moving and resizing
- xinerama is integrated into xrandr (in programs/Xserver/randr/rrxinerama.c; the file I mentioned yesterday is compiled and included, but not used apparently). Does hooking in there produce any side effects? Currently clients asking nxagent for xinerama info get the values from the real server but there are internal structures that are not updated.
Not sure about this without looking into the code any deeper.
Basically, NoMachine also patched libXrandr heavily in an NX.
Partially for backporting xrandr 1.2 proto version (IIRC), but
possible also for some NX specific stuff (haven't looked any close so
far). So maybe the xrandr implementation in programs/Xserver/randr
also depends on the patched libNX_Xrandr.
- is there a need to keep the current solution with LD_LIBRARY_PATH ? (I'd say no)
No, it was only used for enabling Xinerama support in X2Go sessions.
If nxagent can be compiled against libXinerama from X.Org and the
Xinerama magic resided in programs/Xserver/**, then setting
LD_LIBRARY_PATH can be dropped completely from X2Go/NX.
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 Thu, Apr 30, 2015 at 5:18 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
However, I am still unsure about the correct solution here. Some questions that arise:
- do we need a switch to disable that lookup? Why is xinerama disabled by default when configuring new x2go sessions?
In nxagent, there is +xinerama and -xinerama as cmdline option (or {-|+} extension Xinerama). IMHO these typical XServer options should be usable for nxagent. Is that possible?
I had already tried them, but they seem to be broken currently. This is probably because the XINERAMA extension is provided via the randr extension in the current code. If you run nxagent -extension RANDR then XINERAMA will be disabled, too.
The reasons for Xinerama being off by default in X2Go Client:
o when new features get added, the default is the previous situation until the new feature is tested well enough
Good strategy.
o old servers may not have Xinerama support, yet (at the time of releasing the feature in X2Go Client)
In this case the we take that as xinerama configuration with a single large screen. The nxagent will always know about xinerama.
o Xinerama in X2Go has been buggy again and again (due to packaging issues in the various distros that nx-libs is packaged for; due to bugs in X2Go Client when creating xinerama.conf)
Yes, I have noticed that. And I doubt that my changes will be perfect on the first shot...
IMHO, Xinerama enabled should be the default for nx-libs 3.6.x. Esp. if it does not require a xinerama.conf file anymore (i.e., an interaction by the remote session client).
When X11 did the transition from 6.9 to 7.0 they did not add a single feature. Maybe the even did omit bugfixes. The only difference between those two is the source code structure and the build process. So I think all those cleanup things you are doing should not be mixed with code changes, do you?
- do we need a notification from the nxproxy when the xinerama setup changes during connection?
Yes. In general, the geometry of an X2Go desktop session window (and thus the "Xinerama borders" inside) can change.
I have seen x2goclient already has that feature when I was doing the test you describe below. And those tests reveal that I need to intersect the client geometry with the xinerama information. For this to work I need to know the position of the nxproxy window (not the size, I think, RANDR has that information) . My code is currently located in the nxagent. How can I find out the position of the nxproxy window from the server side?
Apart from that I think the client side code for updating that information should move from x2goclient to nxproxy. This way all products using NX will benefit.
Use cases that should work:
o rootless session mode (single applications, running in nxagent, being nxproxied to the client should be aware of the client-side Xserver's Xinerama settings), the nxagent session should be notified by geometry changes of the client-side Xserver
I think in rootless mode the nxagent should always cover the whole desktop. I am not sure if this is valid currently, but it really should. If that is the case this test should succeed. I will check again.
Question: should application windows be de-maximized on geometry changes? Or re-maximized? Or ...?
This is something the window manager within the session must handle. All window managers supporting randr should already be aware of geometry changes. In rootless mode the client side window manager will take care of that.
o fullscreen desktop session mode (the Xinerama settings of the client-side Xserver should be available inside the fullscreen desktop session running in nxagent), the nxagent session should be notified by geometry changes of the client-side Xserver
Fullscreen working currently, since I fetch that information directly from the client-side X server on every request .
Note: as you don't have access to the client-side Xserver controls (except from an outside shell with xrandr cmdline tool), geometry changes in this use case are probably really rare.
On my Thinkpad I can press Fn+F7 to cycle through several screen configurations which will change the number of screen and therefore will influence the xinerama setup. So this is quite normal.
o windowed desktop session mode (tricky, see below)
The most tricky part may be nxagent's windowed desktop sessions. This little
Yes, that case is tricky as it needs intersection. And here I have the mentioned problem: I need to know the position of the nxproxy window on the client-side X server
- xinerama is integrated into xrandr (in programs/Xserver/randr/rrxinerama.c; the file I mentioned yesterday is compiled and included, but not used apparently). Does hooking in there produce any side effects? Currently clients asking nxagent for xinerama info get the values from the real server but there are internal structures that are not updated.
Not sure about this without looking into the code any deeper. Basically, NoMachine also patched libXrandr heavily in an NX. Partially for backporting xrandr 1.2 proto version (IIRC), but possible also for some NX specific
BTW: I think we really need at least xrandr 1.3. to be able to add resolutions on the fly.
stuff (haven't looked any close so far). So maybe the xrandr implementation in programs/Xserver/randr also depends on the patched libNX_Xrandr.
Hmm, I haven't looked at the patched lib yet. The patched randr server code mainly does one think: replace dixLookupWindow() by SecurityLookupWindow().
But in general I would expect the libraries are NOT providing server functions put are provided for clients to use them. Isn't that the case? My local X server here on ubuntu 14.04 opens some X libraries but not libXinerama or libXrandr:
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
- is there a need to keep the current solution with LD_LIBRARY_PATH ? (I'd say no)
No, it was only used for enabling Xinerama support in X2Go sessions. If nxagent can be compiled against libXinerama from X.Org and the Xinerama magic resided in programs/Xserver/**, then setting LD_LIBRARY_PATH can be dropped completely from X2Go/NX.
OK.
I think until that problem with the client window position is solved I will implement the halfway solution that still refers to $NX_XINERAMA_CONFIG but will work without the LD_LIBRARY_PATH hack.
Uli
Hi Ulrich,
On Fri, May 01, 2015 at 01:13:01PM +0200, Ulrich Sibiller wrote:
On Thu, Apr 30, 2015 at 5:18 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
However, I am still unsure about the correct solution here. Some questions that arise:
- do we need a switch to disable that lookup? Why is xinerama disabled by default when configuring new x2go sessions?
In nxagent, there is +xinerama and -xinerama as cmdline option (or {-|+} extension Xinerama). IMHO these typical XServer options should be usable for nxagent. Is that possible?
I had already tried them, but they seem to be broken currently. This is probably because the XINERAMA extension is provided via the randr extension in the current code. If you run nxagent -extension RANDR then XINERAMA will be disabled, too.
Ok... interesting...
The reasons for Xinerama being off by default in X2Go Client:
o when new features get added, the default is the previous situation until the new feature is tested well enough
Good strategy.
o old servers may not have Xinerama support, yet (at the time of releasing the feature in X2Go Client)
In this case the we take that as xinerama configuration with a single large screen. The nxagent will always know about xinerama.
If Xinerama support in nx-libs 3.6.x can be handled without any config option, at all, then we should enable it always and by default.
Maybe it is possible to make +xinerama / -xinerama functional again, so that nxagent has the option to disable xinerama (via xrandr).
o Xinerama in X2Go has been buggy again and again (due to packaging issues in the various distros that nx-libs is packaged for; due to bugs in X2Go Client when creating xinerama.conf)
Yes, I have noticed that. And I doubt that my changes will be perfect on the first shot...
Oh, don't worry about that!
IMHO, Xinerama enabled should be the default for nx-libs 3.6.x. Esp. if it does not require a xinerama.conf file anymore (i.e., an interaction by the remote session client).
When X11 did the transition from 6.9 to 7.0 they did not add a single feature. Maybe the even did omit bugfixes. The only difference between those two is the source code structure and the build process. So I think all those cleanup things you are doing should not be mixed with code changes, do you?
We are actuall mixing code cleanup work, CVE hunting, bug fixes, build fixes, etc. at the moment.
I try to avoid bringing in new features, but maybe I will even start working on getting XComposite available and fixed in nx-libs, soon.
- do we need a notification from the nxproxy when the xinerama setup changes during connection?
Yes. In general, the geometry of an X2Go desktop session window (and thus the "Xinerama borders" inside) can change.
I have seen x2goclient already has that feature when I was doing the test you describe below. And those tests reveal that I need to intersect the client geometry with the xinerama information. For this to work I need to know the position of the nxproxy window (not the size, I think, RANDR has that information) . My code is currently located in the nxagent. How can I find out the position of the nxproxy window from the server side?
Phew... good question. The way it is done is this:
o X2Go Client detects the X window ID of the nxproxy instance o X2Go Client queries the client-side Xserver for the window position of nxproxy (by using the exact X window ID) o X2Go Client does the calculation internally (intersecting nxproxy position and size with client-side Xserver's Xinerama borders
I'd say this requires a patch in nxproxy, so that it knows its position all by itself. Or maybe even let nxproxy do the intersecting???
Apart from that I think the client side code for updating that information should move from x2goclient to nxproxy. This way all products using NX will benefit.
/me nods on that! Great!!!
Use cases that should work:
o rootless session mode (single applications, running in nxagent, being nxproxied to the client should be aware of the client-side Xserver's Xinerama settings), the nxagent session should be notified by geometry changes of the client-side Xserver
I think in rootless mode the nxagent should always cover the whole desktop. I am not sure if this is valid currently, but it really should.
I think, it does this.
If that is the case this test should succeed. I will check again.
Ok.
Question: should application windows be de-maximized on geometry changes? Or re-maximized? Or ...?This is something the window manager within the session must handle. All window managers supporting randr should already be aware of geometry changes. In rootless mode the client side window manager will take care of that.
Ok. For my i3 tiling window manager I can say that it works with rootless NX/X2Go sessions. I guess, it will work with other WMs, too.
o fullscreen desktop session mode (the Xinerama settings of the client-side Xserver should be available inside the fullscreen desktop session running in nxagent), the nxagent session should be notified by geometry changes of the client-side Xserver
Fullscreen working currently, since I fetch that information directly from the client-side X server on every request .
Ok. Cool.
Note: as you don't have access to the client-side Xserver controls (except from an outside shell with xrandr cmdline tool), geometry changes in this use case are probably really rare.On my Thinkpad I can press Fn+F7 to cycle through several screen configurations which will change the number of screen and therefore will influence the xinerama setup. So this is quite normal.
Ah, right. Ok...
o windowed desktop session mode (tricky, see below)
The most tricky part may be nxagent's windowed desktop sessions. This little
Yes, that case is tricky as it needs intersection. And here I have the mentioned problem: I need to know the position of the nxproxy window on the client-side X server
See above.
- xinerama is integrated into xrandr (in programs/Xserver/randr/rrxinerama.c; the file I mentioned yesterday is compiled and included, but not used apparently). Does hooking in there produce any side effects? Currently clients asking nxagent for xinerama info get the values from the real server but there are internal structures that are not updated.
Not sure about this without looking into the code any deeper. Basically, NoMachine also patched libXrandr heavily in an NX. Partially for backporting xrandr 1.2 proto version (IIRC), but possible also for some NX specific
BTW: I think we really need at least xrandr 1.3. to be able to add resolutions on the fly.
Ok. I can take a look at that.
stuff (haven't looked any close so far). So maybe the xrandr implementation in programs/Xserver/randr also depends on the patched libNX_Xrandr.
Hmm, I haven't looked at the patched lib yet. The patched randr server code mainly does one think: replace dixLookupWindow() by SecurityLookupWindow().
Ok...
But in general I would expect the libraries are NOT providing server functions put are provided for clients to use them. Isn't that the case? My local X server here on ubuntu 14.04 opens some X libraries but not libXinerama or libXrandr:
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
At build time, dpkg-shlibdeps (or what's-its-name) indeed reports about unnecessarily linked libraries for nxagent. IIRC, libNX_Xinerama and libNX_Xrandr were among them.
Let me check that later. It would mean that we can drop libNX_Xrandr immediately and that we only have to update the Xserver code itself.
- is there a need to keep the current solution with LD_LIBRARY_PATH ? (I'd say no)
No, it was only used for enabling Xinerama support in X2Go sessions. If nxagent can be compiled against libXinerama from X.Org and the Xinerama magic resided in programs/Xserver/**, then setting LD_LIBRARY_PATH can be dropped completely from X2Go/NX.
OK.
I think until that problem with the client window position is solved I will implement the halfway solution that still refers to $NX_XINERAMA_CONFIG but will work without the LD_LIBRARY_PATH hack.
Maybe it would be good to keep both approaches in place for legacy support.
If a xinerama.conf file is present use that. If not, try out your new code.
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
Hi Ulrich,
On Fr 01 Mai 2015 13:39:42 CEST, Mike Gabriel wrote:
- xinerama is integrated into xrandr (in programs/Xserver/randr/rrxinerama.c; the file I mentioned yesterday is compiled and included, but not used apparently). Does hooking in there produce any side effects? Currently clients asking nxagent for xinerama info get the values from the real server but there are internal structures that are not updated.
Not sure about this without looking into the code any deeper. Basically, NoMachine also patched libXrandr heavily in an NX. Partially for
backporting xrandr 1.2 proto version (IIRC), but possible also for some NX specificBTW: I think we really need at least xrandr 1.3. to be able to add resolutions on the fly.
Ok. I can take a look at that.
http://code.x2go.org/gitweb?p=nx-libs.git;a=commitdiff;h=15cee47a496ef891923...
NoMachine actually did many changes on the Xserver's RandR extenion
part (not on the library part as I erroneously remembered).
[...] [...] [...]
At build time, dpkg-shlibdeps (or what's-its-name) indeed reports about unnecessarily linked libraries for nxagent. IIRC, libNX_Xinerama and libNX_Xrandr were among them.
Let me check that later. It would mean that we can drop libNX_Xrandr immediately and that we only have to update the Xserver code itself.
"""
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libnx-xcomposite1/usr/lib/x86_64-linux-gnu/libNX_Xcomposite.so.1.0 was
not linked against libNX_Xext.so.6 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libnx-xcomposite1/usr/lib/x86_64-linux-gnu/libNX_Xcomposite.so.1.0 was
not linked against libNX_Xfixes.so.3 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libnx-xcomposite1/usr/lib/x86_64-linux-gnu/libNX_Xcomposite.so.1.0 was
not linked against libNX_Xdamage.so.1 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libnx-xdamage1/usr/lib/x86_64-linux-gnu/libNX_Xdamage.so.1.0
was not linked against libNX_Xext.so.6 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libnx-xfixes3/usr/lib/x86_64-linux-gnu/libNX_Xfixes.so.3.0 was
not linked against libNX_Xext.so.6 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libnx-xrender1/usr/lib/x86_64-linux-gnu/libNX_Xrender.so.1.2.2
was not linked against libNX_Xext.so.6 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/nxagent/usr/lib/nx/bin/nxagent was not linked against
libNX_Xtst.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/nxagent/usr/lib/nx/bin/nxagent was not linked against
libNX_Xinerama.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/nxagent/usr/lib/nx/bin/nxagent was not linked against
libNX_Xdamage.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/nxagent/usr/lib/nx/bin/nxagent was not linked against
libNX_Xrandr.so.2 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/nxproxy/usr/lib/nx/bin/nxproxy was not linked against
libstdc++.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/nxproxy/usr/lib/nx/bin/nxproxy was not linked against
libgcc_s.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libxcomp3/usr/lib/x86_64-linux-gnu/libXcomp.so.3.5.99.0 was not
linked against libgcc_s.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libxcompext3/usr/lib/x86_64-linux-gnu/libXcompext.so.3.5.99.0
was not linked against libgcc_s.so.1 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libxcompext3/usr/lib/x86_64-linux-gnu/libXcompext.so.3.5.99.0
was not linked against libstdc++.so.6 (it uses none of the library's
symbols)
"""
So, yes, there is quite some internal over-linking in nx-libs.
I will fix that soon.
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 Fri, May 1, 2015 at 1:39 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi Ulrich,
On Fri, May 01, 2015 at 01:13:01PM +0200, Ulrich Sibiller wrote: If Xinerama support in nx-libs 3.6.x can be handled without any config option, at all, then we should enable it always and by default.
Well, thinking about that: there _could_ be people that want to emulate a really big screen and automatic xinerama would disturb.
Maybe it is possible to make +xinerama / -xinerama functional again, so that nxagent has the option to disable xinerama (via xrandr).
Hmm, I'll have a look.
o Xinerama in X2Go has been buggy again and again (due to packaging issues in the various distros that nx-libs is packaged for; due to bugs in X2Go Client when creating xinerama.conf)
Yes, I have noticed that. And I doubt that my changes will be perfect on the first shot...
Oh, don't worry about that!
Talking about the first shot: You'll find it attached, I don't want to go through that github hassle now (it's three o'clock in the morning..). But I will...
I try to avoid bringing in new features, but maybe I will even start working on getting XComposite available and fixed in nx-libs, soon.
So what's broken there?
located in the nxagent. How can I find out the position of the nxproxy window from the server side?
Phew... good question. The way it is done is this:
I found a solution, one just needs the root window (which is easy to get) and call XTranslateCoordinates() with the nxproxy window. Took me some time to work that out, but in the end it's easy.
o X2Go Client detects the X window ID of the nxproxy instance o X2Go Client queries the client-side Xserver for the window position of nxproxy (by using the exact X window ID) o X2Go Client does the calculation internally (intersecting nxproxy position and size with client-side Xserver's Xinerama borders
I'd say this requires a patch in nxproxy, so that it knows its position all by itself. Or maybe even let nxproxy do the intersecting???
Apart from that I think the client side code for updating that information should move from x2goclient to nxproxy. This way all products using NX will benefit.
/me nods on that! Great!!!
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.
I think in rootless mode the nxagent should always cover the whole desktop. I am not sure if this is valid currently, but it really should.
I think, it does this.
It does not. Running nxagent -R :77 opens up an invisible window with a strange geometry. However, that does not matter because my code does not provide xinerama in rootless mode simply because it is not needed. In rootless mode the client side X server has xinerama and the client side window manager should handle that.
Yes, that case is tricky as it needs intersection. And here I have the mentioned problem: I need to know the position of the nxproxy window on the client-side X server
solved, intersection is implemented and working fine.
Let me check that later. It would mean that we can drop libNX_Xrandr immediately and that we only have to update the Xserver code itself.
Yeah, i'd like that!
I think until that problem with the client window position is solved I will implement the halfway solution that still refers to $NX_XINERAMA_CONFIG but will work without the LD_LIBRARY_PATH hack.
Maybe it would be good to keep both approaches in place for legacy support.
If a xinerama.conf file is present use that. If not, try out your new code.
My current version (attached) does this:
- if env is not set use auto_xinerama
- if env is set to "auto" use auto_xinerama
- if env points to existing file use file_xinerama
- else use original code
We can work out something better if you like.
Please have a look at my code and test.
Uli
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.
I think in rootless mode the nxagent should always cover the whole desktop. I am not sure if this is valid currently, but it really should.
I think, it does this.
It does not. Running nxagent -R :77 opens up an invisible window with a strange geometry. However, that does not matter because my code does not provide xinerama in rootless mode simply because it is not needed. 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?
Yes, that case is tricky as it needs intersection. And here I have the mentioned problem: I need to know the position of the nxproxy window on the client-side X server
solved, intersection is implemented and working fine.
Btw, why do you need to know the position of nxproxy's window? I would have thought it doesn't really matter?
Let me check that later. It would mean that we can drop libNX_Xrandr immediately and that we only have to update the Xserver code itself.
Yeah, i'd like that!
I think until that problem with the client window position is solved I will implement the halfway solution that still refers to $NX_XINERAMA_CONFIG but will work without the LD_LIBRARY_PATH hack.
Maybe it would be good to keep both approaches in place for legacy support.
If a xinerama.conf file is present use that. If not, try out your new code.
My current version (attached) does this:
- if env is not set use auto_xinerama
- if env is set to "auto" use auto_xinerama
- if env points to existing file use file_xinerama
- else use original code
We can work out something better if you like.
Good approach.
Mihai
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
On Fri, May 1, 2015 at 7:13 AM, Ulrich Sibiller <uli42@gmx.de> wrote:
On Thu, Apr 30, 2015 at 5:18 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
IMHO, Xinerama enabled should be the default for nx-libs 3.6.x. Esp. if it does not require a xinerama.conf file anymore (i.e., an interaction by the remote session client).
When X11 did the transition from 6.9 to 7.0 they did not add a single feature. Maybe the even did omit bugfixes. The only difference between those two is the source code structure and the build process. So I think all those cleanup things you are doing should not be mixed with code changes, do you?
The difference is that we are moving from X.org 6.9 libraries to approximately X.org 7.7 libraries. (Whatever version the Linux distro provides.) Many new features have been added to those libraries since 6.9/7.0. So we cannot change our build system without adding new features.
-Mike#2
On Sat, May 2, 2015 at 3:34 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
When X11 did the transition from 6.9 to 7.0 they did not add a single feature. Maybe the even did omit bugfixes. The only difference between those two is the source code structure and the build process. So I think all those cleanup things you are doing should not be mixed with code changes, do you?
The difference is that we are moving from X.org 6.9 libraries to approximately X.org 7.7 libraries. (Whatever version the Linux distro provides.) Many new features have been added to those libraries since 6.9/7.0. So we cannot change our build system without adding new features.
I think the easier way to move to a current X base is to to that very same setup change the X11 people did in the 6.9 -> 7.0 transition. After that pulling in 7.1 to 7.7 in order should be (relatively) easy. And when 7.7 is reached the real code changes can be introduced step by step.
Changing the order might lead to a more stable and more secure nx but make transition complicated.
Maybe the middle way is the best: remove unused stuff, then do the 7.0 transition, then go up to 7.7, and then add new features.
Uli
Hi,
you can checkout my current version from https://github.com/uli42/nx-libs (branches feature/new-xinerama(-3.6.x)). I am unsure if I should start a pull request before anyone had a look at it...
Uli
Hi Ulrich,
On Sa 02 Mai 2015 23:32:31 CEST, Ulrich Sibiller wrote:
Hi,
you can checkout my current version from https://github.com/uli42/nx-libs (branches feature/new-xinerama(-3.6.x)). I am unsure if I should start a pull request before anyone had a look at it...
Uli
actually please file a pull request now. Because then we can use the
overall diff to discuss your patch on Github.
During the PR discussion/review process you can always add patches on
top, that will be displayed in the PR diff. At the very end (before
merging) we will ask you to rebase your patch series against 3.6.x,
make one commit out of it and push that one final commit with --force
to your branch.
I have taken a short glance at your commits just now, but have no real
time for testing before the coming week. My little son is likely to
fall ill and I will be the one to stay at home with him if that comes
that way, so I will have time for looking at your diff on Thursday at
the earliest. If the boy will be well enough for day care, I will take
a look on Monday or Wednesday.
Thanks+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...
Hi Uli,
On Sa 02 Mai 2015 23:32:31 CEST, Ulrich Sibiller wrote:
Hi,
you can checkout my current version from https://github.com/uli42/nx-libs (branches feature/new-xinerama(-3.6.x)). I am unsure if I should start a pull request before anyone had a look at it...
Uli
please cherry-pick this commit [1] onto your branch. It removes the
libNX_Xinerama part from NX
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.
You can find that commit at the top of [2].
Mike
[1]
https://github.com/sunweaver/nx-libs/commit/cd8e2d5295e43098c8afbdab5591d9e4...
[2] https://github.com/sunweaver/nx-libs/commits/pr/libxinerama-cleanup
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...
-
Michael DePaulo -
Mihai Moldovan -
Mike Gabriel -
Ulrich Sibiller