xpra v4.0-r25252 on Debian testing/bullseye
The client window is displayed with too large fonts. Looking at the xpra output, I found that xpra server is setting another dpi value than I set in the xpra command (141x141 dpi vs. 96x96 dpi). I set the same -dpi / --dpi value in xpra server, xpra client and Xvfb command. There is no scaling involved.
I don't understand why xpra assumes 141x141 dpi. Expected behaviour: xpra should regard the dpi value given by option --dpi.
Xpra server log:
2020-02-23 19:41:30,371 6.7GB of system memory 2020-02-23 19:41:30,426 xpra is ready. 2020-02-23 19:41:30,431 xpra GTK3 X11 version 4.0-r25252 64-bit 2020-02-23 19:41:30,870 uid=1000 (lauscher), gid=1000 (lauscher) 2020-02-23 19:41:30,871 running with pid 449252 on Linux Debian testing bullseye 2020-02-23 19:41:30,872 connected to X11 display :115 with 24 bit colors 2020-02-23 19:41:31,980 New unix-domain connection received 2020-02-23 19:41:31,981 on '/home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/buster-115' 2020-02-23 19:41:31,989 Handshake complete; enabling connection 2020-02-23 19:41:32,018 mmap is enabled using 256MB area in /run/user/1000/xpra/xpra.m0dbgmug.mmap 2020-02-23 19:41:32,021 Python/GTK3 Linux Debian testing bullseye x11 client version 4.0-r25252 64-bit 2020-02-23 19:41:32,021 OpenGL is disabled 2020-02-23 19:41:32,022 connected from 'buster' as 'lauscher' - 'Lauscher' 2020-02-23 19:41:32,031 setting key repeat rate from client: 500ms delay / 37ms interval 2020-02-23 19:41:32,034 setting keymap: 2020-02-23 19:41:32,092 setting keyboard layout to 'de' 2020-02-23 19:41:32,285 client root window size is 1920x1080 with 1 display: 2020-02-23 19:41:32,286 :0.0 (508x285 mm - DPI: 96x96) workarea: 1870x1045 at 50x35 2020-02-23 19:41:32,286 BOE eDP (344x193 mm - DPI: 141x142) 2020-02-23 19:41:32,288 cannot find a temporary resolution for Xinerama workaround! 2020-02-23 19:41:32,295 server virtual display now set to 1920x1080 2020-02-23 19:41:32,302 automatic picture encoding enabled, also available: 2020-02-23 19:41:32,302 rgb24, rgb32 2020-02-23 19:41:32,313 client 1 @02.568 Xpra GTK3 X11 server version 4.0-r25252 64-bit 2020-02-23 19:41:32,313 client 1 @02.569 running on Linux Debian testing bullseye 2020-02-23 19:41:32,315 DPI set to 192 x 192 2020-02-23 19:41:32,320 client 1 @02.573 Attached to socket:///home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/buster-115 2020-02-23 19:41:32,321 client 1 @02.573 (press Control-C to detach) 2020-02-23 19:41:32,422 client 1 @02.675 server does not support xi input devices 2020-02-23 19:41:32,422 client 1 @02.675 server uses: xtest 2020-02-23 19:41:32,664 New unix-domain connection received 2020-02-23 19:41:32,665 on '/home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/buster-115' 2020-02-23 19:41:33,256 client 1 @03.512 Xpra OpenGL Acceleration Failure 2020-02-23 19:41:33,257 client 1 @03.513 invalid literal for int() with base 10: '5 (Compatibility Profile) Mesa 19'
Xpra client log:
x11docker [19:41:28,551]: Starting Xpra client 2020-02-23 19:41:29,741 Xpra GTK3 X11 client version 4.0-r25252 64-bit 2020-02-23 19:41:30,054 running on Linux Debian testing bullseye 2020-02-23 19:41:30,055 window manager is 'Xfwm4' 2020-02-23 19:41:30,285 No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate' 2020-02-23 19:41:31,252 Error loading OpenGL support: 2020-02-23 19:41:31,253 invalid literal for int() with base 10: '5 (Compatibility Profile) Mesa 19' 2020-02-23 19:41:31,667 keyboard settings: rules=evdev, model=pc105, layout=de 2020-02-23 19:41:31,677 desktop size is 1920x1080 with 1 screen: 2020-02-23 19:41:31,678 :0.0 (508x285 mm - DPI: 96x96) workarea: 1870x1045 at 50x35 2020-02-23 19:41:31,678 BOE eDP (344x193 mm - DPI: 141x142) 2020-02-23 19:41:32,308 enabled fast mmap transfers using 256MB shared memory area 2020-02-23 19:41:32,309 enabled remote logging 2020-02-23 19:41:32,311 Xpra GTK3 X11 server version 4.0-r25252 64-bit 2020-02-23 19:41:32,312 running on Linux Debian testing bullseye 2020-02-23 19:41:32,315 Attached to socket:///home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/buster-115 2020-02-23 19:41:32,316 (press Control-C to detach) 2020-02-23 19:41:32,417 server does not support xi input devices 2020-02-23 19:41:32,418 server uses: xtest 2020-02-23 19:41:33,255 Xpra OpenGL Acceleration Failure 2020-02-23 19:41:33,256 invalid literal for int() with base 10: '5 (Compatibility Profile) Mesa 19'
Xpra server command:
xpra start :115 --use-display \ --csc-modules=none \ --clipboard-direction=both \ --encodings=rgb \ --microphone=no \ --notifications=no \ --pulseaudio=no \ --socket-dirs='/home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554' \ --speaker=no \ --start-via-proxy=no \ --system-tray=yes \ --video-decoders=none \ --video-encoders=none \ --webcam=no \ --xsettings=no \ --dpi='96' \ --clipboard=yes \ --dbus-proxy=no \ --daemon=no \ --fake-xinerama=no \ --file-transfer=off \ --html=off \ --opengl=noprobe \ --mdns=no \ --printing=no \ --session-name='wine-pcmanfm' \ --start-new-commands=no \ --systemd-run=no
Xpra client command:
xpra attach :115 \ --csc-modules=none \ --clipboard-direction=both \ --encodings=rgb \ --microphone=no \ --notifications=no \ --pulseaudio=no \ --socket-dirs='/home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554' \ --speaker=no \ --start-via-proxy=no \ --system-tray=yes \ --video-decoders=none \ --video-encoders=none \ --webcam=no \ --xsettings=no \ --dpi='96' \ --clipboard=no \ --compress=0 \ --modal-windows=no \ --opengl=auto \ --quality=100 \ --dpi='96' \ --title='@title@ [in container]'
X server command:
/usr/bin/Xvfb :115 \ -retro \ +extension RANDR \ +extension RENDER \ +extension GLX \ +extension XVideo \ +extension DOUBLE-BUFFER \ +extension SECURITY \ +extension DAMAGE \ +extension X-Resource \ -extension XINERAMA -xinerama \ -extension MIT-SHM \ +extension Composite +extension COMPOSITE \ +extension XTEST \ -dpms \ -s off \ -auth /home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/Xauthority.server \ -nolisten tcp \ -dpi 96 \ -screen 0 1920x1080x24
I don't understand why xpra assumes 141x141 dpi.
I see nothing in your output to show that xpra is using this DPI value. If you are referring to this line:
BOE eDP (344x193 mm - DPI: 141x142)
Then that's just xpra printing the geometry if your client display.
To get more information on DPI and screen settings, run your server with -d screen
.
Apart from the virtual "physical" screen geometry set by the server, there is also this value which is honoured by most applications:
$ xrdb -q | grep -i dpi
More information here: wiki/DPI.
There is another DPI line in the log above, and the one below, too (I've missed it before):
2020-02-23 19:41:32,315 DPI set to 192 x 192
It is exactly twice the value I set with --dpi 96
.
Then that's just xpra printing the geometry if your client display.
The client has 96x96 dpi:
$ xdpyinfo | grep dots resolution: 96x96 dots per inch
xrdb gives a wrong result:
$ xrdb -q | grep -i dpi Xft.dpi: 120
Xpra server output with -d screen
:
2020-02-24 12:36:09,608 X11 display is ready 2020-02-24 12:36:09,993 GDK can access the display 2020-02-24 12:36:09,998 created unix domain socket '/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104' 2020-02-24 12:36:10,218 pointer device emulation using XTest 2020-02-24 12:36:10,240 Warning: no XShm support on display :104 2020-02-24 12:36:10,279 xvfb pid not found 2020-02-24 12:36:10,283 randr=True 2020-02-24 12:36:10,284 _XPRA_RANDR_EXACT_SIZE=None 2020-02-24 12:36:10,284 randr=True, exact size=True 2020-02-24 12:36:10,284 randr enabled: True 2020-02-24 12:36:10,285 query_opengl() skipped: noprobe 2020-02-24 12:36:10,400 _NET_WORKAREA=[0, 0, 1920, 1080] 2020-02-24 12:36:10,401 _NET_DESKTOP_GEOMETRY=[1920, 1080] (Xpra:462966): Gtk-CRITICAL **: 12:36:10.650: gtk_widget_realize: assertion 'widget->priv->anchored || GTK_IS_INVISIBLE (widget)' failed 2020-02-24 12:36:10,668 6.7GB of system memory 2020-02-24 12:36:10,724 xpra is ready. 2020-02-24 12:36:10,735 xpra GTK3 X11 version 4.0-r25252 64-bit 2020-02-24 12:36:11,134 uid=1000 (lauscher), gid=1000 (lauscher) 2020-02-24 12:36:11,135 running with pid 462966 on Linux Debian testing bullseye 2020-02-24 12:36:11,136 connected to X11 display :104 with 24 bit colors 2020-02-24 12:36:12,106 New unix-domain connection received 2020-02-24 12:36:12,107 on '/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104' 2020-02-24 12:36:12,114 Handshake complete; enabling connection 2020-02-24 12:36:12,115 dpi=192, dpi.x=0, dpi.y=0, antialias={b'enabled': True, b'hinting': True, b'hintstyle': b'hintnone', b'contrast': 0, b'orientation': b'NONE'}, cursor_size=0 2020-02-24 12:36:12,146 mmap is enabled using 256MB area in /run/user/1000/xpra/xpra.n47wqmlp.mmap 2020-02-24 12:36:12,149 Python/GTK3 Linux Debian testing bullseye x11 client version 4.0-r25252 64-bit 2020-02-24 12:36:12,149 OpenGL is disabled 2020-02-24 12:36:12,149 connected from 'buster' as 'lauscher' - 'Lauscher' 2020-02-24 12:36:12,157 setting key repeat rate from client: 500ms delay / 37ms interval 2020-02-24 12:36:12,159 setting keymap: 2020-02-24 12:36:12,206 setting keyboard layout to 'de' 2020-02-24 12:36:12,365 do_parse_screen_info(ClientConnectionMuxer(1 : Protocol(unix-domain socket:/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104)), (1920, 1080)) 2020-02-24 12:36:12,365 client root window size is 1920x1080 with 1 display: 2020-02-24 12:36:12,366 :0.0 (508x285 mm - DPI: 96x96) workarea: 1870x1045 at 50x35 2020-02-24 12:36:12,366 BOE eDP (344x193 mm - DPI: 141x142) 2020-02-24 12:36:12,367 current server resolution is 1920x1080 2020-02-24 12:36:12,367 maximum client resolution is 1920x1080 2020-02-24 12:36:12,367 minimum client resolution is 1920x1080 2020-02-24 12:36:12,367 want: bigger, so using 1920x1080 2020-02-24 12:36:12,367 set_screen_size(1920, 1080, True) 2020-02-24 12:36:12,367 set_screen_size(1920, 1080, True) xdpi=192, ydpi=192 2020-02-24 12:36:12,368 set_dpi(192, 192) 2020-02-24 12:36:12,369 cannot find a temporary resolution for Xinerama workaround! 2020-02-24 12:36:12,370 using XRRSetScreenConfigAndRate with 1920x1080 2020-02-24 12:36:12,375 calling RandR.get_screen_size() 2020-02-24 12:36:12,376 RandR.get_screen_size()=1920,1080 2020-02-24 12:36:12,376 RandR.get_vrefresh()=0 2020-02-24 12:36:12,376 server virtual display now set to 1920x1080 2020-02-24 12:36:12,377 configure_best_screen_size()=(1920, 1080) 2020-02-24 12:36:12,377 get_max_screen_size()=(1920, 1080) 2020-02-24 12:36:12,377 calculate_workarea(1920, 1080) 2020-02-24 12:36:12,378 calculate_workarea() screen_sizes(ClientConnectionMuxer(1 : Protocol(unix-domain socket:/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104)))=[(b':0.0', 1920, 1080, 508, 285, ((b'BOE eDP', 0, 0, 1920, 1080, 344, 193),), 50, 35, 1870, 1045)] 2020-02-24 12:36:12,378 calculate_workarea() found <Gdk.Rectangle object at 0x7f7bfdb91ad0 (GdkRectangle at 0x1f96aa0)> for display b':0.0' 2020-02-24 12:36:12,378 calculate_workarea(1920, 1080) workarea=<Gdk.Rectangle object at 0x7f7bfdb919f0 (GdkRectangle at 0x21dc7e0)> 2020-02-24 12:36:12,379 _NET_WORKAREA=[50, 35, 1870, 1045] 2020-02-24 12:36:12,379 _NET_DESKTOP_GEOMETRY=[1920, 1080] 2020-02-24 12:36:12,379 no icc data found in {} 2020-02-24 12:36:12,380 reset_icc_profile() 2020-02-24 12:36:12,383 client resolution is (1920, 1080), current server resolution is 1920x1080 2020-02-24 12:36:12,383 get_max_screen_size()=(1920, 1080) 2020-02-24 12:36:12,385 automatic picture encoding enabled, also available: 2020-02-24 12:36:12,386 rgb24, rgb32 2020-02-24 12:36:12,394 RandR.get_screen_size_mm=254,143 2020-02-24 12:36:12,394 client 1 @02.700 Xpra GTK3 X11 server version 4.0-r25252 64-bit 2020-02-24 12:36:12,394 DPI set to 192 x 192 2020-02-24 12:36:12,395 wanted: 192 x 192 2020-02-24 12:36:12,395 client 1 @02.701 running on Linux Debian testing bullseye 2020-02-24 12:36:12,399 client 1 @02.703 Attached to socket:///home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104 2020-02-24 12:36:12,404 client 1 @02.704 (press Control-C to detach) 2020-02-24 12:36:12,414 get_max_screen_size()=(1920, 1080) 2020-02-24 12:36:12,521 client 1 @02.806 server does not support xi input devices 2020-02-24 12:36:12,530 client 1 @02.807 server uses: xtest 2020-02-24 12:36:13,031 New unix-domain connection received 2020-02-24 12:36:13,032 on '/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104' 2020-02-24 12:36:13,490 client 1 @03.796 Xpra OpenGL Acceleration Failure 2020-02-24 12:36:13,490 client 1 @03.797 invalid literal for int() with base 10: '5 (Compatibility Profile) Mesa 19'
Additional infos:
$ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384 eDP connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm 1920x1080 60.01*+ 39.27 1680x1050 60.00 1400x1050 60.00 1280x1024 59.95 1440x900 59.99 1280x960 59.99 1280x854 59.95 1280x800 59.96 1280x720 59.97 1152x768 59.95 1024x768 59.95 800x600 59.96 848x480 59.94 720x480 59.94 640x480 59.94 HDMI-0 disconnected (normal left inverted right x axis y axis) VGA-0 disconnected (normal left inverted right x axis y axis)
Wow, 2 different values can happen, but 3!?
Any progress on this? Makes using xpra html difficult until we can set the dpi.
In the mean time, is there a get-around to improve performance/res?
First, about your command lines:
--clipboard-direction=both
this is the default, not needed
--clipboard=no
so why bother setting the direction?
--system-tray=yes
this is the default, not needed
--fake-xinerama=no
- this is now the default (was not before - slowing down startup on Debian), but if and when we do package fakexinerama for Debian then this will disable it unnecessarily - but I can't think of a better way
--video-decoders=none
doesn't do anything on the server
--video-encoders=none
doesn't do anything on the client
--xsettings=no
this will prevent the xpra server from setting xproperties, including DPI (Xft.dpi
and friends) - if you want to prevent the client's xsettings from being propagated to the server, use this switch client-side only
Then you're also setting it for the vfb. Why? This won't look good on high-DPI displays.
-extension MIT-SHM
- I know I mentioned this to you before - hasn't this been fixed? Disabling mmap transfers to the host is one thing, but not having shared memory within-the-container-only will severely hamper the xpra-X11 performance and has no security benefits - surely there's a way to enable one without the other?
Now, this bug:
DPI set to 192 x 192
Is fixed in r25645 + r25646. It only triggers if you use the dpi switch client-side, which is not recommended.
xrdb -q | grep -i dpi
Xft.dpi: 120
Since you are telling xpra to not touch the xresources, this value does not come from xpra, which explains why it is unrelated to the others.
Also, you're using Xvfb instead of Xdummy, which is not a default setup, some DPI attributes may not be honoured that way.
Thank you for your comments on several options! I've adjusted the xpra commands accordingly.
Is fixed in r25645 + r25646. It only triggers if you use the dpi switch client-side, which is not recommended.
Thank you! Yet I've detected that, too. I'm running an update now to check the fix.
What is it that you're trying to accomplish? leaving it alone should pickup the client's dpi automatically. Then you're also setting it for the vfb. Why? This won't look good on high-DPI displays.
x11docker sets up xpra server+client+Xvfb on the same computer. It sets --dpi
in xpra and Xvfb accordingly to the host dpi (found with xdpyinfo) or defined by the user with an x11docker option --dpi
.
Xvfb and the client applications are started before the xpra server, so it makes sense to set -dpi
in Xvfb.
-extension MIT-SHM - I know I mentioned this to you before - hasn't this been fixed? Disabling mmap transfers to the host is one thing, but not having shared memory within-the-container-only will severely hamper the xpra-X11 performance and has no security benefits - surely there's a way to enable one without the other?
x11docker enables mmap because xpra server and xpra client run on the host. It cannot allow MIT-SHM because the container does not share the memory with the host.
I found no way to allow memory sharing for MIT-SHM only. Docker only allows to share the entire IPC namespace/shared memory for all applications (Docker option --ipc=host
).
@twyeld The bug fixed here does not affect your custom xpra setup in container (https://github.com/mviereck/x11docker/issues/229#issuecomment-599006359). Maybe it helps if you also (or only) set x11docker option --dpi
to have another Xvfb DPI setting.
thanks to both Antoine and mviereck , a short-term getaround is to set the screen size for x11docker - it seems 4:3 ratio gives the best result (~75x75dpi):
x11docker --xvfb --size 1024x768 --dbus-system -- "-p 15500:15500" chromium-x11docker-test
It sets --dpi in xpra and Xvfb accordingly to the host dpi (found with xdpyinfo) or defined by the user with an x11docker option --dpi.
Just beware that xdpyinfo is unreliable and almost always set to 96, even when the actual dpi is not.
Then there's also Xft.dpi
and friends, those are better because they reflect the user's preference, not the faked geometry you get from xdpyinfo
.
Xvfb and the client applications are started before the xpra server, so it makes sense to set -dpi in Xvfb.
Sure. Just be aware that if the client's geometry is modified later (new monitor plugged in, change in resolution), things may get whacky.
I found no way to allow memory sharing for MIT-SHM only. Docker only allows to share the entire IPC namespace/shared memory for all applications (Docker option --ipc=host).
That's a real shame!
As per Understanding the Linux Virtual Memory Manager: The filesystem comes in two variations called shm and tmpfs. They both share core functionality and mainly differ in what they are used for. shm is for use by the kernel for creating file backings for anonymous pages and for backing regions created by shmget().
We need shmget
for xshm, so mounting a tmpfs may not be enough. I have not tried it.
x11docker --xvfb --size 1024x768 --dbus-system -- "-p 15500:15500" chromium-x11docker-test
FYI: Should be OK, but if 1024x768 is smaller than your client's screen size, you may hit other issues later on: #349, #1132. (not sure about Xvfb since xpra generally uses Xdummy instead)
@mviereck: please close if this works for you.
using Xdummy instead of xvfb provides similar results = 88 x 75 dpi
is there a chart showing pixel ratios/res and dpi for xdummy/xvfb?
is there a chart showing pixel ratios/res and dpi for xdummy/xvfb?
How would that work? There is no fixed ratio!
I agree - I was just trying to work out the magic numbers that would produce at least a balanced dpi
how is the dpi currently calculated?
how is the dpi currently calculated?
First, you have to be clear about which DPI you are referring to. As I explained before, there are many. Please also see wiki/DPI and the links in there.
Replying to Antoine Martin:
Please also see wiki/DPI and the links in there.
I have read through much of this material - and it seems to offer some convoluted solutions - but I can't know what dpi my users will have on their machines and so it seems that there should be simple method for setting the dpi to either 72 or 96 for most standard formats on a 2K screen and higher dpi as a custom option...
but non of the dpi flags seem to work and using RANDR seems like a bit of kludge - unless I am missing something crucial..?
unless I am missing something crucial..?
No, welcome to my world!
@mviereck: please close if this works for you.
The update gave me a lower xpra version so I could not check the fix. However, I'll just assume it works. For x11docker it is fixed setting --dpi in xpra server command only. So far, we can close the ticket as the origin issue is solved.
I have opened a new ticket at x11docker for @twyeld's issues: https://github.com/mviereck/x11docker/issues/230 I'm not sure if we should discuss here or there.
About the MIT-SHM issue I've opened a new ticket: #2647
(for Ubuntu 16.04 servers, see also #1935)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2610