Hi, I'll look on it on Thursday-Monday,

regards, Alex

Am 23.06.2015 um 12:51 schrieb Mike Gabriel:

Hi Michael, hi Alex,

On Mo 22 Jun 2015 09:18:28 CEST, Michael DePaulo wrote:

...

I determined that this bug can be fixed by reverting Alex's winmultiwindow.patch to VcXsrv, which was a workaround for #594 and has been included in both 1.15.2.x and 1.17.0.0-x of the VcXsrv X2Go/Arctica builds.

I also created a bug report & branch in the GitHub project for VcXsrv (X2Go/Arctica builds): https://github.com/ArcticaProject/vcxsrv/issues/3 https://github.com/ArcticaProject/vcxsrv/commits/bugfix/bug3

I will be releasing X2Go Client for Windows 4.0.4.0-2015.06.22 with the OpenSSL updates. When I do, I will offer an alternate build with VcXsrv with winmultiwindow.patch reverted. This will be a workaround until we make a change to VcXsrv that fixes both #594 and #883

@Alex: Before Michael starts diving into your patch for fixing #594, do you see any chance for taking a look at the regression described in #883 introduced by your patch? Any feedback on a possible solution would be highly welcome.

Thanks, Mike

--

Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Ludwig-Feuerbach-str. 18 | Fax. : 0911 - 14870374 9 D-90489 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

Hello,

I'll try to explain why I wrote this patch. In x2go client you have possibility to run x2go session in "full screen" mode on only one of physical displays. It has nothing to do with xinerama. It is very useful if you have a client with several monitors and you want to have the native session on one monitor and full screen remote session on second monitor. It's also not a full screen mode, because you are using only a part of virtual display, so you are not running a vcxsrv in full screen mode. This scenario widely used in enterprise environments.

To create a full screen window on only one physical display you need to maximize the window on this display and remove the window decorations. Unfortunately on some setups it was not possible to maximize an X-window. As soon as you tried it, vcsrv resized a window with a size that was bigger then physical display and reseted a window decorations. After some investigation I figured out that it's only happening on the displays with negative coordinates, for example if a secondary display is left of or on the top of primary display. So I assumed that vcxsrv doesn't work properly with negative coordinates. Unfortunately I didn't manage to find a bug in vcxsrv, so I wrote a workaround that checking if the windows size is bigger than a physical display and in this case resizing a window on a screen size. Usually it is no ways to create a windows that are bigger then a physical display, so that workaround worked well. Unfortunately in the case described in this bug report, nxagent creating window that is bigger then screen size, because screen was resized. This is why a firefox or whatever window will be maximized and window decorations will be erased by a workaround.

I don't think that we can remove this workaround, because it will brake many productive x2go setups. At least as long as we won't find a bug handling negative screen sizes in vcxsrv and now I have not sufficient resources to do it.

I suggest to check in workaround if screen has negative coordinates and omit any window that placed on the displays with positive coordinates.

Also in x2go client I'll check a window size and decoration flags and reset it in the case if x2go session is not a multi window session. This fill fix #883 and won't brake a multi monitor setups. I'll do it today or tomorrow.

regards, Alex

Am 24.06.2015 um 04:04 schrieb Mihai Moldovan:

On 23.06.2015 09:22 PM, Oleksandr Shneyder wrote:

...

I'll look on it on Thursday-Monday,

I've had a look myself and played around with it, assisted by Mike#2.

I don't see any benefit in applying this patch and suggest dropping it.

As far as I've gathered, it's supposed to create a "fake" fullscreen window by removing the borders and title bar IFF the window extents are greater or equal the monitor's size, with "monitor" being the monitor that holds most of the window's contents.

It doesn't make sense to do something like this in multiwindow mode. It *does* make sense to do something like this in fullscreen mode, but the patch targets multiwindow mode.

For this mode, it's plain wrong and only causing trouble. You can't fix it either, because you're missing a crucial bit of information: when *do* you want to have a "fake" fullscreen window?

Why did you write the original patch exactly? What was the use case that this patch fixed?

Mihai

--

Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Ludwig-Feuerbach-str. 18 | Fax. : 0911 - 14870374 9 D-90489 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

No, run the desktop session (kde, gnome, whatever) and in display configuration choose "use whole display" and chose a secondary display.

PS: Maybe to reproduce this bug secondary display should be smaller or bigger then a primary, I don't remember.

Am 29.06.2015 um 11:44 schrieb Stefan Baur:

Am 29.06.2015 um 11:36 schrieb Oleksandr Shneyder:

...

After some investigation I figured out that it's only happening on the displays with negative coordinates, for example if a secondary display is left of or on the top of primary display.

I tried just that - secondary display to the left of the primary display - with your patch reverted, and saw no such issue on Windows 7. So I'm wondering where you saw it? Windows XP maybe?

Or *only* in fullscreen mode, maybe? Because published applications work just fine on either screen, maximized or not, as soon as your patch is reverted.

-Stefan

---

x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev

--

Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Ludwig-Feuerbach-str. 18 | Fax. : 0911 - 14870374 9 D-90489 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

Actually, it's very easy to reproduce:

Secondary display is left of primary display and have bigger resolution, which is usual setup if you connecting monitor to notebook. Configure multiwin session to run on big secondary display and you'll have a x2go session not running in full screen mode es expected (See attach #1). If you using x2go client with multiwin patch you will have a session running in full screen on second monitor like in attach #2.

Regards Alex

Am 29.06.2015 um 12:22 schrieb Stefan Baur:

Am 29.06.2015 um 11:52 schrieb Oleksandr Shneyder:

...

No, run the desktop session (kde, gnome, whatever) and in display configuration choose "use whole display" and chose a secondary display.

...

PS: Maybe to reproduce this bug secondary display should be smaller or bigger then a primary, I don't remember.

so,

tag: -1 hard-to-reproduce tag: -1 smells-funny

?

;-)

-Stefan

---

x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev

--

Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Ludwig-Feuerbach-str. 18 | Fax. : 0911 - 14870374 9 D-90489 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

On 29.06.2015 11:36 AM, Oleksandr Shneyder wrote:

I'll try to explain why I wrote this patch. In x2go client you have possibility to run x2go session in "full screen" mode on only one of physical displays. It has nothing to do with xinerama. It is very useful if you have a client with several monitors and you want to have the native session on one monitor and full screen remote session on second monitor. It's also not a full screen mode, because you are using only a part of virtual display, so you are not running a vcxsrv in full screen mode. This scenario widely used in enterprise environments.

Yeah, it's a valid use case. Thanks for explaining it. I want to add that this is the reason for this "Use whole display" property in the session settings.

I don't think that we can remove this workaround, because it will brake many productive x2go setups. At least as long as we won't find a bug handling negative screen sizes in vcxsrv and now I have not sufficient resources to do it.

This patch will either have to be fixed, an alternative solution be found or it will be removed from our VcXsrv builds and you will have to maintain it separately for your customers.

I don't mean to be rude, but this patch causes *two* higher severity bugs Windows users are often hit by:

• disappearing, maximized window after session resume if the resolution decreased to something less than window size
• disappearing, maximized window after MAXIMIZING a window on a non-primary display(!!!)

I regularly get reports of both things happening, even over IRC.

In both cases, users are left without window decorations and thus cannot resize, move or otherwise manipulate windows. The only "solution" is to terminate the session completely. This is very disrupting.

In contrast, the initial problem your patch tried to fix is merely an annoyance. It may not look nice to have window decorations for a "full screen desktop session" and it's annoying to have to resize the window back into shape after maximizing it, but at least you don't lose the ability to manipulate windows.

Ideally, we have to make sure that all three scenarios work fine without any bugs.

Mike#2 presented a very promising approach as an alternative:

On 29.06.2015 03:16 PM, Michael DePaulo wrote:

It sounds like the best approach to making a "full screen" secondary monitor work is to launch VcXsrv (or Cygwin XWin) with these arguments: -nodecoration -screen 0 @2

For tertiary monitor, use @3 instead.

This launches Cygwin XWin in root window mode (the default) rather than -multiwindow mode. -nodecoration hides the window decoration from the Windows OS.

The only thing that needs testing with that suggestion is to check whether windows are automatically resized to the display's extents.

Also, we probably should not use this on the primary display. That's what VcXsrv's fullscreen mode is for.

If the alternative suggested by Mike#2 does not work as intended, we'll have to fix the patch.

I have one approach for doing that in mind:

• add a new VcXsrv command line option
• only enable this command line option if the user selected a full screen session on a non-primary display
• restart VcXsrv if such a session is to be started
• in your multiwindow patch: only execute the workaround if the new command line option has been used when starting VcXsrv

I suggest to check in workaround if screen has negative coordinates and omit any window that placed on the displays with positive coordinates.

This won't work, because users can put windows on a vscreen with negative coordinates. If they do, they'll experience the same problems as before.

Also in x2go client I'll check a window size and decoration flags and reset it in the case if x2go session is not a multi window session.

Did you mean full screen desktop session? Because re-setting windows decorations only makes sense if the x2go session IS a multi window session or a non-fullscreen desktop session.

But even if you do that, won't VcXsrv delete the window decorations again as soon as you re-add the window decorations from X2Go Client? At the very least it will do that when the window is resized/maximized again.

Letting VcXsrv and X2Go Client fight over windows properties is not a good idea. I can see it blowing up easily.

Mihai

Hi Alex,

On Di 23 Jun 2015 21:22:41 CEST, Oleksandr Shneyder wrote:

Hi, I'll look on it on Thursday-Monday,

Thanks!

My suggestion would be to drop that patch and try-out the
-multimonitors and the -screen options of VcXsrv instead (as also
proposed by Ionic and mikedep333 on IRC):

""" -[no]multimonitors or -[no]multiplemonitors Use the entire virtual screen if multiple monitors are present.

[...]

-screen scr_num [width height [x y] | [[WxH[+X+Y]][@m]] ] Enable screen scr_num and optionally specify a width and height and initial position for that screen. Additionally a monitor number can be specified to start the server on, at which point, all coordinates become relative to that monitor. Examples: -screen 0 800x600+100+100@2 ; 2nd monitor offset 100,100 size 800x600 -screen 0 1024x768@3 ; 3rd monitor size 1024x768 -screen 0 @1 ; on 1st monitor using its full resolution (the default) """

Greets, Mike

DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...