I am using xpra v0.14.12 on CentOS 6 and xpra v0.15 beta on Windows. I used xpra for quite some time and menus worked. However, suddenly, out from nothing, menus appear on different locations on screen.
This is how it looks like:
However, not always: It depends on the position on the screen. The screen consists of two monitors: left and right. On the left monitor, the menus are always displayed correctly. On the right side, they are displayed correctly when the window is close the the left monitor (maybe 1/3 of the monitor width). If it is placed on the right side of the right monitor, the menu click looks like on the screenshot above.
First I thought this is related to what I wrote in ticket:349#comment:41 ... It seemed it appeared after I installed the beta xdummy driver and a similar issue occured: The menus were placed right at the monitor intersection when the window is on right monitor.
But now I reinstalled xpra with the original xdummy driver I had before and it still occurs. So for me it seems it started out from nothing.
In general, I always suffered big problems witht this application: Often times xpra server crashes on startup, sometimes afterwards while working.
Maybe all this is related to a certain toolkit this app uses. It is a proprietary application so I am note really sure which toolkit it is but it seems to Qt based on ldd:
ldd virtuoso | grep -v 'not found' linux-vdso.so.1 => (0x00007fffdbfff000) libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f6525020000) liboaDesign.so => /cad/cadence/IC615.06.15.502.lnx/oa_v22.41.005/lib/linux_rhel40_gcc44x_64/opt/liboaDesign.so (0x00007f65243d2000) liboaDM.so => /cad/cadence/IC615.06.15.502.lnx/oa_v22.41.005/lib/linux_rhel40_gcc44x_64/opt/liboaDM.so (0x00007f65240d4000) liboaCM.so => /cad/cadence/IC615.06.15.502.lnx/oa_v22.41.005/lib/linux_rhel40_gcc44x_64/opt/liboaCM.so (0x00007f6523e99000) liboaTech.so => /cad/cadence/IC615.06.15.502.lnx/oa_v22.41.005/lib/linux_rhel40_gcc44x_64/opt/liboaTech.so (0x00007f6523a18000) liboaPlugIn.so => /cad/cadence/IC615.06.15.502.lnx/oa_v22.41.005/lib/linux_rhel40_gcc44x_64/opt/liboaPlugIn.so (0x00007f6523803000) liboaBase.so => /cad/cadence/IC615.06.15.502.lnx/oa_v22.41.005/lib/linux_rhel40_gcc44x_64/opt/liboaBase.so (0x00007f6523214000) liboaCommon.so => /cad/cadence/IC615.06.15.502.lnx/oa_v22.41.005/lib/linux_rhel40_gcc44x_64/opt/liboaCommon.so (0x00007f6522ffd000) libQtCore.so.4 => /usr/lib64/libQtCore.so.4 (0x0000003e1fa00000) libQtGui.so.4 => /usr/lib64/libQtGui.so.4 (0x0000003e21200000) libQt3Support.so.4 => /usr/lib64/libQt3Support.so.4 (0x0000003e22400000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003e1c600000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e18200000) librt.so.1 => /lib64/librt.so.1 (0x0000003e18a00000) libXt.so.6 => /usr/lib64/libXt.so.6 (0x0000003e20200000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003e1b600000) libQtXml.so.4 => /usr/lib64/libQtXml.so.4 (0x0000003e1c200000) libQtSql.so.4 => /usr/lib64/libQtSql.so.4 (0x0000003e22000000) libQtNetwork.so.4 => /usr/lib64/libQtNetwork.so.4 (0x0000003e1e200000) libQtTest.so.4 => /usr/lib64/libQtTest.so.4 (0x00007f6522dc3000) libQtOpenGL.so.4 => /usr/lib64/libQtOpenGL.so.4 (0x00007f6522aff000) libQtAssistantClient.so.4 => /usr/lib64/libQtAssistantClient.so.4 (0x00007f65228f9000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x0000003e1de00000) libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f6522678000) libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003e27a00000) libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003e1a200000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e1d200000) libm.so.6 => /lib64/libm.so.6 (0x0000003e17e00000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e1ba00000) libc.so.6 => /lib64/libc.so.6 (0x0000003e17a00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003e18600000) libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x0000003e1da00000) libz.so.1 => /lib64/libz.so.1 (0x0000003e18e00000) libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x0000003e19e00000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003e19200000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0000003e1d600000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003e1ca00000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f6522425000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x0000003e20600000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003e20e00000) libXi.so.6 => /usr/lib64/libXi.so.6 (0x0000003e1e600000) libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x0000003e1ea00000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x0000003e1f200000) libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x0000003e1f600000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x0000003e1ee00000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x0000003e1ce00000) /lib64/ld-linux-x86-64.so.2 (0x0000003e17600000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000003e1ae00000) libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003e26600000) libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x0000003e25a00000) libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007f65221f9000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f6521ff7000) libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x0000003e1a600000) libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00007f6521de0000) libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007f6521bdc000) libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007f65219d6000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x0000003e1b200000) libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003e19600000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f65217d1000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003e1be00000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003e1aa00000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003e25e00000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003e24a00000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003e20a00000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003e25200000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003e25600000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003e24e00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003e19a00000)
Ok, I nailed down the error a bit: At least this one is related to the Windows client!
I tried all available beta builds and here are the results:
cygwin X server works xpra 0.14.11-8096 works xpra 0.14.12-8135 works xpra 0.15.0-7338 works xpra 0.15.0-7840 connection lost xpra 0.15.0-7909 connection lost xpra 0.15.0-7928 NO
The versions with "connection lost" have a different bug with which I can't even connect to the server (I get immideately connection lost) so I can't check those.
But I can say for sure that the menus are displayed correctly up to 0.15.0-7338 and do not work with 0.15.0-7928 any more.
(of course, all the crashes occur independently from this menu issue)
@lukashaase: thanks for the version tests, can you try a few more to narrow it down? I see a few beta versions between 7338 (works) and 7840. And if needed, I can build a few more.
Unfortunately I did already whatever I could. As mentioned, a bulk of these betas have a different bug where I get "Connection lost" right out of the box - there is not even an SSH connection established.
I tried nearly every available beta and updated the list:
cygwin X server works xpra 0.14.11-8096 works xpra 0.14.12-8135 works xpra 0.15.0-7338 works Xpra_Setup_0.15.0-r7421.exe works Xpra_Setup_0.15.0-r7537.exe connection lost Xpra_Setup_0.15.0-r7577M.exe nothing happens on dbl click Xpra_Setup_0.15.0-r7639.exe connection lost Xpra_Setup_0.15.0-r7835.exe connection lost xpra 0.15.0-7840 connection lost xpra 0.15.0-7909 connection lost xpra 0.15.0-7928 NO
The latest I can try and works is Xpra_Setup_0.15.0-r7421.exe. From then on, until 0.15.0-7909 there is this "Connection lost" bug - I can't try them. And starting with 0.15.0-7928, the problem occurs.
What I can add regarding the "connection lost" bug: My SSH agent is queried so the SSH client is started. On the server, there appears a socket quickly in "netstat -anp" but the server does not display any connection. Using xpra_cmd.exe I get:
$ ./Xpra_cmd attach ssh:lukas@192.168.0.192:1984 -d debug 2014-12-03 22:55:46,759 xpra client version 0.15.0 ** Message: pygobject_register_sinkfunc is deprecated (GstObject) 2014-12-03 22:55:47,321 OpenGL_accelerate module loaded 2014-12-03 22:55:47,321 Using accelerated ArrayDatatype 2014-12-03 22:55:47,476 detected keyboard: layout=us 2014-12-03 22:55:47,476 desktop size is 3200x1200 with 1 screen(s): 2014-12-03 22:55:47,476 '1\WinSta-Default' (846x317 mm) 2014-12-03 22:55:47,476 DISPLAY1 1920x1200 at 1280x0 (677x423 mm) 2014-12-03 22:55:47,476 DISPLAY2 1280x768 at 0x193 (452x271 mm) 2014-12-03 22:55:48,802 disconnected without receiving a single packet, not an xpra server? 2014-12-03 22:55:48,802 (maybe it does not support 'unknown' compression or 'bencode' packet encoding) 2014-12-03 22:55:48,802 Connection lost
However, this bug disappeared in 7928 again so I am not sure if it is worth catching this one ...
I believe that the errors you are seeing with "connection lost" are due to r7912, so I have made a few more win32 builds that can help us narrow it down:
Hopefully we can narrow it down a bit more..
Ahi antoine, thanks for providing these build!
Update:
7500 works 7600M works 7700M works 7800M works 7912 NO 8152M NO
So it seems somewhere between 7800 and 7912. Still over 100 revisions ...
Damn, I didn't realize you would be so quick to test those builds, otherwise I would have done it sooner - I'll do more tomorrow.
A shot in the dark, can you try setting XPRA_DPI_AWARE=0
before launching xpra.exe or xpra_launcher.exe?
Some notes for myself on the best revisions to test from reviewing the ~112 changesets left - nothing really stands out:
No worries ;-) Thanks for being so active and quick on xpra!! At least I found no changes when I set XPRA_DPI_AWARE=0 before calling, unfortunately ...
I've put up some more builds, can you narrow it down a bit more? (all the ones date Dec 04) BTW, AFAICT even the other builds should work if you use bash as login shell. It may be worth checking the very latest too, just in case we've broken something again.
Ok, narrowed it down more:
7500 works 7600M works 7700M works 7800M works 7823M works 7826M NO 7839 NO 7841M NO 7875M NO 7912 NO 8152M NO
Between 7823M and 7826M sounds more doable. Yeah, indeed I used tcsh!
The culprit is very likely to be r7826. Does r8200 fix things? (new beta available)
What does the old / new NativeGUI_info.exe
print? This is also included under the "System" part of the bug reporting tool.
I think I have implemented this wrong: SPI_GETWORKAREA - 0x0030 - Retrieves the size of the work area on the primary display monitor. The work area is the portion of the screen not obscured by the system taskbar or by application desktop toolbars. The pvParam parameter must point to a RECT structure that receives the coordinates of the work area, expressed in virtual screen coordinates. To get the work area of a monitor other than the primary display monitor, call the GetMonitorInfo? function.
So it looks like I need to use GetMonitorInfo instead. The reason why this worked for me is that I only have a single monitor to test on with win32...
Indeed it does :-) Great job!
At the beginning I hoped that this bug goes hand-in-hand with ticket:349#comment:41 ... but it seems not, unfortunately. Can you say now that these two are completely unrelated?
PS: For reference, NativeGUI info before/after:
* double_click.distance : (-1, -1) * double_click.time : 550 * icon_size : 24 * native_notifiers : ['Win32_Notifier'] * native_system_trays : ['Win32Tray'] * native_tray_menu_helpers : [] * native_trays : ['Win32Tray'] * system_bell : system_bell * vertical-refresh : -1 * workarea :
* antialias.contrast : 1200 * antialias.enabled : True * antialias.hinting : True * antialias.orientation : RGB * antialias.type : ClearType * double_click.distance : (4, 4) * double_click.time : 550 * dpi : 96 * dpi.x : 96 * dpi.y : 96 * fixed_cursor_size : (32, 32) * icon_size : 16 * native_notifiers : ['Win32_Notifier'] * native_system_trays : ['Win32Tray'] * native_tray_menu_helpers : [] * native_trays : ['Win32Tray'] * system_bell : system_bell * vertical-refresh : 59 * window_frame.border : 1 * window_frame.caption : 19 * window_frame.fixed : (3, 3) * window_frame.menu-bar : 19 * window_frame.minimum : (112, 27) * window_frame.normal : (4, 4) * workarea
OK, so r8204 + r8205 implements calls to GetMonitorInfo
, the python part turns out to be trivial, integrating into our code which expects relative coordinates and a single workarea covering all the monitors... not so much.
But we now expose the full workarea information (should we need it in the future), and calculate the single workarea from it, using the maximum dimensions. I can't think of a better rule for calculating it.. New beta build posted too.
In the process I also found some bugs (r8202) that need backporting. Yay!
@lukashaase: if that works for you, please close.
Nearly, thanks!
r8200 works like a charm (as mentioned above).
JFYI: r8205 has another bug - not sure if it's related to that, so leaving open ...
When I connect to the server I get
server requested disconnect: server error (error accepting new connection)
With Xpra_cmd.exe:
2014-12-05 04:01:42,506 xpra client version 0.15.0 ** Message: pygobject_register_sinkfunc is deprecated (GstObject) 2014-12-05 04:01:43,095 OpenGL_accelerate module loaded 2014-12-05 04:01:43,095 Using accelerated ArrayDatatype 2014-12-05 04:01:43,239 detected keyboard: layout=us 2014-12-05 04:01:43,239 desktop size is 3200x1200 with 1 screen(s): 2014-12-05 04:01:43,239 '2\WinSta-Default' (846x317 mm - DPI: 96x96) workarea: 1920x1167 at -1280x0 2014-12-05 04:01:43,239 DISPLAY1 1920x1200 at 1280x0 (677x423 mm - DPI: 72x72) workarea: 1920x1167 2014-12-05 04:01:43,239 DISPLAY2 1280x768 at 0x193 (452x271 mm - DPI: 71x71) workarea: 1280x768 2014-12-05 04:01:44,868 server failure: disconnected before the session could be established 2014-12-05 04:01:44,868 server requested disconnect: server error (error accepting new connection) 2014-12-05 04:01:45,111 Connection lost
JFYI: r8205 has another bug..
That's r8202, which needs to land in stable too. It's a very old bug that I've discovered with these changes (it never fired before).
Beta 0.15 packages are available with that fix. Will probably do 0.14.13 tomorrow.
Sorry, I don't really understand...
r8200 works perfectly where this bug (#751) is fixed.
I understand that r8202 fixes (not opens!) another bug.
So in to my understanding this should also work (8205 > 8202 > 8200). But it does not.
Therefore I am currently using the beta Xpra_Setup_0.15.0-r8200.exe (although the newer but buggy Xpra_Setup_0.15.0-r8205.exe is available).
That's because the change in r8204 + r8205 exposes the bug in the server, so you need to update that to connect with 0.15.0 >8202 windows client.
You can use the beta 0.15 packages, or wait for 0.14.13
Aaaaaalright that makes sense. Thanks for the clarification!
Can it be that this bug was re-introduced?
On the server I have now xpra v0.14.18, on Windows 0.15.0-8492. Still the same problems now ...
0.15 is a beta - if you downgrade your client back down to 0.14.18, it should be ok. But before you do, can you post the Native_GUI.exe
output, as well as the server side xprop -root
?
I guess it could also be related to your fakexinerama problems in #798.
I hope it's not too early to say that but you are right, with 0.14.18-8503 it works. I used 0.15 because some other bugs are fixed in 0.15 beta but not 0.14 (e.g. #747)
I think I also used 0.15beta before and according to your statement above ("You can use the beta 0.15 packages, or wait for 0.14.13") I thought this should also work for 0.15 now. Will these changes still go to 0.15 too?
Here are the outputs:
* antialias.contrast : 1200 * antialias.enabled : True * antialias.hinting : True * antialias.orientation : RGB * antialias.type : ClearType * desktop_names : [] * desktops : 1 * double_click.distance : (4, 4) * double_click.time : 550 * dpi : 96 * dpi.x : 96 * dpi.y : 96 * fixed_cursor_size : (32, 32) * icon_size : 16 * native_notifiers : ['Win32_Notifier'] * native_system_trays : ['Win32Tray'] * native_tray_menu_helpers : [] * native_trays : ['Win32Tray'] * system_bell : system_bell * vertical-refresh : 59 * window_frame.border : 1 * window_frame.caption : 19 * window_frame.fixed : (3, 3) * window_frame.menu-bar : 19 * window_frame.minimum : (112, 27) * window_frame.normal : (4, 4) * workarea : (-1280, 0, 1920, 1167) * workareas : [(0, 0, 1920, 1167), (0, 0, 1280, 768)] Press Enter to close
CUT_BUFFER0(STRING) = "$ xprop -root\ndummy-constant-ydpi(CARDINAL) = 96\ndummy-constant-xdpi(CARDINAL) = 96\nRESOURCE_MANAGER(STRING) = \"gnome.Xft/DPI:\\t98304\\nXft.dpi:\\t96\\n\"\n_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0xc00022\n_NET_CLIENT_LIST(WINDOW): window id # 0xc00022\n_NET_ACTIVE_WINDOW(CARDINAL) = 12582946\n_NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0\n_NET_DESKTOP_GEOMETRY(CARDINAL) = 3200, 1200\n_NET_WORKAREA(CARDINAL) = 0, 0, 640, 1167\n_NET_SUPPORTED(ATOM) = _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_WM_FULL_PLACEMENT, _NET_WM_HANDLED_ICONS, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_DESKTOP_VIEWPORT, _NET_DESKTOP_GEOMETRY, _NET_NUMBER_OF_DESKTOPS, _NET_DESKTOP_NAMES, _NET_WORKAREA, _NET_ACTIVE_WINDOW, _NET_CURRENT_DESKTOP, WM_NAME, _NET_WM_NAME, WM_ICON_NAME, _NET_WM_ICON_NAME, WM_CLASS, WM_PROTOCOLS, _NET_WM_PID, WM_CLIENT_MACHINE, WM_STATE, _NET_WM_ALLOWED_ACTIONS, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_USER_TIME, _NET_WM_USER_TIME_WINDOW, WM_HINTS, WM_NORMAL_HINTS, WM_TRANSIENT_FOR, _NET_WM_STRUT, _NET_WM_STRUT_PARTIAL_NET_WM_ICON, _NET_FRAME_EXTENTS, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_COMBO, _NET_WM_STATE, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_MODAL, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_HIDDEN, _NET_WM_STATE_FULLSCREEN, _MOTIF_WM_HINTS, _MOTIF_WM_INFO, _NET_WM_MOVERESIZE\n_NET_CURRENT_DESKTOP(CARDINAL) = 0\n_NET_DESKTOP_NAMES(UTF8_STRING) = \"Main\"\n_NET_NUMBER_OF_DESKTOPS(CARDINAL) = 1\n_NET_WM_NAME(UTF8_STRING) = \"Xpra\"\n_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x40001e\n" dummy-constant-ydpi(CARDINAL) = 96 dummy-constant-xdpi(CARDINAL) = 96 RESOURCE_MANAGER(STRING) = "gnome.Xft/DPI:\t98304\nXft.dpi:\t96\n" _NET_CLIENT_LIST_STACKING(WINDOW): window id # 0xc00022 _NET_CLIENT_LIST(WINDOW): window id # 0xc00022 _NET_ACTIVE_WINDOW(CARDINAL) = 12582946 _NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0 _NET_DESKTOP_GEOMETRY(CARDINAL) = 3200, 1200 _NET_WORKAREA(CARDINAL) = 0, 0, 640, 1167 _NET_SUPPORTED(ATOM) = _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_WM_FULL_PLACEMENT, _NET_WM_HANDLED_ICONS, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_DESKTOP_VIEWPORT, _NET_DESKTOP_GEOMETRY, _NET_NUMBER_OF_DESKTOPS, _NET_DESKTOP_NAMES, _NET_WORKAREA, _NET_ACTIVE_WINDOW, _NET_CURRENT_DESKTOP, WM_NAME, _NET_WM_NAME, WM_ICON_NAME, _NET_WM_ICON_NAME, WM_CLASS, WM_PROTOCOLS, _NET_WM_PID, WM_CLIENT_MACHINE, WM_STATE, _NET_WM_ALLOWED_ACTIONS, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_USER_TIME, _NET_WM_USER_TIME_WINDOW, WM_HINTS, WM_NORMAL_HINTS, WM_TRANSIENT_FOR, _NET_WM_STRUT, _NET_WM_STRUT_PARTIAL_NET_WM_ICON, _NET_FRAME_EXTENTS, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_COMBO, _NET_WM_STATE, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_MODAL, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_HIDDEN, _NET_WM_STATE_FULLSCREEN, _MOTIF_WM_HINTS, _MOTIF_WM_INFO, _NET_WM_MOVERESIZE _NET_CURRENT_DESKTOP(CARDINAL) = 0 _NET_DESKTOP_NAMES(UTF8_STRING) = "Main" _NET_NUMBER_OF_DESKTOPS(CARDINAL) = 1 _NET_WM_NAME(UTF8_STRING) = "Xpra" _NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x40001e XPRA_SERVER(STRING) = "0.14.18" _XPRA_SERVER_UUID(STRING) = "168d7500892d4e4691938ea20bfcfce4" _XPRA_SERVER_PID(CARDINAL) = 11709 _XKB_RULES_NAMES(STRING) = "base", "pc105", "us", "", "" VFB_IDENT(STRING) = "TRUE"
Will these changes still go to 0.15 too?
These changes landed in trunk (0.15) before 0.14... (that's how we do it 99% of the time)
The problem is that 0.15 has further changes - causing other problems.
The good news is that I believe the problem is pretty obvious:
desktop size is 3200x1200 with 1 screen(s): '2\WinSta-Default' (846x317 mm - DPI: 96x96) workarea: 1920x1167 at -1280x0 DISPLAY1 1920x1200 at 1280x0 (677x423 mm - DPI: 72x72) workarea: 1920x1167 DISPLAY2 1280x768 at 0x193 (452x271 mm - DPI: 71x71) workarea: 1280x768
Native_GUI.exe
we get:
* workarea : (-1280, 0, 1920, 1167) * workareas : [(0, 0, 1920, 1167), (0, 0, 1280, 768)]
_NET_WORKAREA(CARDINAL) = 0, 0, 640, 1167
Looks to me like:
workareas
is correct
workarea
is wrong (should just be zero based?)
_NET_WORKAREA
is also wrong (and I have no idea where 640 comes from - why we substract instead of using the maximum common size..)
I should be able to test with virtualbox and two virtual monitors.
It took 3 attempts, but as of r8566 we should be calculating the workarea properly no matter where the monitor starts (negative values in the case where the primary is not the first monitor)
Works for me with a similar setup to yours.
Can you try the latest win32 beta and see if that fixes things?
Thanks, however, the latest beta builds seem to have another bug: When I execute Xpra-Launcher.exe, just nothing happens.
The latest version which works for me is Xpra_Setup_0.15.0-r8492.exe.
I've just spent an hour trying to bisect "launcher does not start", only to find that it does start... No idea what happened there with the builds that had this problem, same build machine, same setup, same revision.. different result!? The latest beta build I have just uploaded definitely does start, at least for-me(tm) (at revision 8572), you should be able to use it.
Thanks for your efforts. Unfortunately it does still not start for me. However, if I start if from command line I get debugging info:
$ ./Xpra-Launcher.exe ** Message: pygobject_register_sinkfunc is deprecated (GstObject) Traceback (most recent call last): File "xpra_launcher", line 8, in <module> File "xpra\client\gtk_base\client_launcher.pyc", line 714, in main File "xpra\client\gtk_base\client_launcher.pyc", line 118, in __init__ File "xpra\client\gtk2\client.pyc", line 62, in init File "xpra\client\gtk_base\gtk_client_base.pyc", line 58, in init File "xpra\client\ui_client_base.pyc", line 233, in init AttributeError: 'AdHocStruct' object has no attribute 'scaling'
Does this help?
AttributeError: 'AdHocStruct' object has no attribute 'scaling'
That looks to me like it's still using the old 0.14.x classes somehow.
It's MS Windows, maybe it needs a reboot or something. Try clearing the "Program Files\Xpra" directory before installing the latest version.
This is what I did already. Also different user profile does not help :(
Wait, it's happening again!?
Taking this ticket back until I figure out what is going on here.
The error was obvious (and fixed in r8578 and also much easier to see as of r8576), what I still don't understand is how it ever worked for me knowing this! (and I swear it did - very sorry for wasting your time)
Anyway, the latest beta build works, for sure, this time.
No apologies, you spend so much time - thanks for your effort in this project! Yes, this one is working now but unfortunately I get "Connection lost" now. I had this problem already, I vaguely remember it had something to do with my login shell being tcsh. Running "ps aux|grep xpra" in an infinite loop I can see that this process shortly appears:
tcsh -c xpra initenv || echo "Warning: xpra server does not support initenv" 1>&2;~/.xpra/run-xpra _proxy :1900
Unfortunately I can't remember how I/we solved this issue...
Nevermind, I think there was a problem with my setup. I restarted the server and it worked. So this 0.15 works.
Regarding the original bug:
It took 3 attempts, but as of r8566 we should be calculating the workarea properly no matter where the monitor starts (negative values in the case where the primary is not the first monitor) Works for me with a similar setup to yours. Can you try the latest win32 beta and see if that fixes things?
This is cool, it works now but ONLY when monitor configuration is not changed.
With full explanation: Menus work now if I use xpra with the same display configuration. However, if I attach with only one monitor and then with 2 again, I got the same issues as described in ticket:349#comment:41
The good news: With the latest 0.14 stable it seems to work too.
As per #349, this should be fixed in both latest stable (0.14.19) and 0.15.0 beta. Please close both tickets if this works for you.
Not heard back, closing. Feel free to reopen if you still have issues.
See also: 636#comment:21 (will be included in the next stable update)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/751