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