Xpra: Ticket #555: 0.12.2: multi-monitor positioning issues

In 0.12.2 I found a regression from 0.11.x: in kmail menus open properly only on leftmost monitor. When application window is on the middle monitor then its menus opens on the right side of the leftmost monitor. I'm using the following monitor configuration:

2014-04-04 08:06:40,047 desktop size is 4960x1200 with 1 screen(s):
2014-04-04 08:06:40,047   ':0.0' (1310x317 mm) workarea: 4960x1167 at 0x33
2014-04-04 08:06:40,047     DisplayPort-1 1680x1050 at 0x30 (474x296 mm)
2014-04-04 08:06:40,047     DisplayPort-0 1680x1050 at 1680x0 (474x296 mm)
2014-04-04 08:06:40,047     DVI-0 1600x1200 at 3360x0 (408x306 mm)
2014-04-04 08:06:40,460 server: Linux debian 7.4 , Xpra version 0.12.2 (r5949)

Vertical positioning is incorrect on middle monitor where I have KDE task bar (on top): when I drag-n-drop URL to bookmark bar in Iceweasel I have to position mouse cursor above the target approximately height of the bar.



Fri, 04 Apr 2014 04:32:27 GMT - Antoine Martin: attachment set

avoids setting the window screen or workspace


Fri, 04 Apr 2014 04:33:24 GMT - Antoine Martin: owner changed

I don't have multi-monitors here... so that's going to be tricky to test.

Please post the client and server output of 0.12.x with -d workspace.

It sounds to me like the vertical positioning is a separate issue (different ticket), is it also a regression? Do you have wiki/FakeXinerama installed? Does it make any difference?

Does the patch above help? If so, what does the client output say?


Fri, 04 Apr 2014 05:51:56 GMT - onlyjob:

Patch completely fixed horizontal menu positioning issue -- thank you so very much for it.

2014-04-04 16:34:03,898 NOT setting window 1 to screen <gtk.gdk.ScreenX11 object at 0x7ff898b73820 (GdkScreenX11 at 0xf73740)>
2014-04-04 16:34:03,984 NOT setting window 26 to screen <gtk.gdk.ScreenX11 object at 0x7ff898b73b90 (GdkScreenX11 at 0xf73740)>
2014-04-04 16:34:04,015 NOT setting window 41 to screen <gtk.gdk.ScreenX11 object at 0x7ff898b84460 (GdkScreenX11 at 0xf73740)>
2014-04-04 16:34:04,017 NOT setting window 59 to screen <gtk.gdk.ScreenX11 object at 0x7ff898b84730 (GdkScreenX11 at 0xf73740)>
2014-04-04 16:34:04,019 NOT setting window 107 to screen <gtk.gdk.ScreenX11 object at 0x7ff898b84a00 (GdkScreenX11 at 0xf73740)>
2014-04-04 16:34:04,227 NOT setting window 726 to screen <gtk.gdk.ScreenX11 object at 0x7ff898b90190 (GdkScreenX11 at 0xf73740)>
2014-04-04 16:34:04,253 NOT setting window 750 to screen <gtk.gdk.ScreenX11 object at 0x7ff898b90410 (GdkScreenX11 at 0xf73740)>
2014-04-04 16:34:04,254 NOT setting window 770 to screen <gtk.gdk.ScreenX11 object at 0x7ff898b906e0 (GdkScreenX11 at 0xf73740)>

with -d workspace:

2014-04-04 16:40:10,045 NOT setting window 1 to screen <gtk.gdk.ScreenX11 object at 0x7f7746a378c0 (GdkScreenX11 at 0x1cecda0)>
2014-04-04 16:40:10,093 NOT setting window 26 to screen <gtk.gdk.ScreenX11 object at 0x7f7746a37be0 (GdkScreenX11 at 0x1cecda0)>
2014-04-04 16:40:10,125 NOT setting window 41 to screen <gtk.gdk.ScreenX11 object at 0x7f7746a4c550 (GdkScreenX11 at 0x1cecda0)>
2014-04-04 16:40:10,126 NOT setting window 59 to screen <gtk.gdk.ScreenX11 object at 0x7f7746a4c820 (GdkScreenX11 at 0x1cecda0)>
2014-04-04 16:40:10,127 NOT setting window 107 to screen <gtk.gdk.ScreenX11 object at 0x7f7746a4caf0 (GdkScreenX11 at 0x1cecda0)>
2014-04-04 16:40:10,199 map event: changed workspace from 0 to -1
2014-04-04 16:40:10,200 configure event: changed workspace from -1 to 0
2014-04-04 16:40:10,245 map event: changed workspace from 0 to -1
2014-04-04 16:40:10,246 configure event: changed workspace from -1 to 0
2014-04-04 16:40:10,293 map event: changed workspace from 0 to -1
2014-04-04 16:40:10,294 configure event: changed workspace from -1 to 0
2014-04-04 16:40:10,297 map event: changed workspace from 0 to -1
2014-04-04 16:40:10,299 configure event: changed workspace from -1 to 0
2014-04-04 16:40:10,302 map event: changed workspace from 0 to -1
2014-04-04 16:40:10,306 configure event: changed workspace from -1 to 0
2014-04-04 16:40:10,329 NOT setting window 726 to screen <gtk.gdk.ScreenX11 object at 0x7f7746a56280 (GdkScreenX11 at 0x1cecda0)>
2014-04-04 16:40:10,333 NOT setting window 770 to screen <gtk.gdk.ScreenX11 object at 0x7f7746a56500 (GdkScreenX11 at 0x1cecda0)>
2014-04-04 16:40:10,463 map event: changed workspace from 0 to -1
2014-04-04 16:40:10,475 configure event: changed workspace from -1 to 0
2014-04-04 16:40:10,524 map event: changed workspace from 0 to -1
2014-04-04 16:40:10,527 configure event: changed workspace from -1 to 0
2014-04-04 16:40:10,535 TrayBacking does not have any pixel data!
2014-04-04 16:40:10,535 TrayBacking does not have any pixel data!
2014-04-04 16:40:10,535 TrayBacking does not have any pixel data!
2014-04-04 16:40:10,536 TrayBacking does not have any pixel data!
2014-04-04 16:40:35,862 map event: changed workspace from None to -1
2014-04-04 16:40:35,863 configure event: changed workspace from -1 to 0
2014-04-04 16:40:45,872 map event: changed workspace from None to -1
2014-04-04 16:40:45,875 configure event: changed workspace from -1 to 0
2014-04-04 16:40:58,374 map event: changed workspace from None to -1
2014-04-04 16:40:58,375 configure event: changed workspace from -1 to 0

The only strange thing (which is no different from 0.11.6) is that all kmail windows (File --> Open, new mail etc.) are opening on the left monitor (but at least menus stay on the same monitor if I move kmail window) while Iceweasel windows correctly opens on the monitor where application is.

I have no FakeXinerama.

As for vertical positioning it is not a regression and now I see it as yet another minor unrelated issue.


Fri, 04 Apr 2014 06:46:44 GMT - Antoine Martin:

Beware that the patch above is only for testing, and probably not the right solution. It tells me that the problem comes from setting the screen the window is on and not the workspace (it could have been workspace as some window managers do odd things).

And since this is a brand new window (the menu), it should not have a screen set yet... We don't even send the "client_properties" which contain the screen number when we get a new window!? Maybe running with "-d window" could shed some light on this. I will have to debug this further as this could be the sign of a more profound bug somewhere.


new mail etc ... are opening on the left monitor ...


This could be related, it could also be that you need wiki/FakeXinerama or that the client window manager just puts them there (maybe the windows aren't children of the top level window... some applications do this unfortunately).

I have no FakeXinerama


You probably should if you have multiple screens.

As for vertical positioning it is not a regression..


Would be good to fix though, please file a ticket. Does this happen if you first move the window before the drag&drop? Is this just with iceweasel?


Wed, 09 Apr 2014 05:42:36 GMT - Antoine Martin:

Using virtualbox with 3 virtual screens and both jessie and sid (I assume this is what you have used?), I can see some odd behaviour with 0.12.2 but not what you describe, instead I hit: #556 and #557. I have tested with kmail installed on the same system and also installed on a remote Fedora 20 box.

Does current 0.12.x svn work for you without any screen related patches? Please confirm so that I can close this ticket and release 0.12.3. If not, please include the -d workspace log output from both ends, preferably using trunk.


Wed, 09 Apr 2014 23:42:41 GMT - onlyjob:

Misplaced menus was one of the symptoms that I experienced (particularly with kmail and synaptic). 0.12.3 fixed this issue. Thank you.

There are few other glitches left like new message window in kmail that always opens on leftmost monitor etc. I'll test and report more (with -d workspace) when I have time...

As for FakeXinerama I don't understand why I "probably should" use it if I'm happy with KDE multi-monitor management...


Thu, 10 Apr 2014 01:42:44 GMT - Antoine Martin:

Misplaced menus was one of the symptoms that I experienced


Then I think the real problem was in fact #557. And I don't understand why my patch made any difference..


There are few other glitches left like new message window in kmail that always opens on leftmost monitor etc


Is this a regression?


As for FakeXinerama I don't understand why I "probably should" use it if I'm happy with KDE multi-monitor management...


Then I failed to explain it properly. The wiki page tries to separate the xpra specific info from the general idea (which can be used for other purposes) and this may have something to do with it.

This library affects X11 client applications running on the xpra server, it has no effect whatsoever on the client side where it does not even get loaded and does not need to be installed.

If you have 3 screens on the client, this is the only way to mirror the same screen configuration in the xpra server. Until now, the xpra server had one big virtual screen and that was all, now we can expose the same 3 screens to the X11 applications - which fixes fullscreen and other window placement issues.

So please try using it and this may even fix some bugs like the one you describe.


Fri, 09 May 2014 13:28:01 GMT - Antoine Martin:

Can I close this?


Mon, 12 May 2014 00:12:46 GMT - onlyjob:

But some of the issues are not fixed... For instance kmail windows are still opens on leftmost monitor disregarding of where main window is located...

For example in kmail "Help-->About KDE" dialog opens on leftmost monitor while in Firefox "Help-->About" opens above main window (as expected).

I don't want FakeXinerama because I don't need to use the same screen configuration... It is more convenient to re-arrange windows as per client monitor setup according to number of currently plugged monitors etc...

I confirm that misplaced menus are fixed, thank you. I didn't have time to follow on vertical positioning issues -- we'll track them in another ticket eventually so as far as I'm concerned the only issue left to fix here is new (dialog) windows positioning.


Sat, 17 May 2014 08:57:05 GMT - Antoine Martin:

I don't want FakeXinerama because I don't need to use the same screen configuration...


How odd. Then expect some unfixable bugs. The applications, or the toolkits they are based on, may use the monitor layout information to place their windows, menus, etc.. Not having it setup means that things will work less well than they are designed to. And since you are complaining about positioning issue, I find it difficult to comprehend!


As for the specific window positioning you refer to, this is what I see:

So firefox places its window, whereas kmail does not... at least not relative to the one monitor I have plugged in.

I don't know for sure if kmail would use the multi-monitor information to position the window differently, but it is certainly worth a try.

In any case, I don't think this issue is a regression, or that it is related to the bug that got fixed in this ticket, so I will probably close this ticket as fixed, unless I have missed something?

(for more information on positioning issues, see #302 and wm-normal-hints)


Sun, 18 May 2014 03:17:51 GMT - onlyjob:

Problem is not specific to kmail. I can reproduce with konsole too, with any Help-->About dialogs. Normally those apps open about dialogs just above main window (I presume application knows its position). In Xpra About dialogs pop at coordinates 0 0 and I have a feeling it could be fixed without fakeXinerama.

fakeXinerama is new in 0.12 and I only had a chance to try it yesterday for the first time. It seems unnecessary for my work flow and it does not fix dialog positioning of konsole anyway. Of course problem is minor but it is not with sophisticated monitor configuration but with large desktop where dialogs opening far away from application window. I don't see how fakeXinerama can be useful for this and I hope this can be fixed without fakeXinerama.

Feel free to close this bug at your convenience but frankly I think there shall be (another?) ticket to track this issue. As far as I can tell all QT applications are affected so it is not an isolated case and definitely worth fixing if possible.


Tue, 29 Jul 2014 10:44:42 GMT - Antoine Martin:

Relevant link: Remember+restore window position of applications with WM_WINDOW_ROLE or window title set


Tue, 19 Aug 2014 06:59:17 GMT - Antoine Martin: owner, status changed; milestone set

maybe try to deal with this in 0.15


Wed, 27 Aug 2014 14:33:14 GMT - Antoine Martin: attachment set

only set the window position if it means something


Wed, 27 Aug 2014 14:34:26 GMT - Antoine Martin:

The patch above fixes the behaviour with konsole and others, I want to review and deal with the FIXME before merging it. Will probably backport in R+1 if it doesn't break anything.

It isn't really clean: we only set the request-position flag from the wm-hints, an application could create the window then move it to 0,0 and we would then not honour the new position.


Fri, 29 Aug 2014 14:22:12 GMT - Antoine Martin: owner, status changed

The FIXME in the patch above was in the wrong place, and I couldn't find any applications causing problems.

So r7478 is a simple solution that fixes the problem.

@onlyjob: please confirm that this works for you and I will backport to v0.14.x


Sun, 31 Aug 2014 00:27:15 GMT - onlyjob:

It works quite well, thank you.


Fri, 12 Sep 2014 02:06:36 GMT - Antoine Martin: status changed; resolution set

Backport to v0.14.x was in r7501. Closing.


Sat, 23 Jan 2021 04:59:14 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/555