-
Notifications
You must be signed in to change notification settings - Fork 14.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for #3666 #4763
base: master
Are you sure you want to change the base?
Fix for #3666 #4763
Conversation
Can one of the admins verify this patch? |
@freerdp-bot test |
Refer to this link for build results (access rights to CI server needed): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
@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. |
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. |
@mmattes Ah, ok. Might simply be an issue if we don't actually move the window then? |
@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. |
@mmattes played a bit and found (again) issues with the fullscreen stuff. |
@akallabeth |
@akallabeth anything i can do to get this pushed forward to get a solution? |
@mmattes trial and error so far, have not found something that works better in all cases |
@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? |
Have you progressed on it? |
is this issue still relevant? |
@akallabeth i will test it and will let you know. Could you pleased give ne some insight what HIGH DEF rails Support means? |
According to https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472531472
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.