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