[X2Go-Dev] improve Xinerama

[Mike Gabriel]

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 at 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) layout
>
> Yes, 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 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 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 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 at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20150508/a9c0bf8b/attachment.pgp>