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! _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
