[X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE

[Stefan Baur]

Hi Alex,

Sorry, no solution yet, but we ran into the same issue yesterday/today
(with TCE-Live, not NFS).
What's worse is that it happens sometimes, but not always.
At first we thought it depended on the Desktop Environment/Window
Manager, but it seems to be a different issue than that.

Kind Regards,
Stefan Baur

Hi guys,
I have a strange issue. The Xinerama works well in full screen mode,
when x2goclient is started on desktop, but doesn't work if x2goclient
4.1.2.0-0x2go1~git20180514.1774+9.heuler.1
and same version of Debian - stretch. Session config identical as well.
Screen 0: minimum 320 x 240, current 4480 x 1080, maximum 4480 x 1200
NX1 connected 1920x1080+2560+0 0mm x 0mm
nx_1920x1080 60.00*
NX2 connected 2560x1080+0+0 0mm x 0mm
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
Although if session is started from TCE, I'm getting error dialog from
"unsupported number of arguments (3); falling back to default"
before I'm starting to look for the reason, maybe someone who tweaked on
Xinerama or on x2go server have any idea why it's happening?
regards,
Alex
_______________________________________________
x2go-dev mailing list
https://lists.x2go.org/listinfo/x2go-dev

[Stefan Baur]

This is a known bug I encountered and this is due to the lack of Window Manager.
Apparently, the WM is needed to have a good working xinerama.
============================================================================================
--- /usr/sbin/x2gothinclientd
+++ /usr/sbin/x2gothinclientd
@@ -175,6 +175,9 @@
}
}
+ # Spawn openbox
+ system("su - x2gothinclient -c \"DISPLAY=:0 openbox &\"");
+
# set screen background to X2Go default blue on all detected screens
`DISPLAY=:0 xsetroot -solid "#246ed8"`;
============================================================================================
I also did a few modifications to /etc/xdg/openbox/rc.xml to disable windows borders and a few stuff ... in fact these are just modifications you can find in the TCE Live Build project.
Please find my rc.xml attached.
Once you do this, everything works just like on your desktop.

... or not.

As I said, it also happens in TCE-Live, though only sometimes.
Hooooweveeeerr ... we include code to kill openbox once the NX window
comes up, so that the dreaded magic pixel won't trigger.

Maybe the act of disabling sometimes happens too soon, and we get a race
condition between the xinerama components and the magic-pixel-workaround.

Kind Regards,
Stefan Baur

[Stefan Baur]

The magic pixel can be disabled in nxagent 3.5.99.16.

Yes, but AFAIK X2GoClient doesn't make use of that feature in 4.1.1.1.
(I may be mistaken, though, so feel free to correct me)

Kind Regards,
Stefan Baur

[Walid MOGHRABI]

Post by Stefan Baur
As I said, it also happens in TCE-Live, though only sometimes.
Hooooweveeeerr ... we include code to kill openbox once the NX window
comes up, so that the dreaded magic pixel won't trigger.
Maybe the act of disabling sometimes happens too soon, and we get a race
condition between the xinerama components and the magic-pixel-workaround.

MagicPixel is not a problem anymore.
I filed a feature request which has been done to add a parameter to disable this behaviour directly at the nx level.
Just add the "-nomagicpixel" option in x2goagent.options

Regards,
Walid Moghrabi

TRAVAUX.COM
BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403
13591 AIX EN PROVENCE CEDEX 3

----- Mail original -----

De: "Stefan Baur" <X2Go-ML-***@baur-itcs.de>
À: x2go-***@lists.x2go.org
Envoyé: Mercredi 16 Mai 2018 15:19:00
Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE

Post by Stefan Baur
This is a known bug I encountered and this is due to the lack of Window Manager.
Apparently, the WM is needed to have a good working xinerama.
============================================================================================
--- /usr/sbin/x2gothinclientd
+++ /usr/sbin/x2gothinclientd
@@ -175,6 +175,9 @@
}
}
+ # Spawn openbox
+ system("su - x2gothinclient -c \"DISPLAY=:0 openbox &\"");
+
# set screen background to X2Go default blue on all detected screens
`DISPLAY=:0 xsetroot -solid "#246ed8"`;
============================================================================================
I also did a few modifications to /etc/xdg/openbox/rc.xml to disable windows borders and a few stuff ... in fact these are just modifications you can find in the TCE Live Build project.
Please find my rc.xml attached.
Once you do this, everything works just like on your desktop.

... or not.

As I said, it also happens in TCE-Live, though only sometimes.
Hooooweveeeerr ... we include code to kill openbox once the NX window
comes up, so that the dreaded magic pixel won't trigger.

Maybe the act of disabling sometimes happens too soon, and we get a race
condition between the xinerama components and the magic-pixel-workaround.

Kind Regards,
Stefan Baur
--
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax [phone] | USt-IdNr.: DE268653243


_______________________________________________
x2go-dev mailing list
x2go-***@lists.x2go.org
https://lists.x2go.org/listinfo/x2go-dev
---
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. Thank you

[Walid MOGHRABI]

I don't know, the only thing I know for sure is the fact that without adding a WM, it never worked.
Anyway, adding OpenBox and tweaking its conf is really nothing to do so I would say this is an acceptable fix for the TCE mode.

Regards,
Walid Moghrabi

TRAVAUX.COM
BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403
13591 AIX EN PROVENCE CEDEX 3

----- Mail original -----

De: "Ulrich Sibiller" <***@gmail.com>
À: "Stefan Baur" <X2Go-ML-***@baur-itcs.de>
Cc: x2go-***@lists.x2go.org
Envoyé: Mercredi 16 Mai 2018 15:48:54
Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE


The magic pixel can be disabled in nxagent 3.5.99.16.


I am wondering why the the WM is relevant. Nxagent is talking to the X server and not the WM. So what does xrandr report on the tce side with and without WM?


Uli

This is a known bug I encountered and this is due to the lack of Window Manager.
Apparently, the WM is needed to have a good working xinerama.
============================================================================================
--- /usr/sbin/x2gothinclientd
+++ /usr/sbin/x2gothinclientd
@@ -175,6 +175,9 @@
}
}
+ # Spawn openbox
+ system("su - x2gothinclient -c \"DISPLAY=:0 openbox &\"");
+
# set screen background to X2Go default blue on all detected screens
`DISPLAY=:0 xsetroot -solid "#246ed8"`;
============================================================================================
I also did a few modifications to /etc/xdg/openbox/rc.xml to disable windows borders and a few stuff ... in fact these are just modifications you can find in the TCE Live Build project.
Please find my rc.xml attached.
Once you do this, everything works just like on your desktop.

... or not.

As I said, it also happens in TCE-Live, though only sometimes.
Hooooweveeeerr ... we include code to kill openbox once the NX window
comes up, so that the dreaded magic pixel won't trigger.

Maybe the act of disabling sometimes happens too soon, and we get a race
condition between the xinerama components and the magic-pixel-workaround.

Kind Regards,
Stefan Baur
--
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax [phone] | USt-IdNr.: DE268653243

_______________________________________________
x2go-dev mailing list
x2go-***@lists.x2go.org
https://lists.x2go.org/listinfo/x2go-dev


_______________________________________________
x2go-dev mailing list
x2go-***@lists.x2go.org
https://lists.x2go.org/listinfo/x2go-dev
---
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. Thank you

[Walid MOGHRABI]

It has been done at the server side (this is not the default behaviour anyway and this is optionnal) because this was the easiest way to do it and as far as I'm concerned, this is what I want since I have a dedicated TCE server farm and there is no reason for my TCEs to have this MagicPixel sh*t and the workaround (which has the merit to exist) is as ugly as the "bug" itself.

To me, disabling MagicPixel (which is something barely useful) at the server side is perfect.
Feel free to give me a use case where this should be kept, I don't see any on my side.


Regards,
Walid Moghrabi

TRAVAUX.COM
BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403
13591 AIX EN PROVENCE CEDEX 3

----- Mail original -----

De: "Stefan Baur" <X2Go-ML-***@baur-itcs.de>
À: "Walid MOGHRABI" <***@servicemagic.eu>
Cc: x2go-***@lists.x2go.org, "ionic >> Mihai Moldovan" <***@ionic.de>
Envoyé: Mercredi 16 Mai 2018 15:55:55
Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE

Post by Walid MOGHRABI
MagicPixel is not a problem anymore.
I filed a feature request which has been done to add a parameter to disable this behaviour directly at the nx level.
Just add the "-nomagicpixel" option in x2goagent.options

Wait, that's on the server side and a per-server setting? That's not
where this should go. This SHOULD be a client-side option, triggered
e.g. by X2GoClient being called with "--thinclient", and active otherwise.

Kind Regards,
Stefan Baur

[Stefan Baur]

Post by Walid MOGHRABI
To me, disabling MagicPixel (which is something barely useful) at the server side is perfect.
Feel free to give me a use case where this should be kept, I don't see any on my side.

The use case is a mixed environment, where people are working from
regular workstations (Windows, macOS, Linux) as well as TCE terminals.

Working on a regular workstation, the magic pixel is actually handy,
because you can use it to go back to your local desktop without leaving
fullscreen mode - remember that on Windows, Ctrl+Alt+F is broken (causes
a VcXsrv crash).

Kind Regards,
Stefan Baur

[Ulrich Sibiller]

We can add that to the options string, so it can be switched depending on
the client's preference. No big deal...

Post by Walid MOGHRABI

Post by Walid MOGHRABI
To me, disabling MagicPixel (which is something barely useful) at the

server side is perfect.

Post by Walid MOGHRABI
Feel free to give me a use case where this should be kept, I don't see

any on my side.
The use case is a mixed environment, where people are working from
regular workstations (Windows, macOS, Linux) as well as TCE terminals.
Working on a regular workstation, the magic pixel is actually handy,
because you can use it to go back to your local desktop without leaving
fullscreen mode - remember that on Windows, Ctrl+Alt+F is broken (causes
a VcXsrv crash).
Kind Regards,
Stefan Baur
--
BAUR-ITCS UG (haftungsbeschrÀnkt)
GeschÀftsfÌhrer: Stefan Baur
EichenÀckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax [phone] | USt-IdNr.: DE268653243
_______________________________________________
x2go-dev mailing list
https://lists.x2go.org/listinfo/x2go-dev

[Oleksandr Shneyder]

Ok, installing WM just to make Xinerama work doesn't seem to be a right
solution for me. On the client site everything looks good. X2Go Client
creating correct xinerama.conf and sending correct options to x2goagent.
So I guess the problem is in NX-Xinerama code. I'll have a look and will
see how difficult is to fix it.

Regards
Alex

Post by Ulrich Sibiller
We can add that to the options string, so it can be switched depending
on the client's preference. No big deal...

Post by Walid MOGHRABI
To me, disabling MagicPixel (which is something barely useful) at

the server side is perfect.

Post by Walid MOGHRABI
Feel free to give me a use case where this should be kept, I don't

see any on my side.
The use case is a mixed environment, where people are working from
regular workstations (Windows, macOS, Linux) as well as TCE terminals.
Working on a regular workstation, the magic pixel is actually handy,
because you can use it to go back to your local desktop without leaving
fullscreen mode - remember that on Windows, Ctrl+Alt+F is broken (causes
a VcXsrv crash).
Kind Regards,
Stefan Baur
--
BAUR-ITCS UG (haftungsbeschrÀnkt)
GeschÀftsfÌhrer: Stefan Baur
EichenÀckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax [phone] | USt-IdNr.: DE268653243
_______________________________________________
x2go-dev mailing list
https://lists.x2go.org/listinfo/x2go-dev
_______________________________________________
x2go-dev mailing list
https://lists.x2go.org/listinfo/x2go-dev

--
-----------------------------------------------------------
Oleksandr Shneyder | Email: ***@phoca-gmbh.de
phoca GmbH | Tel. : 0911 - 14870374 0
Harzstr. 4 | Fax. : 0911 - 14870374 9
D-90491 NÃŒrnberg | Mobil: 0163 - 49 64 461

GeschÀftsfÌhrung:
Dipl.-Inf. Oleksandr Shneyder

Amtsgericht MÃŒnchen | http://www.phoca-gmbh.de
HRB 196 658 | http://www.x2go.org
USt-IdNr.: DE281977973
-----------------------------------------------------------

[Stefan Baur]

Post by Oleksandr Shneyder
Ok, installing WM just to make Xinerama work doesn't seem to be a right
solution for me. On the client site everything looks good. X2Go Client
creating correct xinerama.conf and sending correct options to x2goagent.
So I guess the problem is in NX-Xinerama code. I'll have a look and will
see how difficult is to fix it.

Alex,

having a WM (openbox) in TCE is useful for a lot more than just
XINERAMA. Think Popups for SSH-Private-Key passwords and for "wrong
password, try again" or "no route to host", etc. They all come up god
knows where and worst case, when I first ran into the issue, it was
impossible to focus on the password field, so all I could do was reboot
the client and try again - it wouldn't let me enter the password. Life
is so much easier when they have a window decoration and can get a focus ...

Kind Regards,
Stefan Baur

[Ulrich Sibiller]

On Wed, May 16, 2018 at 4:35 PM, Ulrich Sibiller

Post by Ulrich Sibiller
We can add that to the options string, so it can be switched depending on
the client's preference. No big deal...

Turns out that feature is already present in nxagent. You can use
-nomagicpixel on nxagent's command line and you can toggle the magic
pixel by using magicpixel=0/1 in the options string. So all that's
missing is support in x2go.

Uli

[Mihai Moldovan]

Does that mean it would also work with older NX-Lib versions, like 3.5.0.33?

No. That's a new feature that has been introduced in the 3.5.99.x line only.



Mihai

[Ulrich Sibiller]

On Wed, May 16, 2018 at 2:50 PM, Oleksandr Shneyder

Hi guys,
I have a strange issue. The Xinerama works well in full screen mode,
when x2goclient is started on desktop, but doesn't work if x2goclient
4.1.2.0-0x2go1~git20180514.1774+9.heuler.1
and same version of Debian - stretch. Session config identical as well.
Screen 0: minimum 320 x 240, current 4480 x 1080, maximum 4480 x 1200
NX1 connected 1920x1080+2560+0 0mm x 0mm
nx_1920x1080 60.00*
NX2 connected 2560x1080+0+0 0mm x 0mm

So your client side has 2 displayss

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

This indicates you are only having one screen. Is this true in that setup?

Also, I just remembered there's some xrandr magic going on in TCE mode
that _might_ mess things up for you. Have a look at
lib/live/config/2800-x2go-thinclientconfig.

Although if session is started from TCE, I'm getting error dialog from
"unsupported number of arguments (3); falling back to default"

Sorry, no idea. (the arguments are the ones for Xsession, if I get
that right. Which only supports 0 or 1 argument)

Uli

[Stefan Baur]

Post by Ulrich Sibiller
Also, I just remembered there's some xrandr magic going on in TCE mode
that _might_ mess things up for you. Have a look at
lib/live/config/2800-x2go-thinclientconfig.

I think you mean 2900. (We increased that count by 100 a while ago.)

And the xrandr code in there is actually based on
<https://code.x2go.org/gitweb?p=x2gothinclient.git;a=blob_plain;f=displaymanager/sbin/x2gothinclientd;h=6897d42d17bd6778e7de5e62ec3f51727d4e8800;hb=HEAD>

Both the perl original and the bash clone have a nice explanation of
what that code is doing - aligning displays in the order specified, and
making sure clone mode is active if all you have is a touchscreen (on
one surface) and no additional pointing device like a mouse (because in
that case, you would either be unable to reach the areas on the
non-touch-enabled screen with your pointing device, or the
touch-sensitive area would be totally out of sync with what's displayed
on it).

Kind Regards,
Stefan Baur

[Ulrich Sibiller]

On Thu, May 17, 2018 at 2:45 PM, Oleksandr Shneyder

On Thu, May 17, 2018 at 2:13 PM, Oleksandr Shneyder

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
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
else.

No, if I'm starting the session from TC without WM, I don't have screen
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.

Uli

[Walid MOGHRABI]

I am getting more an more confused about the TCE stuff. Is there a
difference between TCE you are talking about and the x2gothinclient
Alex is working on?

Let me clarify then :

TCE is just a micro Linux starting X2Goclient with the --thinclient option in fullscreen (mostly).

There are some other implementations such as "mini desktop" which, to me, is not a "real" Thin Client since you just start a smaller Linux distro with a few local apps (such as web browser) and the X2Go client installed as a local app but I'm not talking about this since this is just x2goclient in local desktop mode.

By default, the x2gothinclient-displaymanager package built by Alex don't have any WM dependencies and thus, if you do a very lightweight TCE setup (aka debootstrap Debian/Ubuntu and install x2gothinclient-displaymanager package), it will only install minimal dependencies such as Xorg libs, x2goclient and a buch of scripts to start it at boot time but no WM.
Since there is no WM, xinerama is not working properly and everything is OK with this setup unless you have a dual head (or more) display and in this case, your multiple monitors are used but x2goagent only see ONE huge display that stretches over your screens and not a proper multihead display with multiple monitors the way you have when using a local desktop.

Simply spawning a minimalistic WM such as OpenBox before starting X2Goclient fixes this issue.

Regards,
Walid Moghrabi

TRAVAUX.COM
BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403
13591 AIX EN PROVENCE CEDEX 3

----- Mail original -----

De: "Ulrich Sibiller" <***@gmail.com>
À: "Stefan Baur" <X2Go-ML-***@baur-itcs.de>
Cc: "Walid MOGHRABI" <***@servicemagic.eu>, x2go-***@lists.x2go.org
Envoyé: Vendredi 18 Mai 2018 09:57:31
Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE

Walid,
the proper way to handle this is to set the "MP disable" command *in
X2GoClient*, but *only when* X2GoClient is called with *--thinclient*,
because that is the option used to tell X2GoClient it is in TCE mode.
And the workaround with the un-minimizing daemon you are talking about
is the deprecated one anyways.

I am getting more an more confused about the TCE stuff. Is there a
difference between TCE you are talking about and the x2gothinclient
Alex is working on?

Uli
---
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. Thank you

[Stefan Baur]

Walid,

the proper way to handle this is to set the "MP disable" command *in
X2GoClient*, but *only when* X2GoClient is called with *--thinclient*,
because that is the option used to tell X2GoClient it is in TCE mode.

And the workaround with the un-minimizing daemon you are talking about
is the deprecated one anyways.
The better workaround, and the one we are deploying until this gets
fixed in X2GoClient, is the one where OpenBox is getting killed once the
NX window comes up, and restarted when it vanishes.
That way, MP is DEAD even in TCE. No "zap and unminimize", it just
doesn't have anything to send the minimize command to.
The only thing I'm considering changing is the time until OpenBox gets
killed when the NX window is detected - if the patch to X2GoClient takes
longer, adding a longer delay here might help getting Xinerama to work
properly.

Kind Regards,
Stefan Baur

I definitely don't agree ... you're too developer centric ...
This MagicPixel thing *IN TCE MODE* is troubling for users and your workaround is NOT a good option because the desktop is minimized then, thanks to a little daemon running, maximized again which is extremely confusing and frustrating for users.
In TCE mode, there is no need for such thing and there MUST be a way to disabling it completely.
This is what has been done by a server side switch which is fine for most *TCE* cases, now, I can understand that it can be desirable to keep that stuff for some other use cases but then, don't do tricks like that, just keep it and inform your users OR add the ability to disable this behaviour client side if disabling it server side really bothers you.
Regards,
Walid Moghrabi
TRAVAUX.COM
BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403
13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
Envoyé: Vendredi 18 Mai 2018 00:49:29
Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE

[...]
The problem arises on systems that have a Window Manager (like OpenBox),
but no task bar, so no way to un-minimize the X2Go/NX-window once the
user hits the magic pixel.
Are you sure that task bar is required? AFAIK any tool with window
switching ability (e.g. bbkeys, xdotool, some custom quick-and-dirty
libwnck script) would work, wouldn't it?

Well, we are using xdotool in one of our workarounds. But, in a
ThinClient environment, such a workaround must either function
automatically (detect minimize and un-minimize instantly), or give the
user some visual indication that X2GoClient hasn't crashed, but just
needs to be un-minimized. The way to do this, because even an only
marginally trained user would still understand this, is showing a task
bar with an X2Go icon.
Otherwise, all the user sees is a completely blue screen once they hit
the magic pixel. An advanced user might try key combinations like
Alt+Tab, but I wouldn't be sure that they help restoring the window to
fullscreen.
Oh, and as stated above, we tried xdotool for a workaround, but sadly,
it's not as simple as it seems and can trigger some nasty side-effects.
That's why we went for the other workaround - disabling OpenBox as soon
as the NX window spawns, then restarting it afterwards, once it has been
closed.
Kind Regards,
Stefan Baur

[Oleksandr Shneyder]

I don't know why you should have troubles with it. The installation
procedure is described in the Wiki step by step. You can use TCE with
very simple hardware which is not powerful enough to run TCE-Live. And
you can make changes in NFS-Root even without restarting thin clients. I
don't want to start battle "NFS vs Live" here. Everyone should decide it
for himself. For me TCE-Live is not a substitution for NFS-TCE. And it's
basically not a Thin Client System by definition. It's more a live image
system, IMHO.

regards
Alex

NFS-based TCE has a lot of advantages and will be kept anyway.

... as long as someone is actively maintaining it. If you have
customers paying for it, or you volunteer to maintain it, fine.
But I'm not happy with keeping a TCE-NFS in git that works on, say,
Debian 9 only, when Debian 10 or 11 becomes/is the stable release.
I'm curious to learn about the "lot of advantages" of TCE-NFS. Go ahead
and list them, please, so we can put them in the Wiki and create a
side-by-side comparison between TCE-NFS and TCE-Live as a guide for
potential users, so they know which version is right for them.
My personal experience with TCE-NFS was horrifying, that's why I started
TCE-Live. But maybe it is just a serious lack of documentation of
TCE-NFS that made Debian-Live feel way easier to me ...
Kind Regards,
Stefan Baur
_______________________________________________
x2go-dev mailing list
https://lists.x2go.org/listinfo/x2go-dev

--
-----------------------------------------------------------
Oleksandr Shneyder | Email: ***@phoca-gmbh.de
phoca GmbH | Tel. : 0911 - 14870374 0
Harzstr. 4 | Fax. : 0911 - 14870374 9
D-90491 NÃŒrnberg | Mobil: 0163 - 49 64 461

GeschÀftsfÌhrung:
Dipl.-Inf. Oleksandr Shneyder

Amtsgericht MÃŒnchen | http://www.phoca-gmbh.de
HRB 196 658 | http://www.x2go.org
USt-IdNr.: DE281977973
-----------------------------------------------------------

[Oleksandr Shneyder]

Well, 256MB RAM it's what they used in city of Treuchtlingen. Loading
images from local drive it's not an option, if you have about 200
clients which are located kilometers away from each other. NFS-TCE is
nothing else than simple debootstrap loaded from NFS with some scripts
to launch X2Go Client. Should be no problem to anyone who has a minimal
knowledges about NFS-Root, DHCP and TFTP. It took me just a several
minute to migrate it from Wheezy to Stretch. Didn't work out of the box
because some files were moved in Debian from one package to another.

regards
Alex

Post by Stefan Baur
Hi Alex,
I don't want to start a battle either, but I think a side-by-side
comparison would be nice so users know what to expect and thus what they
should pick for their intended use.
Back when I tried to follow the installation instructions, they were for
Wheezy only. Attempting to run the same installation steps for Jessie
failed (Stretch wasn't released back then), and there were no obvious
error messages pointing me toward what I should fix/change.
Which, to me, is an indication that TCE-NFS has lots of "hackish" parts
that need to be altered with every new major Debian release to make them
work again.
I would also like to know what your minimum hardware requirements for
TCE-NFS are.
Even though TCE-Live has the option to run from a RAM disk, it is by no
means mandatory. I just booted an i386 stretch build of TCE-Live
(without the "toram" parameter) from USB and it shows approximately 69
MB of RAM used in idle, and 76 MB RAM used with a fullscreen session and
pulseaudio running. I have to admit that this doesn't seem to be the
whole truth, though - actually reducing the RAM on the machine to 128MB
caused a kernel crash right while booting. With 256MB of RAM, it boots
up, and runs a session - though it's obviously slow because it can use
almost no RAM as buffer/cache. But I doubt that would be different with
TCE-NFS ...
Kind Regards,
Stefan Baur

Post by Oleksandr Shneyder
I don't know why you should have troubles with it. The installation
procedure is described in the Wiki step by step. You can use TCE with
very simple hardware which is not powerful enough to run TCE-Live. And
you can make changes in NFS-Root even without restarting thin clients. I
don't want to start battle "NFS vs Live" here. Everyone should decide it
for himself. For me TCE-Live is not a substitution for NFS-TCE. And it's
basically not a Thin Client System by definition. It's more a live image
system, IMHO.
regards
Alex

NFS-based TCE has a lot of advantages and will be kept anyway.

... as long as someone is actively maintaining it. If you have
customers paying for it, or you volunteer to maintain it, fine.
But I'm not happy with keeping a TCE-NFS in git that works on, say,
Debian 9 only, when Debian 10 or 11 becomes/is the stable release.
I'm curious to learn about the "lot of advantages" of TCE-NFS. Go ahead
and list them, please, so we can put them in the Wiki and create a
side-by-side comparison between TCE-NFS and TCE-Live as a guide for
potential users, so they know which version is right for them.
My personal experience with TCE-NFS was horrifying, that's why I started
TCE-Live. But maybe it is just a serious lack of documentation of
TCE-NFS that made Debian-Live feel way easier to me ...
Kind Regards,
Stefan Baur
_______________________________________________
x2go-dev mailing list
https://lists.x2go.org/listinfo/x2go-dev

_______________________________________________
x2go-dev mailing list
https://lists.x2go.org/listinfo/x2go-dev

_______________________________________________
x2go-dev mailing list
https://lists.x2go.org/listinfo/x2go-dev

--
-----------------------------------------------------------
Oleksandr Shneyder | Email: ***@phoca-gmbh.de
phoca GmbH | Tel. : 0911 - 14870374 0
Harzstr. 4 | Fax. : 0911 - 14870374 9
D-90491 NÃŒrnberg | Mobil: 0163 - 49 64 461

GeschÀftsfÌhrung:
Dipl.-Inf. Oleksandr Shneyder

Amtsgericht MÃŒnchen | http://www.phoca-gmbh.de
HRB 196 658 | http://www.x2go.org
USt-IdNr.: DE281977973
-----------------------------------------------------------

[Stefan Baur]

Post by Oleksandr Shneyder
Well, 256MB RAM it's what they used in city of Treuchtlingen. Loading
images from local drive it's not an option, if you have about 200
clients which are located kilometers away from each other.

It is an option, if local storage is present. We have a background
updater exactly for that.
Also, TCE-Live *should* work via netboot as well, even on 256MB RAM
machines, though admittedly I haven't tested it myself. In those
situations, you need to use httpfs instead of the "fetch" boot
parameter, that way, even in netboot mode, the image isn't loaded into
RAM (at least that's the theory behind it).

Kind Regards,
Stefan Baur

[Ulrich Sibiller]

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).

And that's why we added OpenBox to TCE-live in the first place.
(TL;DR: +1)

Nevertheless I have opened an issue on nx-libs
(https://github.com/ArcticaProject/nx-libs/pull/694) and I have a
possible solution
(https://github.com/ArcticaProject/nx-libs/pull/695).

Also I suppose we should automatically disable the magic pixel when
there's no window manager running. What do you think?

Uli

[Ulrich Sibiller]

Post by Ulrich Sibiller
Also I suppose we should automatically disable the magic pixel when
there's no window manager running. What do you think?

Wait, no. Let's not get confused here.
Magic Pixel *is* effectively disabled when there is no Window Manager
running, because the command "minimize" is sent to a WM. If there is
none, nothing happens. That is fine how it is. No further action needed.
The problem arises on systems that have a Window Manager (like OpenBox),
but no task bar, so no way to un-minimize the X2Go/NX-window once the
user hits the magic pixel. And we need a way to disable the magic pixel
there, because we need OpenBox for several reasons and can't just ditch
it to fool NX. So instead of detecting the presence of a Window
Manager, we'd need to detect the presence of a task bar. Which, I'd
guess, isn't as easy.

Taskbar detection would be plainly wrong. It is completely up the
window manager how iconification (and that is what we really talking
about, IMHO) is handled. So it totally depends on the window manager
what you see and what you can (or can't) do.

Uli

[Nable]

[...]
The problem arises on systems that have a Window Manager (like OpenBox),
but no task bar, so no way to un-minimize the X2Go/NX-window once the
user hits the magic pixel.

Are you sure that task bar is required? AFAIK any tool with window
switching ability (e.g. bbkeys, xdotool, some custom quick-and-dirty
libwnck script) would work, wouldn't it?

[Stefan Baur]

This post might be inappropriate. Click to display it.

[Stefan Baur]

Post by Ulrich Sibiller
Also I suppose we should automatically disable the magic pixel when
there's no window manager running. What do you think?

I'd say your thinking is a bit too Linux-centric here.
Or would your code also detect a running MS Windows / macOS underneath
X2GoClient as "has WM"?

Unfortunately I do not remember, although I have beee examining that
recently (while debugging the flickering issue on Windows). No, wait,
vcxsrv brings its own window manager for the multiwindow mode and then
nx is reporting "has WM". No idea about MacOs, though.

*pinging Mihai and Mike#2 here, because of the macOS question ...*

[Stefan Baur]

Because the magic pixel is useful on those platforms, too - especially
Windows, where pressing Ctrl+Alt+F regularly crashes the X server,
instead of toggling fullscreen mode.

We could file vcxsrv bug for that. We "just" need to track it down and
build some small example code. ;-)

Given how long that bug has bothered us, I don't expect it to get fixed
any time soon ...

Kind Regards,
Stefan Baur

[Walid MOGHRABI]

Well, don't ask me ... to me, TCE is TCE and I don't mix X2Go servers dedicated to TCE with X2Go servers dedicated to other usages so, if it was only for me, I would remove MagicPixel completely and eventually replace it by some x2go script that can be triggered manually (by some cli command or desktop app or even keyboard shortcut).


Regards,
Walid Moghrabi

TRAVAUX.COM
BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403
13591 AIX EN PROVENCE CEDEX 3

----- Mail original -----

De: "Ulrich Sibiller" <***@gmail.com>
À: "Stefan Baur" <X2Go-ML-***@baur-itcs.de>
Cc: x2go-***@lists.x2go.org
Envoyé: Jeudi 17 Mai 2018 23:21:47
Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE

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).

And that's why we added OpenBox to TCE-live in the first place.
(TL;DR: +1)

Nevertheless I have opened an issue on nx-libs
(https://github.com/ArcticaProject/nx-libs/pull/694) and I have a
possible solution
(https://github.com/ArcticaProject/nx-libs/pull/695).

Also I suppose we should automatically disable the magic pixel when
there's no window manager running. What do you think?

Uli
_______________________________________________
x2go-dev mailing list
x2go-***@lists.x2go.org
https://lists.x2go.org/listinfo/x2go-dev
---
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. Thank you

[Stefan Baur]

I am suspecting this has to do with the fact that openbox is the first
client to TCEs X server. Can someone try and run an
xterm/xclock/xlogo/whatever (and no WM) prior to x2goclient?

What would you expect to happen when another application is the first
client? (Just so testers know what to look for ...)

Kind Regards,
Stefan Baur

[Walid MOGHRABI]

Don't see much advantages either except the fact that it lets you easily change some settings live without a reboot needed to start a new image.

But to be honest, as far as I'm concerned, I see more drawbacks in TCE-NFS than in TCE-Live.

Regards,
Walid Moghrabi

TRAVAUX.COM
BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403
13591 AIX EN PROVENCE CEDEX 3

----- Mail original -----

De: "Stefan Baur" <X2Go-ML-***@baur-itcs.de>
À: x2go-***@lists.x2go.org
Envoyé: Vendredi 18 Mai 2018 10:43:16
Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE

NFS-based TCE has a lot of advantages and will be kept anyway.

... as long as someone is actively maintaining it. If you have
customers paying for it, or you volunteer to maintain it, fine.

But I'm not happy with keeping a TCE-NFS in git that works on, say,
Debian 9 only, when Debian 10 or 11 becomes/is the stable release.

I'm curious to learn about the "lot of advantages" of TCE-NFS. Go ahead
and list them, please, so we can put them in the Wiki and create a
side-by-side comparison between TCE-NFS and TCE-Live as a guide for
potential users, so they know which version is right for them.

My personal experience with TCE-NFS was horrifying, that's why I started
TCE-Live. But maybe it is just a serious lack of documentation of
TCE-NFS that made Debian-Live feel way easier to me ...

Kind Regards,
Stefan Baur
--
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax [phone] | USt-IdNr.: DE268653243


_______________________________________________
x2go-dev mailing list
x2go-***@lists.x2go.org
https://lists.x2go.org/listinfo/x2go-dev
---
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. Thank you

[Mike Gabriel]

Hi all,

This is a known bug I encountered and this is due to the lack of
Window Manager.
Apparently, the WM is needed to have a good working xinerama.

since today, this is not true anymore. The nxagent now also supports
Xinerama without a running WM.

The merge of this PR fixed the issue.
https://github.com/ArcticaProject/nx-libs/pull/695

Thus, you might want to ponder de-complicating the TCE code in that
respect. However, a WM does not hurt. The workaround is just not
needed anymore.

Greets,
Mike

[Stefan Baur]

Post by Mike Gabriel
Thus, you might want to ponder de-complicating the TCE code in that
respect. However, a WM does not hurt. The workaround is just not needed
anymore.

The WM is not needed for Xinerama any more - but still for window
decoration and focus, unless you want to degrade user experience in case
of popups (yes, in a perfect world, we wouldn't have popups, but
sometimes, there's no route to host, there's a wrong password, there's a
private key file that needs to have its passphrase entered, ...).

-Stefan

[Walid MOGHRABI]

I agree, adding a minimalistic WM in the TCE setup is not cosmetic, anyway, this is nice that this bug is now fixed :)


Regards,
Walid Moghrabi

TRAVAUX.COM
BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403
13591 AIX EN PROVENCE CEDEX 3

----- Mail original -----

De: "Stefan Baur" <X2Go-ML-***@baur-itcs.de>
À: x2go-***@lists.x2go.org
Envoyé: Jeudi 24 Mai 2018 11:52:04
Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE

Post by Mike Gabriel
Thus, you might want to ponder de-complicating the TCE code in that
respect. However, a WM does not hurt. The workaround is just not needed
anymore.

The WM is not needed for Xinerama any more - but still for window
decoration and focus, unless you want to degrade user experience in case
of popups (yes, in a perfect world, we wouldn't have popups, but
sometimes, there's no route to host, there's a wrong password, there's a
private key file that needs to have its passphrase entered, ...).

-Stefan
--
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax [phone] | USt-IdNr.: DE268653243


_______________________________________________
x2go-dev mailing list
x2go-***@lists.x2go.org
https://lists.x2go.org/listinfo/x2go-dev
---
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. Thank you