According to http://xorg.freedesktop.org/wiki/ExaStatus these are the drivers that still don't support EXA:
glide, glint, i740, imstt, newport, impact, rendition, trident, voodoo, apm, cirrus, neomagic, cyrix/nsc, sun, ark, chips, s3, tga, tseng
Do you really think anybody will start a new project based on one of those chips and latest software? Those are not even previous decade, rather previous millennium!
And you are aware that x86 is not the most popular architecture in the embedded market, right?
Anyway, as I pointed out, XAA is only ever used if you're not using a compositing window manager, and not using XRender, and not using double-buffering (even if it is client-side, like GTK and Qt have done for years now), and not using GL. So, um, that would be xedit, xterm and anything with Xaw (but not Xaw3d!) then. And even then, it only offers an advantage over EXA with unmaintained drivers where no-one is willing to provide any work on them.
I don't mind conceding that part of the embedded market - not least because it's nowhere near 70% and in fact not even close to 1%, so your Apache argument is pointless and irrelevant.
Resulting in loss of RAM and storage space. Xfbdev is a single 600kb binary. Xorg totals somewhere around 3mb with dozens of spread out files.(Or, drop it and replace it with a script that passes the appropriate options to Xorg/fbdev, resulting in no loss of functionality whatsoever.)
Where does the extra storage space usage come from? And ram?
The script would run, then the shell would exit, right? Most systems run a shell at least once anyway, so any shared libraries are already loaded into memory. And we're removing code in order to replace Xfbdev, etc., anyway, not to mention the binary isn't there anymore. Shouldn't that cut down on used disk space?
These are honest questions, correct me if I'm wrong.
The code removed (Xfbdev in this example) does not help Xorg the binary/server, it would help the development. I seem to recall Xfbdev wasn't even built by default, you had to explicitly request it with a configure option.
Xfbdev uses less RAM than Xorg
Disk space for packages added (dependencies of both are omitted):
2793k Xfbdev package vs 4579k (server) + 180k (evdev driver) + 98.3k (fbdev) + 487k (libdrm) +37.3k libpciaccess
Total: 2793k vs 5382k = 2,589k difference
That's an awful lot for Tinycore (which I know curaga is involved in), pupngo, or a rescue system that lives alongside your data on an old 500MB flashdrive.
I'm not sure where you're getting these numbers from, but I make a cumulative total of about 2.5MB (might be a little more due to being overeager with strip, but in any case less than 3MB) for Xorg + evdev_drv + libfb + libfbdevhw + libshadow. fbdev_drv.so would be a little more but not too much. You could make this even less again by building with -Os.
So we've got ~2.8MB versus 1.6MB for my fully-stripped Xfbdev, which is still a bit of a jump but not half as catastrophic as you make out. Remember also that both of them depend on the 197KB xkbcomp, the 142KB libxkbfile, and an XKB data set which is 3.6MB (!!) unless you go out of your way to strip that down.
If you don't want pciaccess or drm, you can disable them with ./configure and squeeze some huge space wins, especially with pciaccess. Similarly, you could disable udev, Xv, DGA (which is pretty damn big), Xdmcp, DRI2, and XACE for even more.
There are still definitely some space and size wins to be squeezed out of Xorg, but it really isn't a massive increase over Xfbdev. Even so, you still have libX11 weighing in at 1.5MB+, and a fairly hefty pixman too. And your clients are likely running GTK+ (bigger than all of them combined), or Qt (even bigger again), with Cairo (pretty damn big).
tl;dr: I really don't think it's as big a deal as you're making out.
Alright, let's get some actual numbers involved ...
../configure --prefix=/usr --enable-install-setuid --sysconfdir=/etc --localstatedir=/var --disable-docs --disable-devel-docs --enable-kdrive --enable-xfbdev --disable-xcsecurity --disable-xselinux --disable-xf86bigfont --disable-pciaccess --disable-config-udev --disable-dga --disable-xv --disable-xf86vidmode --disable-dri2 --disable-xvmc --disable-xdmcp --disable-xdm-auth-1 --disable-xinerama --disable-xace --disable-xfree86-utils --disable-xaa --disable-vgahw --disable-vbe --disable-int10-module --disable-libdrm --disable-dmx --disable-xvfb --disable-xnest --disable-xephyr --disable-xfake --disable-kdrive-kbd --disable-kdrive-mouse --enable-kdrive-evdev --disable-tcp-transport --disable-ipv6 --disable-local-transport --disable-secure-rpc --with-sha1=libcrypto --disable-dri CFLAGS=-Os
Then stripped with strip --remove-section=.comment --remove-section=.note.
-rwxr-xr-x 1 daniels daniels 1.1M Apr 11 15:24 bin/Xfbdev
-rwxr-xr-x 1 daniels daniels 1.4M Apr 11 15:24 bin/Xorg
-rwxr-xr-x 1 daniels daniels 117K Apr 11 15:24 lib/xorg/modules/libfb.so
-rwxr-xr-x 1 daniels daniels 17K Apr 11 15:24 lib/xorg/modules/libfbdevhw.so
-rwxr-xr-x 1 daniels daniels 23K Apr 11 15:24 lib/xorg/modules/libshadow.so
-rwxr-xr-x 1 daniels daniels 25K Apr 11 15:24 lib/xorg/modules/libshadowfb.so
So, that's 1.1MB, vs. 1.58MB + however much evdev_drv.so and fbdev_drv.so end up being. Add in the XKB bits, and you have ~5.1MB vs. ~5.58MB (+ fbdev_drv + evdev_drv).
For full disclosure, this is against my extmod + unexport branches of xserver which haven't yet been merged upstream, and I expect master performs a little worse here. Still ...
[Edit: It obviously goes without saying that we'll very happily take patches for size reduction in Xorg. We've shed about half our codebase since 2004 (~1.1M LoC -> ~500k LoC) and would be happy to see that trend continue.]
Last edited by daniels; 04-11-2012 at 11:39 AM.
The Xfbdev binary we ship is 646.5 kb. All the XKB things you mention are not needed with Xfbdev.So we've got ~2.8MB versus 1.6MB for my fully-stripped Xfbdev, which is still a bit of a jump but not half as catastrophic as you make out. Remember also that both of them depend on the 197KB xkbcomp, the 142KB libxkbfile, and an XKB data set which is 3.6MB (!!) unless you go out of your way to strip that down.
I'm also not getting why you're not listing all of the Xorg's internal libs (libcfb libmfb libint10 etc etc), but only those. How can an user tell which can be deleted of them? ldd doesn't show anything as depending on them.
Oh right, the OpenSSL dep, I had forgotten about that! Thanks for the reminder
It's not a general purpose box usually that is that space conscious or runs Xfbdev. You can often not use gtk, qt, cairo, pixman and folks.There are still definitely some space and size wins to be squeezed out of Xorg, but it really isn't a massive increase over Xfbdev. Even so, you still have libX11 weighing in at 1.5MB+, and a fairly hefty pixman too. And your clients are likely running GTK+ (bigger than all of them combined), or Qt (even bigger again), with Cairo (pretty damn big).