Fix for #3666

[mmattes]

According to https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472531472

_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen and have no window decorations. Additionally the Window Manager is responsible for restoring the original geometry after a switch from fullscreen back to normal window.

I think that the cinnamon desktop handles this and that the additional move to position 0, 0 causes issues here. Not moving the window after the event is send fixes this issue in cinnamon. I additionally tested the change in XFCE and Mate and it seems to work without any problems.

[freerdp-bot]

Can one of the admins verify this patch?

[akallabeth]

@freerdp-bot test

[freerdp-bot]

Refer to this link for build results (access rights to CI server needed):
https://ci.freerdp.com//job/PullRequestTester/2990/

[akallabeth]

Sorry, broken on all accounts (cinnamon fedora 28)
The window is not restored to its previous position after applying your patch.
On multimonitor setups it even restores on the wrong monitor.

[mmattes]

The window is not restored to its previous position after applying your patch.
On multimonitor setups it even restores on the wrong monitor.

Hm... on the website i referenced it says that the window manager is responsible for restoring the window to its previous state. So isnt your discovery then a bug within cinnamon which FreeRDP should not aim to fix?

The only other solution I could think of is to add some sleep time before moving the window, i can give that a try this afternoon.

[akallabeth]

@mmattes It might indeed be a bug in window managers (or disagreement, pick your poison ;)), sadly they all misbehave (the ones I tried at least). This way the behaviour is at least somewhat the one expected.

Anyway, the referenced issue with the transparent/frozen window seems to be of a different nature, as the window may be moved by code at any time without the wm to do block something, so this fix is just hiding what is causing the issue anyway.

Have you checked we are not in some kind of recursive loop through X11 event generation in an X11 event handler? That might be the actual cause of the issue and be fixable without manipulating fullscreen switch behaviour.

[mmattes]

I haven't had a look for an recursive event loop yet, will have a look later. What I can say so far is that it would work if the window is moved to x = 1 and y = 0. Rather then x = 0 and y = 0.

[akallabeth]

@mmattes Ah, ok. Might simply be an issue if we don't actually move the window then?

[mmattes]

@akallabeth this is, after a lot of trying and reading the only solution i could come up with. It keeps the old behavior and fixes the issue with Cinnamon WM.

Please note that toggling full-screen back and forth many times will slowly move the window down as XMoveWindow moves the position of the window including decorator (green mark blow) but the ConfigureNotify event gives the top/left position of the window without decorator (red mark below). I haven't found anything which tells me how large the decorator is so i left this behavior as it is.

[akallabeth]

@mmattes played a bit and found (again) issues with the fullscreen stuff.
Could you try https://github.com/akallabeth/FreeRDP/tree/fullscreen_cinnamon and report if it works for you?
Should fullscreen and restore on the correct monitor now (using cinnamon here on fedora 28)

[mmattes]

@akallabeth
xfreerdp /u:username /f /v:hostname works
xfreerdp /u:username /smart-sizing /v:hostname works
xfreerdp /u:username /dynamic-resolution /v:hostname works
xfreerdp /u:username /v:hostname does not work, decorators are just removed and that is it, window stays at original place and keeps size. May nothing should happen at all here?

[mmattes]

@akallabeth anything i can do to get this pushed forward to get a solution?

[akallabeth]

@mmattes trial and error so far, have not found something that works better in all cases

[dannymcc]

@mmattes Hi, did you ever have any luck with this? We are using FreeRDP to access software from VetZ and seem to be struggling with windows resizing crashing the session. Did you ever make any further progress?

[Neustradamus]

Have you progressed on it?

[akallabeth]

is this issue still relevant?
Is this still an issue with HIGH DEF rails support?

[mmattes]

@akallabeth i will test it and will let you know. Could you pleased give ne some insight what HIGH DEF rails Support means?