On Thu, Sep 29, 2011 at 12:10:29PM -0700, Jamey Sharp wrote: > On Fri, Sep 30, 2011 at 12:10:05AM +0700, Antoine Martin wrote: > > 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? > > I think there's a third option here, yeah. > > > First, what is wrong with Xvfb? > > It does not support modern extensions like RandrR which I need for my > > Xpra fork [2] > > Also wrong with Xvfb: I want it and the other DDXes to die. :-) > > > 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]) > > The same goes for the video-nested driver. It might make sense for fbdev > or KMS drivers too: if you have permission for the device node, you > should be able to run an X server on it any way you like. > > Further, I think checking whether the server is running as root is > always the wrong check. I think the *right* check is to test whether the > server's effective UID is the same as its real UID. Then the server can > be paranoid about config files and options only when it's running with > different permissions than its caller otherwise would have. > > For example, there's nothing wrong with a non-root user setting a custom > module path. The only problem is if a non-root user, running a SUID X > server, can use a custom module path to execute harmful code with > elevated permissions. Similarly, setting a log-file path is only a > problem if you can overwrite a file you couldn't otherwise overwrite. > > I don't think this calls for an "unbreak me please" flag; I think the > normal behavior of the server should be fixed. > > > 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] > > I use these settings in my nested/dummy testing, which seem to suffice > for me: > > Section "ServerFlags" > Option "AutoEnableDevices" "false" > Option "AutoAddDevices" "false" > EndSection > > I'm not sure even AutoEnableDevices is relevant; I think AutoAddDevices > is the important flag. You shouldn't need to add any input devices, not > even "void" ones.
There's little need for AutoEnableDevices ever. I think the main reason it is there is because XI 1.3- had a rather different notion of enabled/disabled devices than we have now. If your nested driver needs to disable this, we could add a hook to the DDX to let a driver toggle AAD defaults. Cheers, Peter > If that's all the issues you've had, I'm hoping that just fixing the > stupid "am I root?" checks will take care of everything you need. > Anything missing? > > Jamey _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
