I am trying to run server's virtual X at 4K and the client's in Full HD or lower. Everything works allright (thanks to Antoine for useful inputs) except only 1/4 of the client screen refreshes, leaving 3/4 from the previous screen.
However if I manually switch to and fro from the workspace (pager) running the client xpra instance, it gets refreshed.
The environemnt is Ubuntu v14.04.3 which reportedly does not work with Xdummy, so Xvbf is used without OpenGL/VirutalGL. Xpra is at v0.16.0-1beta.
The steps to reproduce are:
SERVERSIDE:
Xvfb :10 -screen 0 3840x2160x24+32 -fbdir /var/tmp & XPRA_RANDR=0 xpra start --use-display :10 --sync-xvfb=50 --bind-tcp=localhost:10000 & export DISPLAY=:10 libreoffice &
CLIENTSIDE:
xpra attach tcp:localhost:10000:10 --desktop-scaling=0.5 --opengl=no --encoding=jpeg --quality=85 -z9
Please find attached screenshot of the refreshed window.
Cheers, /z
Please find screenshots at
BEFORE: http://picpaste.com/DSCTtlg9.png AFTER: http://picpaste.com/cVbgGQty.png
(also editing the ticket description)
Here is the (long) original thread which came before this ticket: http://lists.devloop.org.uk/pipermail/shifter-users/2015-November/001399.html.
FYI: this should be equivalent to the commands you used and both easier to understand and harder to get wrong:
XPRA_RANDR=0 xpra start \ --xvfb="Xvfb :99 -screen 0 3840x2160x24+32 -fbdir /var/tmp" \ --sync-xvfb=50 --bind-tcp=127.0.0.1:10000 \ --start=libreoffice
Why libreoffice? I test with an xterm which is a LOT easier to handle.
Then there's this:
opengl=no
- why? (part of the problem)
encoding=jpeg
- why?
quality=85
- why?
z9
- why? (a very bad idea it is too)
I eventually found a bug, caused by the changes in #976, which only occurs with opengl disabled and with downscaling (desktop-scaling<1.0), fixed in r11288.
You can find beta packages for Ubuntu Trusty here: http://xpra.org/beta/trusty/.
@zenny: please close if this ticket if that works for you.
Let me first answer some of your 'why' questions.
Why libreoffice?
Because Libreoffice (or her proprietary sisters) is what most of the people use for presentation, I assume.
Why --opengl=no? Because Xvfb does not support opengl, thus producing black screen. Xdummy supports openGL, but, as you too have confirmed after testing, does not work with Ubuntu trusty.
Why --encoding=jpeg --quality=85? That appeared to be fastest in my case. I am open to any suggestion.
UPDATE:
§1 Upgraded to the latest debian binary from 2015-11-18 (source: http://xpra.org/beta/trusty/)
§2 Thanks for the aggregated command. Used that. Everything went fine, except capture of the vitual X server.
§3 while capturing, ffmpeg cannot connect to with an error " [x11grab @ 0x2809c00] Cannot open display :99, error 1.\n :99: Input/output error".
CAVEAT:
The capture was working fine earlier, but not the display refreshment of the client. Now the display refreshes fine, but capture does not work.
On top of that, new bugs popped up as detailed below at ticket:1036#comment:9.
ANOTHER UPDATE:
I tried to start virutal X server and xpra with different commands (not the aggregated one as Antoine suggested) like I reported earlier, in that case, the capture works, but the display in captured size is 4K, but the content from libreoffice is same as the display size-FullHD (1/4th of the captured screen).
Used this comamnd to capture:
$ ffmpeg -f x11grab -s 3840x2160 -i :99 -r 24 -deadline realtime -b:v 1M -threads 5 -qmin 0 -qmax 50 -crf 5 -preset ultrafast -f matroska 4k_xpra.mkv
Because Libreoffice (or her proprietary sisters) is what most of the people use for presentation, I assume.
libreoffice is huge, keep it simple when trying to test for bugs. This limits the bug's scope and makes it much easier to reproduce. (ie: in this case, it makes no difference)
Why --opengl=no?
Because Xvfb does not support opengl, thus producing black screen. Xdummy supports openGL, but, as you too have tested yourself, does not work with Ubuntu trusty.
Wrong. You are getting confused between:
Ideally, you want both. You cannot use the first one on Ubuntu, but why disable the other?
Why --encoding=jpeg --quality=85?
That appeared to be fastest in my case. I am open to any suggestion.
See wiki/Encodings.
while capturing, ffmpeg cannot connect to with an error " [x11grab @ 0x2809c00] Cannot open display :99, error 1.\n :99: Input/output error".
Are you sure that display :99 exists? (please include the ffmpeg command next time)
You cannot use the first one on Ubuntu, but why disable the other?
Because without disabling opengl in the client, the screen goes black, when opengl is disabled I can see the contents on the screen.
See wiki/Encodings.
I read that many a times, and found by experimenting jpeg with 85% quality appeared to be fastest. But there is no data to support it, sorry.
Are you sure that display :99 exists? (please include the ffmpeg command next time)
If I used the aggregated command that you proposed, it should exist. Shan't it? Please find ffmpeg command once again:
$ ffmpeg -f x11grab -s 3840x2160 -i :99 -r 24 -deadline realtime -b:v 1M -threads 5 -qmin 0 -qmax 50 -crf 5 -preset ultrafast -f matroska 4k_xpra.mkv
And the screenshot from capture with separate commands (as I have noted under ANOTHER UPDATE in my previous post) is at http://picpaste.com/1KzLKgzD.jpg
Thanks!
Because without disabling opengl in the client, the screen goes black, when opengl is disabled I can see the contents on the screen.
Please post the opengl debug information, as per wiki/ClientRendering/OpenGL (the gl_check output)
... quality appeared to be fastest
Quality and speed are different things.
I'm not sure which one matters most to you, or which type of connection you are using, but jpeg is unlikely to be the best option either way.
If I used the aggregated command that you proposed, it should exist. Shan't it? Please find ffmpeg command once again:
If you use the display :10
then you should tell ffmpeg to use the same display.
If you use the display :10 then you should tell ffmpeg to use the same display.
Throughout this, I am using display :99, fyi.
And here comes the output from gl_check.py.
$ python gl_check.py PyOpenGL warning: missing accelerate module PyOpenGL warning: missing array format handlers: numeric, vbo, vbooffset OpenGL Version: 3.0 Mesa 10.1.3 OpenGL properties: * GLU extensions : GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess * GLU version : 1.3 * display_mode : ALPHA, SINGLE * gdkgl.version : 1.4 * gdkglext.version : 1.2.0 * gtkglext.version : 1.2.0 * has_alpha : True * max-viewport-dims : (16384, 16384) * opengl : 3.0 * pygdkglext.version : 1.1.0 * pyopengl : 3.0.2 * renderer : Gallium 0.4 on AMD CAICOS * rgba : True * safe : True * shading language version : 1.30 * texture-size-limit : 16384 * transparency : True * vendor : X.Org * zerocopy : False
AN UPDATE:
With the aggregated command (with no changes, but verbatim) you proposed earlier
XPRA_RANDR=0 xpra start \ --xvfb="Xvfb :99 -screen 0 3840x2160x24+32 -fbdir /var/tmp" \ --sync-xvfb=50 --bind-tcp=127.0.0.1:10000 \ --start=libreoffice
To my surprise, starts an virtual xserver at :2 instead of :99! Hmmm!
$ xpra list Found the following xpra sessions: /home/zenny/.xpra: LIVE session at :2
When I connected to :2 as a client, both xpra server and client died when I tried to play with the running libroffice with the following message on the console:
2015-11-18 19:39:15,908 Attached to tcp:localhost:10000:2 (press Control-C to detach) /usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed import gobject._gobject 2015-11-18 19:39:27,750 internal error: read connection tcp socket: 127.0.0.1:59855 <- 127.0.0.1:10000 reset 2015-11-18 19:39:27,750 [Errno 104] Connection reset by peer 2015-11-18 19:39:27,751 Connection lost
This crashing bug seems to have been introduced after upgrading to the newer version of xpra released 2015-11-18, it seems. Else, previous beta was very stable. I am repeatedly getting it no matter how I start xservers (directly or using xpra -xvfb option).
Re-run the same aggregated command, and the servers started in :3, but xpra client didn't bring up anything upon connection.
After reading wiki/Debugging, I tried to debug both ways (directly running xpra with gdb as well as running gdb with the xpra PID).
The outcomes are:
§1 The serverside gdb is at http://hastebin.com/iquviqidub.vhdl
The above simply prints 'no stack'.
§2 The clientside gdb is at http://hastebin.com/vuhumesofo.vhdl
The §2 above categorically shows via 'xpra list' command that the aggregated command starts 3 xvfb instances (:2 :3 and :99) and finally gets autokilled and runs only in :2 even when the --xvfb flag categorically asked to start the virtual server on :99. This is done a cold-booted machine so there is no chance of having any instance of xpra running from yesterday.
This is very new issue introduced with latest Beta build as of 2015-11-18.
Is there a way to get the beta build before the 2015-11-18 release for trusty? I cannot find any at http://xpra.org/beta/trusty/main/binary-amd64/''
UPDATE:
Going back to square one as the aggregated command is not doing what it should or say overriding the parameters specified on its own (Ref: comment:10). It seems xpra tries to autodetect running x instances and tries to start xpra server on the next one, I guess. Maybe I am wrong.
Therefore, I tried with the separate commands I used to and it does what the commands (below) are supposed to do:
On server:
$ Xvfb :99 -screen 0 3840x2160x24+32 -fbdir /var/tmp $ SCALING_HARDCODED=1/2 XPRA_RANDR=0 xpra start --use-display :99 --sync-xvfb=50 --bind-tcp=localhost:10000 $ export DISPLAY=:99 $ libreoffice
On Client:
$ xpra attach tcp:localhost:10000:99 --desktop-scaling=0.5 --sync-xvfb=50 --opengl=no
Thus, the capture in 4K works except the captured content covers only 1/4th of the 4K screencapture (the xpra client screen is FullHD). See http://picpaste.com/IgV8eLMl.jpg.
Also tried WITHOUT
--desktop-scaling
option, but with the same results.
... To my surprise, starts an virtual xserver at :2 instead of :99! Hmmm!
Maybe another Ubuntu oddity. Works absolutely fine here.
As for the gdb backtrace, the command line used was wrong and there was nothing running:
/usr/bin/python: can't open file 'XPRA_RANDR=0': [Errno 2] No such file or directory
And it wasn't a crash but a simple process exit:
Entering daemon mode; any further errors will be reported to: /home/zenny/.xpra/S5551.log
If this daemon process does crash, you need to attach to it after it daemonizes, or use --no-daemon
to prevent the fork.
Then the other "trace" has this: Could not attach to process.
, so you won't be getting any useful information from that either.
FWIW: it's extremely unlikely that they both crash, if one does crash then the other will just disconnect and tell you that. (logs missing)
There is a mistake in that command I gave in comment:3 in that it only allows you to start one display (hardcoded to :99. The more proper command would be:
XPRA_RANDR=0 xpra start \ --xvfb="Xvfb -screen 0 3840x2160x24+32 -fbdir /var/tmp" \ --sync-xvfb=50 --bind-tcp=127.0.0.1:10000 \ --start=xterm
Which allows you:
xpra start :99 --xvfb=...
Thus, the capture in 4K works except the captured content covers only 1/4th of the 4K screencapture
You're not including the server log but it looks to me like the server did resize the virtual screen, or that the client is not using desktop scaling, or both. I bet there is some very useful information in the server log or client output.
Is there a way to get the beta build before the 2015-11-18 release for trusty?
No, and I'm not even convinced we should be making final 0.16 builds for Ubuntu Trusty, which is just too old, lacks ffmpeg / avcodec2 decoding, and has various bugs (the opengl issue you are seeing with AMD being just the latest one).
The original plan was to keep older distros like Trusty and centos 5.x with the 0.14.x branch until it gets retired.
You're not including the server log but it looks to me like the server did resize the virtual screen, or that the client is not using desktop scaling, or both. I bet there is some very useful information in the server log or client output.
Fyi, The console output from the xpra client: http://hastebin.com/otukureqos.coffee
The server log is posted at http://hastebin.com/necawobowa.vhdl
As you have suggested at comment:12, the new aggregated command works well with:
$ XPRA_RANDR=0 xpra start :99 \ > --xvfb="Xvfb -screen 0 3840x2160x24+32 -fbdir /var/tmp" \ > --sync-xvfb=50 --bind-tcp=127.0.0.1:10000 \ > --start=libreoffice
CLIENTSIDE:
xpra attach tcp:localhost:10000:99 --opengl=no
However the 4k capture of the virtual server produces with 1/4th of the capture area as earlier.
You're not including the server log but it looks to me like the server did resize the virtual screen, or that the client is not using desktop scaling, or both. I bet there is some very useful information in the server log or client output.
The relevant Xpra log is pasted at: http://hastebin.com/welewuhile.vbs, and
Console output at client is pasted at: http://hastebin.com/boyuxobifu.coffee, fyi.
Thanks!
no need for scaling with mmap setting scaling to 100%: sending updated screen size to server: 1920x1080 with 1 screens
Disable mmap. sync-xvfb
is a server switch, it does nothing on the client.
And I can't look at the rest:
# ping hastebin.com ping: unknown host hastebin.com
Looks we're going to have dead links to remove from the tracker :(
The paste domain is back online and I was able to see in the server log (which should have been shown in the client log too): do_paint_rgb32 error: GLError
glTexParameteri
- looks just like #1024 (also on Ubuntu..)
Means opengl client rendering is really not stable on that OS.
BTW, as of r11291, mmap will only cause desktop-scaling to be disabled if it was set to "auto", not if a specific scaling value was specified on the command line.
Means opengl client rendering is really not stable on that OS.
Which distro or OS do you use btw? So that I can experiment with the same in a KVM instance.
BTW, as of r11291, mmap will only cause desktop-scaling to be disabled if it was set to "auto", not if a specific scaling value was specified on the command line.
Even after appending '--no-mmap' option to 'xpra start', the capture status remained the same. :(
Command used:
$ XPRA_RANDR=0 xpra start :99 --xvfb="Xvfb -screen 0 3840x2160x24+32 -fbdir /var/tmp" --sync-xvfb=50 --bind-tcp=127.0.0.1:10000 --start=libreoffice --no-mmap
Server Log:
$ cat ~/.xpra/:99.log Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension Present Initializing built-in extension DRI3 Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 6 XSELINUXs still allocated at reset SCREEN: 0 objects of 264 bytes = 0 total bytes 0 private allocs DEVICE: 0 objects of 96 bytes = 0 total bytes 0 private allocs CLIENT: 0 objects of 144 bytes = 0 total bytes 0 private allocs WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs PIXMAP: 1 objects of 16 bytes = 16 total bytes 0 private allocs GC: 4 objects of 16 bytes = 64 total bytes 0 private allocs CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs TOTAL: 6 objects, 88 bytes, 0 allocs 1 PIXMAPs still allocated at reset PIXMAP: 1 objects of 16 bytes = 16 total bytes 0 private allocs GC: 4 objects of 16 bytes = 64 total bytes 0 private allocs CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs TOTAL: 6 objects, 88 bytes, 0 allocs 4 GCs still allocated at reset GC: 4 objects of 16 bytes = 64 total bytes 0 private allocs CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs TOTAL: 5 objects, 72 bytes, 0 allocs 1 CURSORs still allocated at reset CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs TOTAL: 1 objects, 8 bytes, 0 allocs 1 CURSOR_BITSs still allocated at reset TOTAL: 0 objects, 0 bytes, 0 allocs [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! Xlib: extension "RANDR" missing on display ":99". Xlib: extension "RANDR" missing on display ":99". [33m2015-11-19 14:53:32,869 Warning: libvpx ABI version 5 is too old:[0m [33m2015-11-19 14:53:32,869 disabling YUV444P support with VP9[0m [33m2015-11-19 14:53:32,934 Warning: swscale version 2.1.1 is too old:[0m [33m2015-11-19 14:53:32,935 disabling YUV422P to RGB, BGR, BGRX[0m [33m2015-11-19 14:53:32,938 Warning: no X11 RandR support on :99[0m /usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed import gobject._gobject Xlib: extension "RANDR" missing on display ":99". 2015-11-19 14:53:34,357 pulseaudio server started with pid 24038[0m [33m2015-11-19 14:53:34,359 Warning: cannot forward notifications, the interface is already claimed[0m [33m2015-11-19 14:53:34,359 if you do not have a dedicated dbus session for this xpra instance,[0m [33m2015-11-19 14:53:34,359 use the 'notifications=no' option[0m E: [pulseaudio] pid.c: Daemon already running. 2015-11-19 14:53:34,385 xpra X11 version 0.16.0-r11289[0m 2015-11-19 14:53:34,385 running with pid 23991 on Linux Ubuntu 14.04 trusty[0m 2015-11-19 14:53:34,385 on display :99[0m Xlib: extension "XINERAMA" missing on display ":99". [33m2015-11-19 14:53:34,429 failed to connect to avahi's dbus interface: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Avahi was not provided by any .service files[0m [33m2015-11-19 14:53:34,429 you may want to disable mdns support to avoid this warning[0m [33m2015-11-19 14:53:34,429 failed to connect to avahi's dbus interface: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Avahi was not provided by any .service files[0m [33m2015-11-19 14:53:34,429 you may want to disable mdns support to avoid this warning[0m 2015-11-19 14:53:34,430 xpra is ready.[0m Xlib: extension "RANDR" missing on display ":99". [33m2015-11-19 14:53:35,387 Warning: pulseaudio has terminated shortly after startup.[0m [33m2015-11-19 14:53:35,387 pulseaudio is limited to a single instance per user account,[0m [33m2015-11-19 14:53:35,387 and one may be running already for user 'zenny'[0m [33m2015-11-19 14:53:35,388 to avoid this warning, either fix the pulseaudio command line[0m [33m2015-11-19 14:53:35,388 or use the 'pulseaudio=no' option[0m 2015-11-19 14:53:41,103 New unix-domain connection received on /home/zenny/.xpra/MACHINE-GA-970A-D3-99[0m 2015-11-19 14:53:41,107 Connection lost[0m 2015-11-19 14:54:09,302 New tcp connection received from 127.0.0.1:48911[0m 2015-11-19 14:54:09,690 Handshake complete; enabling connection[0m 2015-11-19 14:54:09,701 Python/Gtk2 Linux Ubuntu 14.04 trusty client version 0.16.0-r11289[0m 2015-11-19 14:54:09,701 connected from 'MACHINE-GA-970A-D3' as 'zenny'[0m 2015-11-19 14:54:09,702 using vp9 as primary encoding also available:[0m 2015-11-19 14:54:09,702 vp8, png, png/P, png/L, webp, rgb24, jpeg, rgb32[0m 2015-11-19 14:54:09,702 client root window size is 1920x1080 with 1 display:[0m 2015-11-19 14:54:09,703 :0.0 (508x285 mm - DPI: 96x96)[0m 2015-11-19 14:54:09,703 HDMI-0 (598x336 mm - DPI: 81x81)[0m 2015-11-19 14:54:09,723 setting key repeat rate from client: 660ms delay / 40ms interval[0m 2015-11-19 14:54:09,729 setting keymap: rules=evdev, model=evdev, layout=se[0m The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server [33m2015-11-19 14:54:10,015 Warning: cannot start speaker forwarding:[0m [33m2015-11-19 14:54:10,015 user and server environment are identical,[0m [33m2015-11-19 14:54:10,015 this would create a sound loop[0m [33m2015-11-19 14:54:10,015 use XPRA_ALLOW_SOUND_LOOP=1 to force enable it[0m avahi_client_new failed.
xpra Client console output:
$ xpra attach tcp:localhost:10000:99 --opengl=no 2015-11-19 14:54:05,897 Xpra gtk2 client version 0.16.0-r11289 2015-11-19 14:54:05,902 running on Linux Ubuntu 14.04 trusty /usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed import gobject._gobject 2015-11-19 14:54:06,145 Warning: swscale version 2.1.1 is too old: 2015-11-19 14:54:06,145 disabling YUV422P to RGB, BGR, BGRX 2015-11-19 14:54:06,159 Warning: libvpx ABI version 5 is too old: 2015-11-19 14:54:06,159 disabling YUV444P support with VP9 2015-11-19 14:54:09,316 detected keyboard: rules=evdev, model=evdev, layout=se 2015-11-19 14:54:09,318 desktop size is 1920x1080 with 1 screen: 2015-11-19 14:54:09,318 :0.0 (508x285 mm - DPI: 96x96) 2015-11-19 14:54:09,318 HDMI-0 (598x336 mm - DPI: 81x81) 2015-11-19 14:54:09,770 Xpra X11 server version 0.16.0-r11289 2015-11-19 14:54:09,770 running on Linux Ubuntu 14.04 trusty 2015-11-19 14:54:09,784 Attached to tcp:localhost:10000:99 (press Control-C to detach) /usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed import gobject._gobject
Which distro or OS do you use btw? So that I can experiment with the same in a KVM instance.
I use Fedora 23, which is much more up to date is the distribution most tested during development.
xpra attach tcp:localhost:10000:99 --opengl=no
You seem to have dropped the desktop-scaling=0.5
from the client's command line in the last few comments, this would explain why the server is rendering at 1080p..
You seem to have dropped the desktop-scaling=0.5 from the client's command line in the last few comments, this would explain why it is rendering at 1080p..
Yay! That is the reason. Thanks Antoine for your help, and this capture issue is solved! :D
FYI:
XPRA_RANDR
has been replaced by --resize-display=no
in trunk: r11468
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1036