Windows 10 Xpra-Python3-x86_64_Setup_2.5-r21648
to Ubuntu 16.04.5
"C:\Program Files\Xpra\xpra_cmd" start ssh://sntentos@172.16.57.121/ --start=gnome-terminal
and then, I tried to open meld
from there.
The xpra connection "immediately closed" on the client; attached is the output from server and client
with --opengl=no
application does start, but has other issues that force me to re-attach to make it working. (maybe clipboard
related?)
Please post the output of the OpenGL_check.exe
tool.
First the client side. From the opengl diagnostics, I see that you're using an Intel chipset, those are known to cause various problems, see wiki/ClientRendering/OpenGL.
I have never seen any drivers reporting the error that you are hitting:
File "E:\Xpra\trunk\src/xpra/client/gl/gl_window_backing_base.py", line 443, in gl_init
This corresponded to:
glTexImage2D(target, 0, self.internal_format, w, h, 0, self.texture_pixel_format, GL_UNSIGNED_BYTE, None)
A workaround was easy enough to implement: r21687, and it shouldn't be too expensive to allocate and throw-away a few megabytes of empty memory - this is only used during initialization or window resizing. That said, it may or may not help.
FWIW: I tried removing a similar empty buffer initialization code in r21691 but that caused errors with the nvidia driver on win32 (and nowhere else!), so r21693 takes the same approach there.
There are new builds uploaded to the beta area.
FWIW: I'm doing the same thing from a windows-7 machine with an nvidia quadro card in it, also connecting to an ubuntu 16.04 system, and I'm not seeing any errors at all, with or without opengl enabled.
I think that these errors may follow window resizing, or window cleanup when the client terminates - possibly caused by a server crash (see below).
So if the fixes above don't help, please post the -d geometry,opengl,metadata
client log of a crash.
maybe clipboard related?
Have you tried disabling the clipboard?
It's also worth trying the python3 builds, just in case.
The server side is even more interesting:
2019-02-18 12:26:23,877 XShmWrapper.setup() shmget(PRIVATE, 18446744073701559216 bytes, 0x3ff) failed, bytes_per_line=131004, width=32751, height=32723 2019-02-18 12:26:23,877 Warning: disabling XShm support following irrecoverable error Xpra: Fatal IO error 11 (Resource temporarily unavailable) on X server :1.
That looks like a hard X11 server crash.
Was the vfb still running or also crashed?
Can you recover the session by re-starting xpra with: xpra start --use-display :1
?
Not sure if it's mentioned anywhere: "assigned" display is :1
Replying to Antoine Martin:
It's also worth trying the python3 builds, just in case.
Win10 already using Python3? Xpra-Python3-x86_64_Setup_2.5-r21648
If you mean the server AKA Ubuntu 16.04, I have no idea how to switch.
I have installed the xpra
package, but there is no xpra3
package (there is python3-xpra
, but no idea how to pull that instead of the py2
)
That looks like a hard X11 server crash.
In my ears, it could be anything related to #2151, #2131, #2099 ... Luckily:
Was the vfb still running or also crashed?
No idea. Of the top of my head:
$ ps aux | grep vfb sntentos 6500 0.0 0.2 373116 141884 ? Ssl 12:06 0:13 Xvfb-for-Xpra-S6482 +extension GLX +extension Composite -screen 0 5760x2560x24+32 -dpi 96 -nolisten tcp -noreset -auth /home/sntentos/.Xauthority -displayfd 5 sntentos 17127 0.0 0.1 339888 109224 ? Ssl 20:48 0:00 Xvfb-for-Xpra-:2 +extension GLX +extension Composite -screen 0 5760x2560x24+32 -dpi 96 -nolisten tcp -noreset -auth /home/sntentos/.Xauthority :2
Can you recover the session by re-starting xpra with:
xpra start --use-display :1
?
Session was recoverable. The image was not complete (a lot of black, in random regions), dragging it around was creating "image breaks/black-ness/almost-transparent regions"* - re-attaching fixed it. Holding on to the screen for diagnostics, if needed.
Not sure if it's mentioned anywhere: "assigned" display is :1
AFAICT, not explicitly. For bug reports, it's easier if you specify the display yourself, then all the steps can be reproduce with a simple cut + paste. Also prevents confusion with multiple sessions / left-overs.
Win10 already using Python3?
Sorry, I had missed that. In this case, try python2 instead.
On ubuntu, you could install python3-xpra
but this only supports servers with the 2.5 beta.
And then you need to run xpra with: python3 /usr/bin/xpra ...
In my ears, it could be anything related to #2151, #2131, #2099 ...
Session was recoverable.
Was it recoverable by just re-attaching xpra or did you have to re-spin the xpra server?
The image was not complete (a lot of black, in random regions), dragging it around was creating "image breaks/black-ness/almost-transparent regions" - re-attaching fixed it. Holding on to the screen for diagnostics, if needed.
Maybe try to run a screen capture like scrot
or xwd
on it and attach it here?
It would be interesting to see if xpra got messed up or if the vfb backing is also in a bit of a state.
I suspect it might be related to OpenGL, but I have no hard evidence
Sounds plausible, you may want to run with virtualgl, not just to get acceleration but also to use a different opengl backend.
Replying to Antoine Martin:
Not sure if it's mentioned anywhere: "assigned" display is :1
AFAICT, not explicitly. For bug reports, it's easier if you specify the display yourself, then all the steps can be reproduce with a simple cut + paste. Also prevents confusion with multiple sessions / left-overs.
I know; the thing is I use a prefab scripts to open things. The bad thing is, I have no idea how to write Windows Terminal scripts that have "some" interaction :/ I don't want to hit the same screen if it's borked in one way or another; I just want a new terminal.
Win10 already using Python3?
Sorry, I had missed that. In this case, try python2 instead.
Administrator operations are a tad more complicated on the laptop. Maybe I should just switch to the zip-clients and forget about the hassle. I'll try to replicate with a py2
build
On ubuntu, you could install
python3-xpra
but this only supports servers with the 2.5 beta. And then you need to run xpra with:python3 /usr/bin/xpra ...
I can try, but then - will the client operate "seamlessly", or would that orchestration require more?
In my ears, it could be anything related to #2151, #2131, #2099 ...
Well, I thought something more serious was happening on #2151 (that borked in some way or another X11), and then the "leftovers" were not handled correctly? idk...
Session was recoverable.
Was it recoverable by just re-attaching xpra or did you have to re-spin the xpra server?
Based on:
/run/user/1000/xpra$ xpra list Found the following xpra sessions: /run/user/1000/xpra: UNKNOWN session at :1 LIVE session at :20 /run/xpra: UNKNOWN session at :1 LIVE session at :20 Re-probing unknown sessions in: /run/xpra, /run/user/1000/xpra UNKNOWN session at :1 (cleaned up) UNKNOWN session at :1 (cleaned up)
I'd say dead. Or idk. I couldn't do xpra attach :1
I just did xpra start --use-display :1
and I got all my windows etc back.
The image was not complete (a lot of black, in random regions), dragging it around was creating "image breaks/black-ness/almost-transparent regions" - re-attaching fixed it. Holding on to the screen for diagnostics, if needed.
Maybe try to run a screen capture like
scrot
orxwd
on it and attach it here? It would be interesting to see if xpra got messed up or if the vfb backing is also in a bit of a state.
All this from "inside" the xpra, or simply a screen capture from the client machine? It seems xpra has "a very good idea" on what things look like. I just need to disconnect and re-attach to correctly display things.
I suspect it might be related to OpenGL, but I have no hard evidence
Sounds plausible, you may want to run with virtualgl, not just to get acceleration but also to use a different opengl backend.
What is the wrapper mentioned here:
You can also ensure that all your client applications are launched using vglrun by using the exec-wrapper option in your configuration file.
I cannot find it in https://xpra.org/manual.
Does that affect shadow
or only --start[-child]=
commands?
And then you need to run xpra with:
python3 /usr/bin/xpra
...I can try, but then - will the client operate "seamlessly", or would that orchestration require more?
If both are installed, you must invoke xpra using python3 /usr/bin/xpra
to use the python3 version.
If only the python3 version is installed, it should just work automagically.
It would be interesting to see if xpra got messed up or if the vfb backing is also in a bit of a state.
All this from "inside" the xpra, or simply a screen capture from the client machine?
I meant directly on the server, without using xpra at all. ie:
DISPLAY=:1 scrot
It seems xpra has "a very good idea" on what things look like. I just need to disconnect and re-attach to correctly display things.
Then the screenshot is probably not necessary. The vfb is fine, it's just xpra's connection to it that dropped, for whatever reason.
You can also ensure that all your client applications are launched using vglrun by using the exec-wrapper option in your configuration file.
I cannot find it in https://xpra.org/manual
oops, fixed: r21709
ie: I do xpra start --exec-wrapper="vglrun -d :1" --start=xterm
Does that affect
shadow
or only--start[-child]=
commands?
Both, but since the display is already started with shadow
, there is nothing to start.
Started with:
Xpra-Client-x86_64_2.5-r21454\xpra_cmd start ssh://user@ip/2 --microphone=off --speaker=off --webcam=no --clipboard=no --start-new-commands=yes --start=gnome-terminal
[.....]
Screen crashed, recovered with xpra start --use-display :2
, and then:
Xpra-Client-x86_64_2.5-r21454\xpra_cmd attach ssh://user@ip/2 --opengl=no
2019-02-23 19:23:15,964 Xpra GTK2 client version 2.5-r21454 64-bit 2019-02-23 19:23:15,969 running on Microsoft Windows 10 2019-02-23 19:23:16,021 Warning: failed to import opencv: 2019-02-23 19:23:16,021 No module named cv2 2019-02-23 19:23:16,022 webcam forwarding is disabled 2019-02-23 19:23:16,507 GStreamer version 1.14.4 for Python 2.7.15 64-bit 2019-02-23 19:23:16,733 keyboard settings: layout=us 2019-02-23 19:23:16,736 desktop size is 1600x900 with 1 screen: 2019-02-23 19:23:16,737 Default (423x238 mm - DPI: 96x96) workarea: 1600x860 2019-02-23 19:23:16,738 DISPLAY1 (309x174 mm - DPI: 131x131) 2019-02-23 19:23:22,733 enabled remote logging 2019-02-23 19:23:22,737 Xpra GTK2 X11 server version 2.5-r21791 64-bit 2019-02-23 19:23:22,740 running on Linux Ubuntu 16.04 xenial 2019-02-23 19:23:22,782 Attached to 172.16.57.121:22 via ssh 2019-02-23 19:23:22,784 (press Control-C to detach) _create_dc_and_bitmap: The parameter is incorrect. 2019-02-23 19:23:22,855 failed to instantiate <class 'xpra.client.gtk2.client_window.ClientWindow'> Traceback (most recent call last): File "./xpra/client/mixins/window_manager.py", line 719, in make_new_window File "./xpra/client/client_window_base.py", line 65, in __init__ File "./xpra/client/gtk_base/gtk_client_window_base.py", line 522, in setup_window File "./xpra/client/client_window_base.py", line 122, in setup_window File "./xpra/client/gtk_base/gtk_client_window_base.py", line 557, in new_backing File "./xpra/client/client_window_base.py", line 105, in new_backing File "./xpra/client/client_widget_base.py", line 51, in make_new_backing File "./xpra/client/gtk2/pixmap_backing.py", line 55, in init File "./xpra/client/gtk2/pixmap_backing.py", line 77, in do_init_new_backing_instance RuntimeError: could not create GdkPixmap object 2019-02-23 19:23:22,870 no more options.. this window will not be shown, sorry C:\Users\stavros.ntentos\Desktop\Xpra-Client-x86_64_2.5-r21454/lib/xpra/clipboard/clipboard_base.py:937: GtkWarning: ../../../gtk+-2.24.32/gdk/win32/gdkselection-win32.c:423: OpenClipboard failed: Access is denied. 2019-02-23 19:23:23,881 sound output using 'opus' audio codec C:\Users\stavros.ntentos\Desktop\Xpra-Client-x86_64_2.5-r21454/lib/xpra/clipboard/clipboard_base.py:795: GtkWarning: gdk_property_change: assertion 'type != GDK_TARGET_STRING' failed 2019-02-23 19:29:00,835 sound output stopping
Initial meld window was not shown, restarting it, it worked nicely.
Also --opengl=no
, generally works okay.
I tried to run:
Xpra-Client-x86_64_2.5-r21454\xpra_cmd start ssh://user@ip/5 --exec-wrapper="vglrun -d :5" --microphone=off --speaker=off --webcam=no --clipboard=no --start-new-commands=yes --start=gnome-terminal
but, it wasn't starting (check the attachment).
Maybe I'll need to do it directly from the server, I can try tomorrow.
_create_dc_and_bitmap: The parameter is incorrect.
(..)RuntimeError: could not create GdkPixmap object
That's a weird one. I have never seen this, but r21868 and r21873 should help if somehow the window ends up with completely messed up dimensions. You may also want to try the python3 builds, those use a different backend when opengl is disabled.
In your log I saw:
2019-02-23 19:29:00,825 Error spawning child '"DBUS_SESSION_BUS_ADDRESS=\"$(cut -f 2- -d= /run/user/1000/dbus-session)\" gnome-screensaver-command -l"':
Not sure what this is meant to do, why not just use start=gnome-screensaver-command -l
?
The server should retrieve the correct dbus session address for the session automatically, even when upgrading or using --use-display
to recover a session.
And finally I think we have the real cause:
Warning: menu forwarding is disabled: cannot load dbus helper: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /tmp/dbus-xvD4Pz9X05: Connection refused
Then later:
2019-02-23 18:49:50,962 _read_initial_X11_properties() Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/x11/models/core.py", line 383, in _read_initial_X11_properties handler(self) File "/usr/lib/python2.7/dist-packages/xpra/x11/models/base.py", line 483, in _handle_gtk_app_menu_change query_actions(bus_name, app_path, app_actions_cb, app_actions_err) NameError: global name 'query_actions' is not defined
I have no idea how it is possible for the code to end up trying to parse the menu stuff if it failed to load the menu forwarding components, but it did. So r21870 will use a different check so it never ends up calling the undefined function. r21871 will also trap all errors during the initial window setup.
I think that this could explain everything: it left the window in a half-initialized state, and its dimensions were completely random and invalid. The fix is server-side, but you can also try running the server with:
XPRA_MENU_FORWARDING=0 xpra start ...
This should make the problems go away.
In fact, this whole menu mess may be going away soon: #2163.
Replying to Antoine Martin:
_create_dc_and_bitmap: The parameter is incorrect.
(..)RuntimeError: could not create GdkPixmap object
That's a weird one. I have never seen this, but r21868 and r21873 should help if somehow the window ends up with completely messed up dimensions. You may also want to try the python3 builds, those use a different backend when opengl is disabled.
Thank you, I will update server/client as soon as betas roll out
In your log I saw:
2019-02-23 19:29:00,825 Error spawning child '"DBUS_SESSION_BUS_ADDRESS=\"$(cut -f 2- -d= /run/user/1000/dbus-session)\" gnome-screensaver-command -l"':
Not sure what this is meant to do, why not just use
start=gnome-screensaver-command -l
? The server should retrieve the correct dbus session address for the session automatically, even when upgrading or using--use-display
to recover a session.
I have had a two-pronged issue:
−−start−on−last−client−exit
was working (neither could I come up with a testing solution)
xpra start ssh:/// gnome-terminal
locked "that screen" instead of :0
. Setting DISPLAY
didn't help either. Since I couldn't verify [1], I didn't know if e.g. the command run, failed to run, executed a "side-effect" etc.
So r21870 will use a different check so it never ends up calling the undefined function. r21871 will also trap all errors during the initial window setup.
Thank you for the fix. I will test, however, when builds roll out. xpra
is my windows window to the server, when server is unavailable.
Since I cannot do that from the client, testing is (usually) hard. (and there are workarounds e.g. --opengl=no
)
Thank you, I will update server/client as soon as betas roll out
Updated beta builds were posted earlier today.
Replying to Antoine Martin:
Thank you, I will update server/client as soon as betas roll out
Updated beta builds were posted earlier today.
I don't see something here https://xpra.org/beta/xenial/main/binary-amd64/?P=*r218*
I haven't asked apt-get
yet, but the only r218XX I see is the r21828
I haven't asked apt-get yet, but the only r218XX I see is the r21828
Ah, right. Ubuntu Xenial builds had been broken since r21739 (cython minimum version requirements), r21879 fixes that.
The opengl fix from comment:3 was causing a regression with normally well behaved drivers: #2194, so this has been reverted in r21981. This looks like a garbage collection issue, maybe we need to keep a reference to the empty buffer until we're certain pyopengl has uploaded it?
As per the documentation glTexImage2d and Null data: GL still validates the pair of format and type but we do supply valid values for those: self.texture_pixel_format, GL_UNSIGNED_BYTE
.
So I think that the driver error is bogus and I'm not going to try to fix it.
Can I close this ticket? meld works for me.
Replying to Antoine Martin:
As per the documentation glTexImage2d and Null data: GL still validates the pair of format and type but we do supply valid values for those:
self.texture_pixel_format, GL_UNSIGNED_BYTE
. So I think that the driver error is bogus and I'm not going to try to fix it.Can I close this ticket? meld works for me.
Well, if it is Intel shenanigans, then I guess I'll just stop using OpenGL on the Intel driver at all. You may go ahead and close.
Would using vlgrun
have a chance to alleviate this problem?
vglrun is used on the server side for sharing GPU acceleration with multiple contexts, it doesn't help with the client.
meld seems to be working now (r25468):
"Xpra-Python3-x86_64_4.0-r25468\xpra_cmd" start ssh://user@ip/20 --ssh="plink -ssh -agent" --microphone=off --speaker=off --webcam=no --pulseaudio=no --start-new-commands=yes --start=gnome-terminal 2020-03-03 23:08:18,528 Xpra GTK3 client version 4.0-r25468 64-bit 2020-03-03 23:08:18,530 running on Microsoft Windows 10 2020-03-03 23:08:19,429 GStreamer version 1.16.2 for Python 3.8.2 64-bit 2020-03-03 23:08:19,662 keyboard layout code 0x409 2020-03-03 23:08:19,663 identified as 'United States - English' : us 2020-03-03 23:08:19,794 OpenGL_accelerate module loaded 2020-03-03 23:08:19,833 Using accelerated ArrayDatatype 2020-03-03 23:08:20,474 Warning: vendor 'Intel' is greylisted, 2020-03-03 23:08:20,475 you may want to turn off OpenGL if you encounter bugs 2020-03-03 23:08:21,361 OpenGL enabled with Intel(R) HD Graphics 4000 2020-03-03 23:08:21,533 keyboard settings: layout=us 2020-03-03 23:08:21,537 desktop size is 1600x900 with 1 screen: 2020-03-03 23:08:21,538 Default (423x238 mm - DPI: 96x96) workarea: 1600x860 2020-03-03 23:08:21,539 (Standard monitor types) Generic PnP Monitor (309x174 mm - DPI: 131x131) 2020-03-03 23:08:31,358 enabled remote logging 2020-03-03 23:08:31,361 Xpra GTK3 X11 server version 3.0.6-r25174 64-bit 2020-03-03 23:08:31,362 running on Linux Ubuntu 16.04 xenial (xpra_cmd:9920): Pango-WARNING **: 23:08:32.142: couldn't load font "Bitstream Vera Sans Not-Rotated 14.662109375", falling back to "Sans Not-Rotated 14.662109375", expect ugly output. 2020-03-03 23:08:54,176 UI thread is now blocked 2020-03-03 23:08:54,505 UI thread is running again, resuming P
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2153