[RFC] Xdummy standalone binary or "-dummy" switch

[Antoine Martin]

Hi,

As discussed a while back [1], there are a number of issues which can
only be resolved by using an Xdummy binary server in order to replace
Xvfb with a more modern equivalent. The only alternative I can think of
would be to add a "-dummy" command line option to Xorg, this feels
somewhat more intrusive/dangerous. Or maybe there is another way I
haven't thought about?

First, what is wrong with Xvfb?
It does not support modern extensions like RandrR which I need for my
Xpra fork [2]

Why can't people just use Xorg as it is with the dummy driver?
Well, you can but this involves using Xdummy's [3] dodgy LD_PRELOAD
hacks to workaround some of the limitations built into the Xorg server.

What are those limitations?
1) root-only limitations on the configuration options for the location
of the config and log files.
This makes sense when the server runs as root and gets (almost?) full
access to all system memory, but not when the only device driver loaded
is the "dummy" one.
Any user should be able to launch an Xdummy instance without needing
root or special permissions.
(I've tested this with a quick and dirty patch [4])
2) Xorg server probing devices.
Now this one I am less sure about, maybe I just don't know the proper
incantations. I've tried all the options I could find to try to prevent
all the probing that goes on (explicitly specifying the "void" driver
for keyboard and mouse, etc)
In the end, I just hacked the code to ignore them all for now [5]


It feels cleaner to just make a new Xdummy binary rather than
overloading Xorg with a new "-dummy" switch.
pros:
* drop almost all command line switches, make -novtswitch the default, etc
* easier to whitelist/blacklist what gets loaded
* no need to link against libraries which aren't needed, no VGAHW,
INT10, etc
* easier to use: can be made to look more like Xvfb
cons:
* higher initial development cost and maintenance

The alternative is the "Xorg -dummy" switch:
pros:
* much easier to implement? (new option and a few switches here and there?)
cons:
* potentially dangerous if somehow hardware device drivers can still be
loaded when the switch is on (which would make this type of bug
potentially quite dangerous)


Should you want to try it out with Xpra, simply apply the 3 patches
below to /xfree86/ (the third one [6] allows for absolute config file
paths - not sure why this does not work for root at present?), make and
copy the resulting Xorg as Xdummy, then you can test with:
xpra start :100 "--xvfb=/usr/local/bin/Xdummy +extension RandR
+extension Render -logfile ./log -config /path/to/xorg.conf"
DISPLAY=:100 xterm
xpra attach :100
Or if attaching from somewhere else:
xpra attach ssh:hostname:100

Your comments would be much appreciated.

Thanks
Antoine


[1] xorg discussion and patch for dummy driver:
http://lists.freedesktop.org/archives/xorg/2011-April/052812.html
[2] Xpra fork:
http://xpra.org/
[3] Xdummy by Karl Runge:
http://www.karlrunge.com/x11vnc/Xdummy
[4] Allow non-root users to specify log and config locations:
http://xpra.org/src/Xdummy/xdummy-allow-nonrootoptions.patch
[5] Ignore all input devices:
http://xpra.org/src/Xdummy/xdummy-ignoreallinputdevices.patch
[6] Allow absolute config filenames:
http://xpra.org/src/Xdummy/xdummy-absoluteconfigs.patch
[7] Sample xorg.conf I have used for testing dummy:
http://xpra.org/src/Xdummy/xorg.conf

PS: these patches were generated in reverse so you need to apply them
with "-R", sorry about that!