xpra icon
Bug tracker and wiki




Xdummy was originally developed by Karl Runge as a script to allow a standard X11 server to be used by non-root users with the dummy video driver (xf86-video-dummy).

Since then, the X11 server gained the ability to run without those LD_SO_PRELOAD hacks. This is now available for most distributions.

In the context of Xpra, Xdummy allows us to use a better, more up to date X11 display server, one that supports more extensions, especially the RandR and GLX extensions (it may also be faster for some X11 operations - though not all, see Xvfb-vs-Xorg x11perf).

For many display bugs (ie: #1, #2) or features (ie: wiki/DPI) this is the only workable solution: it allows Xpra to resize the virtual display to match the client's resolution so as to prevent windows and menus from overflowing beyond the edge of the screen. (see also fake Xinerama)


Xdummy standlone

You can start a new display using the dummy driver without needing any special privileges (no root, no suid), you should specify your own log and config files:

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

You can find a sample configuration file for dummy here: xorg.conf. (It contains many of the most common resolutions you are likely to need, including those found on phones and tablets. However if your client uses unusual resolutions, for instance multiple screens of differing sizes, you may want to add new Modelines to match your specific resolution)

Xdummy with Xpra

With Xpra, this should have been configured automatically for you when installing.

You can specify this virtual framebuffer alternative using the --xvfb switch or by setting the xvfb option in your /etc/xpra/xpra.conf:

xvfb=Xorg -dpi 96 -noreset -nolisten tcp \
			+extension GLX +extension RANDR +extension RENDER \
			-logfile ${HOME}/.xpra/Xvfb-10.log -config ${HOME}/xorg.conf

(the -noreset option is only needed if the window manager is not the first application started on the display, for example if you use the --start-child= option, or if you want the display to survive once the window manager exits - generally, this is a good idea since xpra could crash and when it exits cleanly via "xpra stop" it takes care of shutting down the X11 server anyway)

Driver Conflicts (libGL)

Proprietary drivers often install their own copy of libGL which conflicts with the use of software GL rendering. You cannot use this GL library to render directly on Xdummy (or Xvfb).

The best way to deal with this is to use VirtualGL to take advantage of the OpenGL acceleration provided by the graphics card, just run: vglrun yourapplication.

To make vglrun work properly with Nvidia proprietary drivers make sure to create /etc/X11/xorg.conf using sudo nvidia-xconfig.

The alternative is often to disable OpenGL altogether. (more information here: ticket:580#comment:3)



By default the configuration file shipped with xpra allocates 256MB of memory and defines a large number of common screen resolutions, including double and triple display setups.


Since it is impossible to pre-define all the combinations possible, if your client resolution does not match one of the pre-defined values, you may want to add this resolution to the configuration file. (hopefully, #56 will make all this redundant one day)

Use a modeline calculator like xtiming.sf.net or using a command line utility like gtf or cvt and add the new modeline to the /etc/xpra/xorg.conf.

The only restriction on modelines is the pixel clock defined for the dummy driver and monitor: at higher resolution, you may need to lower the vertical refresh rate to ensure the mode remains valid. If your new resolution does not get used, check the X11 server log file (usually in ~/.xpra/Xorg.$DISPLAY.log with xpra)

Large Screens

If you have an unusually large display configuration (multiple monitors), you may also need to increase the memory and/or increase the "virtual size".


Versions Required

Most recent distributions now ship compatible packages: Xorg version 1.12 or later, dummy driver version 0.3.5 or later; though some may have issues with non world-readable binaries (see below)

There are some more patches which improve the dummy driver further, which are not all upstreamed yet:

The dummy packages in the xpra repositories include those patches.


Ubuntu does weird things with their Xorg server which prevents it from running Xdummy (tty permission issues). Status: at time of writing, Xdummy can be used with 16.10 (aka "yakkety") but not with earlier versions. (see r14327)

(The following workaround has been tested on Ubuntu 14.04 server.

  • make sure you have xserver-xorg-video-dummy package installed.
  • add the user who is going to start xpra/xdummy on the server to the following three groups: tty, video and dialout (these are the groups /dev/tty*, /dev/fb0 and /dev/dri/card0 devices belong to)
    sudo adduser username groupname
  • fully reboot the server. Group membership change does not take effect until a new log in.
  • login to the server remotely (e.g. via ssh) and start the xpra using commands like this:
    xpra --xvfb="Xorg -noreset -nolisten tcp +extension GLX \
        -config /etc/xpra/xorg.conf \
        +extension RANDR +extension RENDER -logfile ${HOME}/.xpra/Xorg-10.log" \
        start :100

If that works, you can then place this same xvfb option in your global config file /etc/xpra/xpra.conf.

Note, if you are running an instance of Xorg locally on the server (e.g. using it as a desktop with a monitor attached), you need to start xpra server before starting the local xorg instance, or some permission issues may prevent you from starting xorg.

That's all! Using this method, I am able to run xpra with xdummy on an ubuntu 14.04 server)

non-suid binary

If you distribution ships the newer version but only installs a suid Xorg binary, Xpra should have installed the xpra_Xdummy wrapper script and configured xpra.conf to use it instead of the regular Xorg binary.

Newer versions of this script execute Xorg via ld-linux.so, which takes care of stripping the suid bit.

Older version of this script were copying the Xorg binary to a non-suid executable before running it. (Note: in some cases, you may need to make the Xorg executable world-readable so that the wrapper can make the non-suid copy when needed: sudo chmod +r /usr/bin/Xorg)

Last modified 2 weeks ago Last modified on 02/12/17 15:56:54

Attachments (1)

Download all attachments as: .zip