Anyway, having to install a WM in a TCE is not dumb stuff, it makes TCE acts
much more like a real desktop than without it (and thus, easier to debug and a
more uniform setup than with local fat client).
The real problem was this was not part of the x2gothinclient-displaymanager
install and so, you had to patch the installation by hand which is always risky.
BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403
13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Ulrich Sibiller" <ul...@gmx.de>
À: "Oleksandr Shneyder" <o.shney...@phoca-gmbh.de>
Envoyé: Jeudi 17 Mai 2018 14:56:17
Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE
On Thu, May 17, 2018 at 2:45 PM, Oleksandr Shneyder
> Am 17.05.2018 um 14:33 schrieb Ulrich Sibiller:
>> On Thu, May 17, 2018 at 2:13 PM, Oleksandr Shneyder
>> <o.shney...@phoca-gmbh.de> wrote:
>>> Nope, it looks for me, that nxproxy window get information about screens
>>> from WM. If WM is not started, nxproxy get just the window geometry.
>>> With started WM we have correct display information on server side.
>>> Xinerama starts to work with WM even if X2Go Session already running. I
>>> made some experiments like:
>>> 1. Starting tce without WM.
>>> 2. Connect to TC with ssh.
>>> 3. Open X2Go Session. At this moment Xinerama in X2Go session not
>>> working. I have one big screen over two monitors.
>> What exactly do you mean by "open x2go session"?
> I mean start X2Go session from TC
>>> 4. Starting WM on the TC. At this moment Xinerama starts to work in the
>>> running X2Go session immediately.
>>> It worked in TCE for me in 100% of cases. Independent when I'm starting
>>> WM - before X2Go Client, after X2Go Client or even when X2Go Session
>>> already running. I'll implement this solution in classic TCE and will
>>> let my customers test it.
>> I'd prefer understanding what's going on first. nxagent is running
> You can easily reproduce this issue by running x2goclient without WM.
> It's not really important for me now, why it's not working without WM. I
> think NX using some WM-Based function to determine screen configuration
> on the client side. I don't have resources to investigate this issue
> right now and it's not critical for me.
>> if (nxagentGrabServerInfo.grabstate == SERVER_GRABBED &&
>> nxagentGrabServerInfo.client != NULL)
>> And XineramaQueryScreens ins finally called in
>> nxagentAdjustRandRXinerama. BUT: If nxagentAdjustRandRXinerama FAILS
>> to get that data it will NOT fall back to the version you see but to
>> reporting ONE screen (called NX1, IIRC). So all this fails somewhere
> No, if I'm starting the session from TC without WM, I don't have screen
> with name NX1. xrandr output looks in this case like this:
> Screen 0: minimum 320 x 240, current 2560 x 1024, maximum 2560 x 1200
> default connected 2560x1024+0+0 0mm x 0mm
> 1360x768 60.00
> 320x240 60.00
> 1024x600 60.00
> 1280x800 60.00
> 1600x900 60.00
> 1600x1200 60.00
> Only if I starting session from TC with running WM, I have screens with
> names NX1, NX2, etc.
That's what I am saying. It is NOT the xinerama code going nuts, the
difference is happening somewhere else in nxagent. I will try to
determine the cause tonight.
x2go-dev mailing list
DISCLAIMER: This e-mail is private and confidential and may contain proprietary
or legally privileged information. It is for the intended recipient only. If
you have received this email in error, please notify the author by replying to
it and then destroy it. If you are not the intended recipient you must not use,
disclose, distribute, copy, print or rely on this e-mail or any attachment.
x2go-dev mailing list