RFD: setting up a minimal xorg configuration
Tiago Vignatti
tiago.vignatti at nokia.com
Wed Apr 14 09:26:26 PDT 2010
Hi,
Embedded devices want to set up an Xorg server with very specific and
customized capabilities. Several modules and extensions are simply unused
on these devices and not desirable to be built. So far we've been adjusting
this with a huge amount of autoconf options, which in turn means 2251 lines of
total mess in our configure.ac. It's far from being practical.
Let's pick my N900 case, for instance. I'm configuring Xorg more less like
this:
### DDXes
--disable-xwin
--disable-kdrive
--disable-xnest
--disable-dmx
--disable-xvfb
--disable-xwin
### Modules and extensions
--disable-xdmcp
--disable-xdm-auth-1
--disable-ipv6
--disable-tcp-transport
--disable-secure-rpc
--disable-glx
--disable-aiglx
--disable-glx-tls
--disable-dri
--disable-xace
--disable-dbe
--disable-xinerama
--disable-dpms
--disable-vgahw
--disable-xfree86-utils
--disable-dga
--disable-vbe
--disable-int10-module
--disable-xaa
--disable-xvmc
--disable-fontserver
--disable-libdrm
### Vendor related and misc
--with-default-font-path="/" \
--with-fontdir="/" \
--with-os-vendor="Nokia" \
--with-vendor-name="Nokia" \
--with-vendor-name-short="Nokia" \
--with-vendor-web="http://www.nokia.com/" \
--with-xkb-output=/tmp
One idea popped up was the creation of one single option that groups all
undesired modules, like --enable-xorg-minimal which would disable all modules
and extension there. That works for my case, but soon someone will want to
change one particular option from this set and so on. So I can think in three
approaches:
1. one single option disabling a very basic set and to be used for all sort of
embedded; would be --enable-xorg-minimal containing _part_ of modules and
extensions options but not for instance --disable-glx, cause some devices
might want to use it.
2. Try to separate in smaller groups like: --disable-hw-access (for vgahw,
vbe, int10, pci), --disable-remote-access (xdmcp, xdm-auth, ipv6,
tcp-transport, rpc) and etc.
3. don't remove any option from there and just clean up configure.ac. Well,
kernel has already zillion ways to configure it and seems that works nicely.
Honestly, it's not so clear to me why people were shouting so loud regarding
these bunch of --enable-{disable}-$option inclusions. If the purpose is testing
coverage then I'd say to go for 1. If the real problem is the mess in
configure.ac then 3. looks fine. The second approach is middle term of both.
Comments?
Tiago
More information about the xorg-devel
mailing list