Xpra Documentation

Xdummy

Xdummy is an X11 server backend for Xpra’s seamless, desktop, and monitor servers on POSIX platforms.

It was originally developed by Karl Runge as a script that lets a standard X11 server run as a non-root user with the dummy video driver. Modern X11 servers can do this without the original LD_SO_PRELOAD hacks, and most distributions now provide the required support.

Why use Xdummy instead of Xvfb?

Xdummy provides the display features needed for high-DPI and multi-monitor desktop sessions.

Arbitrary DPI

Xvfb cannot simulate arbitrary DPI values. This can affect application geometry and font rendering.

Dynamic monitors

Xdummy can add or remove virtual monitors at runtime. This is required by monitor mode, the multi-monitor version of desktop mode.

Usage

Use Xdummy directly for a standalone display, or configure Xpra to use it as the xvfb backend.

Run Xdummy standalone

Start a display with the dummy driver without root or setuid privileges. Use your own log and configuration files:

Xorg -noreset +extension GLX +extension RANDR +extension RENDER \
     -logfile ./10.log -config /etc/xpra/xorg.conf :10

This is roughly equivalent to Xvfb :10. A sample dummy configuration is available as xorg.conf.

Start an Xdummy display through Xpra

With a distribution that supports Xdummy and Xpra 6.3 or later:

xpra xvfb :10

Select Xdummy as the Xpra backend

Since Xpra 6.3, configure this through the GUI with xpra configure vfb, or from the command line:

xpra set xvfb Xdummy

This saves the setting in ~/.config/xpra/conf.d/90_configure_tool.conf, or in /etc/xpra/conf.d/90_configure_tool.conf when running as root.

Xdummy with Xpra packages

Official Xpra packages normally configure Xdummy automatically. Debian and Ubuntu do not enable it by default because of distribution bugs.

At build time, select Xdummy with the --with-Xdummy or --without-Xdummy build switch. If a package does not enable it, you may still be able to change the setting at runtime.

Configuration

The shipped configuration allocates 768 MB of memory and a maximum virtual size of 11520 6318. Increase these values when using very high resolutions or many virtual monitors.

Sizing VideoRam

The VideoRam value in xorg.conf (in kB) caps the dummy driver’s framebuffer pool. Three things share that pool:

  1. Virtual root-window back buffer. It is sized by the active Display subsection—the one matching DefaultDepth at startup, not all Display subsections combined. The cost is roughly Virtual.w × Virtual.h × bytes_per_pixel. With DefaultDepth 24 and Virtual 11520×6318, that is about 218 MB; depth 30 is about 292 MB and depth 16 about 146 MB. A Virtual 16384 16384 display would exceed 1 GB at 24 bpp.
  2. Drawable buffers and pixmaps from client X11 applications. This is application-dependent and often the second-largest contributor. Software OpenGL apps using Mesa’s llvmpipe can allocate very large pixmaps; vglrun avoids this by routing GL through the host GPU. See OpenGL and the Memory guide.
  3. Cursor and offscreen buffers. These are small.

Practical reductions

Reduce memory use in this order:

  • Lower Virtual to match the largest client display. A Virtual 3840×2160 configuration uses about 32 MB of back-buffer instead of about 218 MB at depth 24, and pixmap allocations scale with the same dimensions.
  • Use vglrun for OpenGL applications to keep their backing buffers off Xdummy.
  • Do not expand VideoRam further than necessary. The default 768 MB is a generous ceiling for a single 24-bit 11520×6318 back buffer and a healthy pixmap pool. Smaller setups, such as a 1920×1080 desktop, work at 192 MB.

Display subsections

Removing unused Display subsections for depths 8, 16, or 30 does not save framebuffer memory. Only the subsection matching DefaultDepth is active; the others are configuration for starting Xorg at a different depth.

Verify memory usage

See Memory.md for measured RSS deltas and how to read the display.memory.* keys from xpra info.

History

The current defaults come from several sizing rounds documented in the CHANGELOG: increased default dummy-driver memory, reduced Xdummy memory usage through lower maximum resolutions, and fixes for the X11 server pixmap memory leak.

Packaging

Most recent distributions ship compatible Xorg and dummy-driver packages.

Required versions

  • Xorg 1.12 or later
  • dummy driver 0.3.5 or later

Optional dummy-driver patch

Since dummy driver 0.4.0, Xpra adds one optional patch to the version found in the Xpra repositories:

0006-Dummy-Disconnect.patch

Other issues

These platform and graphics-driver issues can prevent Xdummy from starting or can affect OpenGL applications.

libGL driver conflicts

Older distributions without libglvnd often install a proprietary libGL that conflicts with software OpenGL on Xdummy or Xvfb. Use VirtualGL and run vglrun yourapplication to use the graphics card. With Nvidia drivers, create /etc/X11/xorg.conf with sudo nvidia-xconfig.

Alternatively, disable OpenGL; see #580.

Debian and Ubuntu

Their Xorg packaging can prevent Xdummy from running because of TTY permission issues. It may also interfere with other sessions that should be isolated; crashing other X11 sessions is a serious security issue.

Non-setuid Xorg binary

If your distribution ships a newer Xorg but only installs a setuid binary, Xpra should install the xpra_Xdummy wrapper and configure xpra.conf to use it. The wrapper executes Xorg through ld-linux.so to strip the setuid bit. Some distributions have issues with non-world-readable binaries that prevent this from working.

This site is open source. Improve this page.