Xpra: Ticket #1036: 1/4 of the Client Screen Refreshing

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



Wed, 18 Nov 2015 07:48:43 GMT - zenny: cc set

Please find screenshots at

BEFORE: http://picpaste.com/DSCTtlg9.png AFTER: http://picpaste.com/cVbgGQty.png


Wed, 18 Nov 2015 16:17:09 GMT - Antoine Martin: owner, description changed

(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:

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.


Wed, 18 Nov 2015 17:15:28 GMT - zenny:

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

Wed, 18 Nov 2015 17:29:22 GMT - Antoine Martin:

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)


Wed, 18 Nov 2015 17:45:18 GMT - zenny:

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!


Wed, 18 Nov 2015 17:51:36 GMT - Antoine Martin:

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.


Wed, 18 Nov 2015 18:01:00 GMT - zenny:

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

Wed, 18 Nov 2015 18:38:39 GMT - zenny:

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.


Thu, 19 Nov 2015 08:05:41 GMT - zenny:

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/''


Thu, 19 Nov 2015 10:20:12 GMT - zenny:

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.


Thu, 19 Nov 2015 10:50:22 GMT - Antoine Martin:

... 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:


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.


Thu, 19 Nov 2015 11:50:31 GMT - zenny:

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


Thu, 19 Nov 2015 12:04:02 GMT - zenny:

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!


Thu, 19 Nov 2015 12:16:41 GMT - Antoine Martin:

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 :(


Thu, 19 Nov 2015 12:37:02 GMT - Antoine Martin:

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.


Thu, 19 Nov 2015 13:08:11 GMT - Antoine Martin:

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.


Thu, 19 Nov 2015 14:07:25 GMT - zenny:


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

Thu, 19 Nov 2015 14:43:13 GMT - Antoine Martin:

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..


Thu, 19 Nov 2015 15:07:36 GMT - zenny: status changed; resolution set


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


Tue, 22 Dec 2015 15:43:49 GMT - Antoine Martin:

FYI:


Sat, 23 Jan 2021 05:13:09 GMT - migration script:

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