Desktop flashing when maximizing window on second screen with Windows client #600
Assignees
Labels
Comments
|
I have a similar issue with screen Flickering and Ubuntu mate. If the mouse is moved over the top-left corner after the client window is resized (no clicking) the flickering continues for a few more seconds. Setup details are: Server I have uploaded a youtube video demonstrating the issue when the client window is maximized
As you can see from the log every time the client window is resized multiple resize operations are performed, without actually resize the client window. When the client window is maximized it continuously tries to resize the client window to the maximized resolution of 1858x1177. |
|
Tested also with Centos 6.9 with Gnome 2.28.2 and the flickering can be also triggered. I am appending the session log bellow. Setup details are: Server |
|
More testing is done trying to identify if the 1 pixel hack is responsible for the flickering Flickering also occurs when the the nx-nxagent is manually started Tested with: The flickering loop always occurs when the Window is maximized Tested also with Cyxwin-X version 1.18.4-1 and the flicker loop does not occur. |
|
I build the Ubuntu packages from the latest source from nx-libs.git and enabled DEBUG and TEST in Modified nx-X11/programs/Xserver/hw/nxagent/Screen.c by removing And the flicker occurs again, the nxagent_debug-mod.log.gz file contains the output from the modified nxagent From the vcxsrv.log noticed that after the (ConfigureWindow), error events follow |
|
@nkrepo: please find a version printing more debugging output in this branch: https://github.com/uli42/nx-libs/tree/tst_flicker Can you please compile this version and supply another debug log? |
|
@uli42 : I build and run the tst_flicker branch. I am attaching the log file bellow. |
|
Run nxagent with -sync option, attaching the new log, the same flicker loop happens when the window is maximized. |
|
I did a little more testing with different X-Servers |
|
I did some more tests asked by @uli42 . I also noticed that there no need to start the mate-session for the vcxsrv client window to start flickering. |
|
I did some tests, too. And I could see that the x position of the nxagent window is changing back and forth between 0 and 8 while the y position is flapping between 23 and 31 (again 8 pixels) between those many ConfigureNotify events the nxagent receives. Searching for "windows 10 8pixels" lead me to this insane Windows 10 behaviour: https://stackoverflow.com/questions/42473554/windows-10-screen-coordinates-are-offset-by-7 (money quote: "In my opinion, whoever did this at Microsoft should be immediately shot.") Digging in that direction now. Still, I don't have a good idea how to handle that. Update: setting the VcXsrv executable to "Windows 7" in the compatibility tab changes the values from 8 to 4, the rest stays the same. |
|
The other theory: Windows 10 changes the size of the window title bar when maximizing. The height is reduced and the program`s icon is moving a bit closer to the left edge. On my slow VM it looks like this done using multiple operations one after the other (move the icon to the left, reduce the height, move the window; I cannot define the order for sure). If every operation is causing an event this might be an explanation. |
|
What happens if you disable all visual effects in Windows???
Mike
…On Sunday, March 18, 2018, Ulrich Sibiller wrote:
The other theory: Windows 10 changes the size of the window title bar when maximizing. The height is reduced and the program`s icon is moving a bit closer to the left edge. On my slow VM it looks like this done using multiple operations one after the other (move the icon to the left, reduce the height, move the window; I cannot define the order for sure). If every operation is causing an event this might be an explanation.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
--
Sent from my Fairphone 2 (running Sailfish OS)
|
|
Unfortunately I haven't found where to do this yet. I have found some
instructions but they were not valid anymore. Looks like MS has dropped
that feature with one of the Win10 releases.
Mike Gabriel <[email protected]> schrieb am Mo., 19. März 2018,
07:01:
… What happens if you disable all visual effects in Windows???
Mike
On Sunday, March 18, 2018, Ulrich Sibiller wrote:
> The other theory: Windows 10 changes the size of the window title bar
when maximizing. The height is reduced and the program`s icon is moving a
bit closer to the left edge. On my slow VM it looks like this done using
multiple operations one after the other (move the icon to the left, reduce
the height, move the window; I cannot define the order for sure). If every
operation is causing an event this might be an explanation.
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
--
Sent from my Fairphone 2 (running Sailfish OS)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#600 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGBw5HbkcE1f_9sPx3Rp7T_THW-NghZOks5tf0nIgaJpZM4RA9Op>
.
|
|
@uli42 , yes of course, I will produce the new logs until tomorrow. I have to note that after every client window resize (not maximizing), an extraneous client window resize event occurs to same geometry every time. It may worth to start looking for that first. For example : |
|
@uli42 , run the |
|
@nkrepo: Thx. But unfortunately switching to "performance" here has no
impact on the flickering.
…On Mon, Mar 19, 2018 at 8:13 AM, nkrepo ***@***.***> wrote:
@uli42 , run the sysdm.cpl, you can find the visual setting in advance tab.
I tested running x2go both locally and while connected to another windows
machine via RDP with all effects disabled.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@nkrepo: I can not confirm getting two resize events! I get only one!
…On Mon, Mar 19, 2018 at 7:49 AM, nkrepo ***@***.***> wrote:
@uli42 , yes of course, I will produce the new logs until tomorrow.
@sunweaver , I did a test with "Desktop Composition" , "Menu and window
animation" and "Visual styles disabled", the flickering still occurs.
I have to note that after every client window resize (not maximizing), an
extraneous client window resize event occurs to same geometry every time. It
may worth to start looking for that first.
For example :
Info: Screen [0] resized to geometry [984x728] fullscreen [0].
Info: Screen [0] resized to geometry [984x728] fullscreen [0].
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Hi,
On Mo 19 Mär 2018 09:02:26 CET, Ulrich Sibiller wrote:
@nkrepo: Thx. But unfortunately switching to "performance" here has no
impact on the flickering.
Finally, I had a chance to try out X2Go under Windows yesterday at a
customer's. The flickering issue also occurs under Windows 7 and
doesn't seem to stop (we were not very patient, as in "minutes").
From recent posts, I get the feeling that you guys limit it to
occurring under Windows 10. That is not the case, so Windows-10-only
specialities (like the 8-pixel-off phenomenon) cannot be it.
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: [email protected], http://das-netzwerkteam.de
|
|
On Mo 19 Mär 2018 09:06:13 CET, Ulrich Sibiller wrote:
@nkrepo: can you rebuild a different nxagent branch and give feedback,
if that also has the flickering flaw?
The branch is this: bugfix/xinerama-crtcs on Ionic's nx-libs clone.
$ git remote origin add gh-Ionic https://github.com/Ionic/nx-libs
$ git fetch gh-Ionic
$ git checkout bugfix/xinerama-crtcs
For details, see:
#682
Please note, I myself haven't reviewed that branch, yet, but it would
be good to know if that also has the flickering "feature" when run
from an MS Windows system.
Thanks,
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: [email protected], http://das-netzwerkteam.de
|
|
Testing with this branch is not necessary. There are no differences from the main branch currently. It will behave exactly the same. |
|
I did more testing with the workaround patch provided by @uli42. There was no flickering loop. It seemed stable, I did notice any issues, unfortunately the testing was done remotely and was a bit slow and I might missed something. I am attaching the log file generated by nxagent with with I am attaching the log file generated by nxagent with with I tried to use vcxsrv's command line options To more get extensive logging at client side but it seems to ignore them. |
|
Thx! At least we have something to offer (although I still consider this a workaround only). Did you notice any difference between "return 0" and "return 1"? The return value should only really matter on systems with multiple monitors on windows and rrxinerama activated. Do you have two monitors available for testing? |
|
I have now tracked this issue down to a single line in =Screen.c:nxagentResizeScreen()=. The call of =XSetWMNormalHints()= is causing the flickering. We could leave it out if the =clientos= is Windows but there must be a better way... |
|
On Mi 21 Mär 2018 23:24:41 CET, Ulrich Sibiller wrote:
I have now tracked this issue down to a single line in
=Screen.c:nxagentResizeScreen()=. The call of =XSetWMNormalHints()=
is causing the flickering. We could leave it out if the =clientos=
is Windows but there must be a better way...
I presume, you mean the XSetWMNormalHints() call in nxagetResizeScreen().
The nxagent code has its own function for that:
nxagentSetWMNormalHints() (also in Screen.c). Maybe that one needs to
be called instead?
Mike
…--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: [email protected], http://das-netzwerkteam.de
|
|
On Thu, Mar 22, 2018 at 7:47 AM, Mike Gabriel <[email protected]>
wrote:
On Mi 21 Mär 2018 23:24:41 CET, Ulrich Sibiller wrote:
> I have now tracked this issue down to a single line in
> =Screen.c:nxagentResizeScreen()=. The call of =XSetWMNormalHints()=
> is causing the flickering. We could leave it out if the =clientos=
> is Windows but there must be a better way...
I presume, you mean the XSetWMNormalHints() call in nxagetResizeScreen().
Yes, as I wrote above ;-)
The nxagent code has its own function for that:
nxagentSetWMNormalHints() (also in Screen.c). Maybe that one needs to
be called instead?
I have seen this function. It is very similar, but not the same (there's
room for improvement anyway). I have also tried calling
nxagentSetWMNormalHints() but it did not change anything.
The "interesting" thing here is that the specific values passed to
XSetWMNormalHints() do not seem to be causing this but merely the call
itself.
Uli
…
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: ***@***.***, http://das-netzwerkteam.de
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#600 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGBw5LP6_4gPjosz_VnXhV70RehQxfY6ks5tg0jvgaJpZM4RA9Op>
.
|
|
I have been playing around the whole evening on this... One thing I learned:
This will move the nxagent window on the Windows desktop to the left border. But only until you enter the window with the mouse. The window will then immediately be moved from 0,31 -> 8,31 which will trigger another ConfigureNotifyEvent. This behaviour vanishes when removing the XSetWMNormalHints() call from nxagentResizeScreen, as mentioned above. I have figured out that even calling XSetWMNormalHints() without any values will lead to that behaviour. Same for the flickering. @nkrepo: I have updated the repo https://github.com/uli42/nx-libs/tree/tst_flicker, can you please do another test? I am not really sure what we lose by that. Do we need PS: I noticed that VcXsrv opens an X server that does not have any of the NET* properties of the Extended Window Manager Hints (compare output of |
|
I have tested more. I now think that the problem is that we call XMoveWindow() and XMoveResizeWindow() at some places in the code and assume that the nx window will be placed at exactly the position we pass to those calls. But the window managers will place it as they like. Now, if we get a ConfigureNotify event it contains x,y coordinates. We compare them to the ones where we think the window should be (the values we passed in the calls mentioned above) and as they are different we issue further action (involving calling XMoveWindow). Which will trigger further ConfigureNotify events... Depending on the window manager you use on Linux the problem could happen there, too. So the real fix is to ask the xserver for the current window position after a move and store THAT. Which might get tricky and could cause additional traffic on the wire. Further: x,y,width,height in XSizeHints are obsolete and should dropped from our code entirely. |
|
Oh well, I really need to look into this. Thanks for all the research!!!
Mike
…On Wednesday, March 28, 2018, Ulrich Sibiller wrote:
I have tested more. I now think that the problem is that we call XMoveWindow() and XMoveResizeWindow() at some places in the code and assume that the nx window will be placed at exactly the position we pass to those calls. But the window managers will place it as they like. Now, if we get a ConfigureNotify event it contains x,y coordinates. We compare them to the ones where we think the window should be (the values we passed in the calls mentioned above) and as they are different we issue further action (involving calling XMoveWindow). Which will trigger further ConfigureNotify events...
Depending on the window manager you use on Linux the problem could happen there, too.
So the real fix is to ask the xserver for the current window position after a move and store THAT. Which might get tricky and could cause additional traffic on the wire.
Further: x,y,width,height in XSizeHints are obsolete and should dropped from our code entirely.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.
--
Sent from my Fairphone 2 (running Sailfish OS)
|
|
I have been looking at this over and over again. Meanwhile I think this is a bug in VcXsrv's handling of WM_NORMAL_HINTS. The minimal code below also triggers the behaviour on VcXsrv. Note that is does not change any value of WM_NORMAL_HINTS. Nevertheless, removing the SetXWMNormalHints() call fixes the flickering: |
|
I have opened a bug for VcXSrv on SourceForge: https://sourceforge.net/p/vcxsrv/bugs/71/ |
|
On Sa 14 Apr 2018 22:47:29 CEST, Ulrich Sibiller wrote:
I have opened a bug a VcXSrv on SourceForge:
https://sourceforge.net/p/vcxsrv/bugs/71/
The statement about Windows 7 in that bug report is wrong. I have seen
it happen on Win7.
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: [email protected], http://das-netzwerkteam.de
|
|
Thanks. I have added that information to the bug. It was mentioned above but I seem to have forgotten about that. |
|
Hi Uli,
On Sa 14 Apr 2018 22:10:01 CEST, Ulrich Sibiller wrote:
I have been looking at this over and over again. Meanwhile I think
this is a bug in VcXsrv's handling of WM_NORMAL_HINTS. The minimal
code below also triggers the behaviour on VcXsrv. Not that is does
not change any value of WM_NORMAL_HINTS. Nevertheless, removing the
SetXWMNormalHints() fixes the flickering:
```
/* gcc -v -L/usr/lib/x86_64-linux-gnu flicker.c -o flicker -lX11 */
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void SetSizeHints(Display *display, Window window)
{
XSizeHints * sizeHints = XAllocSizeHints();
/* comment this line to make the flickering go away: */
XSetWMNormalHints(display, window, sizeHints);
XFree(sizeHints);
}
int main(void) {
Display *display;
Window win;
XEvent X;
int screen;
if (!(display = XOpenDisplay(NULL)))
exit(1);
screen = DefaultScreen(display);
win = XCreateSimpleWindow(display, RootWindow(display, screen),
10, 10, 100, 100, 0,
BlackPixel(display, screen),
WhitePixel(display, screen));
XMapWindow(display, win);
XSelectInput(display, win, KeyPressMask | StructureNotifyMask);
while (1) {
XNextEvent(display, &X);
if (X.xany.serial > 100)
break;
if (X.type == KeyPress)
break;
if (X.type == ConfigureNotify)
{
fprintf(stderr, "self [%p] ConfigureNotifyEvent: s/n [%ld],
Window [%p] Event [%p] X/Y [%d,%d] W*H [%dx%d] send_evnt [%d] border
[%d] above [%p] override [%d]\n", (void *)win, X.xconfigure.serial,
(void *)X.xconfigure.window, (void *)X.xconfigure.event,
X.xconfigure.x, X.xconfigure.y, X.xconfigure.width,
X.xconfigure.height, X.xconfigure.send_event,
X.xconfigure.border_width, (void *)X.xconfigure.above,
X.xconfigure.override_redirect);
SetSizeHints(display, win);
}
}
XCloseDisplay(display);
return 0;
}
```
If I get this right, the problem is caused by x,y,width and height
being set in the size hints.
From
https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-normal-hints.html I read that those params are obsolete and should be left
out.
IIRC, the XWin code when -multiwindow is given fires up some minimal
internal window manager.
Can we do the XSetWMNormalHints but omit the position and geometry
part of the size hints? Would that help?
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: [email protected], http://das-netzwerkteam.de
|
|
No. My example code does not set ANY hint and it still happens. I have
also tested exactly your suggestion in nxagent but the problems
remains.
Besides: x,y,width and height are obsolete, but nevertheless are being
used by some window managers.
…On Sat, Apr 14, 2018 at 11:35 PM, Mike Gabriel ***@***.***> wrote:
Hi Uli,
On Sa 14 Apr 2018 22:10:01 CEST, Ulrich Sibiller wrote:
> I have been looking at this over and over again. Meanwhile I think
> this is a bug in VcXsrv's handling of WM_NORMAL_HINTS. The minimal
> code below also triggers the behaviour on VcXsrv. Not that is does
> not change any value of WM_NORMAL_HINTS. Nevertheless, removing the
> SetXWMNormalHints() fixes the flickering:
>
> ```
> /* gcc -v -L/usr/lib/x86_64-linux-gnu flicker.c -o flicker -lX11 */
>
> #include <X11/Xlib.h>
> #include <X11/Xutil.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> void SetSizeHints(Display *display, Window window)
> {
> XSizeHints * sizeHints = XAllocSizeHints();
> /* comment this line to make the flickering go away: */
> XSetWMNormalHints(display, window, sizeHints);
> XFree(sizeHints);
> }
>
> int main(void) {
> Display *display;
> Window win;
> XEvent X;
> int screen;
>
> if (!(display = XOpenDisplay(NULL)))
> exit(1);
>
> screen = DefaultScreen(display);
> win = XCreateSimpleWindow(display, RootWindow(display, screen),
> 10, 10, 100, 100, 0,
> BlackPixel(display, screen),
> WhitePixel(display, screen));
> XMapWindow(display, win);
> XSelectInput(display, win, KeyPressMask | StructureNotifyMask);
>
> while (1) {
> XNextEvent(display, &X);
> if (X.xany.serial > 100)
> break;
> if (X.type == KeyPress)
> break;
> if (X.type == ConfigureNotify)
> {
> fprintf(stderr, "self [%p] ConfigureNotifyEvent: s/n [%ld],
> Window [%p] Event [%p] X/Y [%d,%d] W*H [%dx%d] send_evnt [%d] border
> [%d] above [%p] override [%d]\n", (void *)win, X.xconfigure.serial,
> (void *)X.xconfigure.window, (void *)X.xconfigure.event,
> X.xconfigure.x, X.xconfigure.y, X.xconfigure.width,
> X.xconfigure.height, X.xconfigure.send_event,
> X.xconfigure.border_width, (void *)X.xconfigure.above,
> X.xconfigure.override_redirect);
> SetSizeHints(display, win);
> }
> }
> XCloseDisplay(display);
> return 0;
> }
> ```
If I get this right, the problem is caused by x,y,width and height
being set in the size hints.
From
https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-normal-hints.html
I read that those params are obsolete and should be left
out.
IIRC, the XWin code when -multiwindow is given fires up some minimal
internal window manager.
Can we do the XSetWMNormalHints but omit the position and geometry
part of the size hints? Would that help?
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: ***@***.***, http://das-netzwerkteam.de
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@mikedep333 Hi Mike#2, can you please examine what happens in the vcxsrv code when my example code from above is executed? Maybe you can even find a fix! Thx! |
|
Good news everyone: vcxsrv 1.19.6.4 got released today and the release notes mention "Solved some flickering problems". An indeed: It works! |
|
Does this mean next release of the client will have the fix, or is there some steps we can take to update the current installation? |
|
@attzonko: I guess that next client release will contain the new vcxsrv version but I don't know if there are other reasons why x2go does still ship an older version. Meanwhile I suggest you download the the current vcxsrv from sourceforge, install it and configure x2goclien to use that version (Menu =Options/Settings=, Tab =Xorg Server Settings=) |
|
Our vcxsrv version is patched, which means that it must be rebased for every new version and then built. That takes @mikedep333 quite a bit of time and generally any fixes in vcxsrv are considered non-security-related, since the software is not running with elevated privileges on Windows. |
|
In that case it should be possible to backport that single commit to
our current patched version.
Out of curiosity: what patches are included?
…On Fri, Apr 20, 2018 at 12:37 AM, Mihai Moldovan ***@***.***> wrote:
Our vcxsrv version is patched, which means that it must be rebased for every
new version and then built.
That takes @mikedep333 quite a bit of time and generally any fixes in vcxsrv
are considered non-security-related, since the software is not running with
elevated privileges on Windows.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
It's probably easier to fully upgrade this time, no idea what other stuff was changed. Mostly build fixes, but also other stuff. See the commit history for details and especially the x2go/arctica release notes. |
|
Thus, closing. The issue is not an nx-libs issue, but burried in old versions of VcXsrv. Please upgrade VcXsrv to vcxsrv 1.19.6.4 or newer, if you encounter this issue. |
|
Good morning every one, Can someone tell me how to configure the new vcxsrv with the x2goclient? |
|
On Mon, May 7, 2018 at 6:41 PM, soportecasator ***@***.***> wrote:
Good morning every one, Can someone tell me how to configure the new vcxsrv with the x2goclient?
1. install latest vcxsrv from sourceforge.
2. open x2goclient
3. in x2goclient's configuration menu (_not_ the confguration dialog
for a single connection) change the xserver configuration to the
freshly installed vcxsrv
Hope that helps,
Uli
|
|
@sunweaver Will an updated VcXsrv be shipped with x2go Windows client? And if it is supposed to happen, is this evtl. scheduled already? |
|
Updating to X2go client V 1.4.2.0 on windows resolves my same issue. While Installing and pointing to vcxsrv installed separately brings up a problem of unable to copy from windows to target machine. |
|
Thank you very much, it´s works :)
From: "Rahul Nagekar" <[email protected]>
To: "ArcticaProject/nx-libs" <[email protected]>
Cc: "Carlos Omar Alonzo Alfaro" <[email protected]>, "Comment" <[email protected]>
Sent: Friday, July 12, 2019 5:15:40 AM
Subject: Re: [ArcticaProject/nx-libs] Desktop flashing when maximizing window on second screen with Windows client (#600)
Updating to X2go client V 1.4.2.0 on windows resolves my same issue.
While Installing and pointing to vcxsrv installed separately brings up a problem of unable to copy from windows to target machine.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub , or mute the thread .
…--
Carlos O. Alonzo A |Casa del tornillo, S.A |Departamento de informática | Data Center | mail: [email protected]
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the Windows X2Goclient, in a multihead setup, if you maximize a windowed desktop session (MATE session for instance but I guess it happens with any DE) this window keeps on flashing and most of the time, it can't seem to get a fixed size and position.
The only workaround in that case is to resize the window by hand and not maximize it.
This doesn't seem to happen with the pre-3.6 ("x2go stable") libs but only with Arctica ones.
The text was updated successfully, but these errors were encountered: