[X2Go-Dev] improve Xinerama
Mike Gabriel
mike.gabriel at das-netzwerkteam.de
Thu Apr 30 05:18:54 CEST 2015
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>
More information about the x2go-dev
mailing list