[X2Go-Dev] improve Xinerama

[Mike Gabriel]

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 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/20150430/e466d6f1/attachment.pgp>