KDrive, Xnest, Xvfb Called For Removal From X.Org

[Ibidem]

Where did you see an embedded system running uptodate software? Such obsolete hardware is most likely still running Linux 2.4 with XFree86.

And nobody is going to switch their EOL hardware to M$ crap, M$ wouldn't offer support anyway. Only for new hardware there is this chance, and they drop old code so that they can provide better features/performance for new hardware, so where is the problem again?

Or do you think embedded means last decade's failed desktop hardware? Because that's what the link you posted suggests.

I'm not so sure you're correct on the MS part, much as I hate them; but leave that for now.

That fellow is doing a new design with Debian Squeeze/kernel 2.6.32 + Xorg 7.5, which is a far cry from 2.4 + XF86 (in case you weren't paying attention, the last Debian version with a 2.4.x kernel and XF86 was 3.1 not 6.0, so you're 5 years behind the times on that.)
The board isn't one I picked, it's one his company picked.

If you're going to through out claims to 'refute' what I say, you could at least verify that they match reality and each other!

Much as you may want to think that what failed on the desktop is dead, that's wishful thinking.
Go find a PC104 board that has NVidia graphics of any age/ION, or an AMD Radeon 3xxx or better, or find any x86 board listed as "embedded" that's halfway up-to-date.
The closest I've seen is an Atom board and a few of Via's designs; those might work reasonably if the graphics work, but even 'new' designs have to be compatible with the old ones to some extent, and switching from PC104 to (say) micro-ITX may not be possible due to those constraints.
I've even found a company selling 'embedded' boards based on an AM186; they also carry an Am386 based system that comes with Linux 2.2.
I could point out several examples of out-of-date hardware if I wanted, but checking the aforementioned ones should prove that much of the embedded/x86 stuff is very much 'the last decade or two's failed hardware. Gripe all you like, but if the hardware is from the last decade, they're unusually current--or are you going to pay them the (wag) $20/device they'd spend on going with real up-to-date hardware?

[Ansla]

That fellow is doing a new design with Debian Squeeze/kernel 2.6.32 + Xorg 7.5, which is a far cry from 2.4 + XF86 (in case you weren't paying attention, the last Debian version with a 2.4.x kernel and XF86 was 3.1 not 6.0, so you're 5 years behind the times on that.)
The board isn't one I picked, it's one his company picked.

That board is not what I was meaning when I said "such obsolete hardware", I was meaning the hardware that will actually be affected by the XAA removal. The XGI driver has exa support, if it's not yet complete and/or stable it just needs to be fixed by whoever is still using it, not random X developers.

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!

If you're going to through out claims to 'refute' what I say, you could at least verify that they match reality and each other!

Much as you may want to think that what failed on the desktop is dead, that's wishful thinking.
Go find a PC104 board that has NVidia graphics of any age/ION, or an AMD Radeon 3xxx or better, or find any x86 board listed as "embedded" that's halfway up-to-date.
The closest I've seen is an Atom board and a few of Via's designs; those might work reasonably if the graphics work, but even 'new' designs have to be compatible with the old ones to some extent, and switching from PC104 to (say) micro-ITX may not be possible due to those constraints.
I've even found a company selling 'embedded' boards based on an AM186; they also carry an Am386 based system that comes with Linux 2.2.
I could point out several examples of out-of-date hardware if I wanted, but checking the aforementioned ones should prove that much of the embedded/x86 stuff is very much 'the last decade or two's failed hardware. Gripe all you like, but if the hardware is from the last decade, they're unusually current--or are you going to pay them the (wag) $20/device they'd spend on going with real up-to-date hardware?

I don't know what crap Intel and nVidia are selling to their customers, but AMD has a very up-to-date offer http://www.amd.com/us/products/embed.../embedded.aspx

And you are aware that x86 is not the most popular architecture in the embedded market, right?

[daniels]

So it's better that users have no software than buggy software?

I've used Xnest, Xvfb and Xephyr for various things in the past, and would hate to see them go.

At the least, I really think they should wait 'till all the functionality of these servers which aren't currently available in the DDX drivers are implemented first before removing the servers, it'd provide motivation for whoever wants the servers removed to actually get the work done, whereas if the servers are removed first then we will likely never see some of the functionality re-implemented, and will effectively be removing functionality for no good reason.

Does anyone here ever bother reading what they're commenting on beforehand, or is that unnecessary hassle? Xfbdev already has xf86-video-fbdev (which has existed since the XFree86 days and isn't going anywhere), and Xnest and Xephyr are being replaced by an xf86-video-nested, and won't be removed until -nested is fully ready, so there would be no loss of functionality. All of this was covered in the thread.

And before someone mentions "removing 30,000 lines of code" as a good enough reason, I wonder how much of that code actually affects the Xorg server itself?
Pretty sure they're all separate code trees within the source tarballs...

All of it affects the server. Want to change how initialisation happens? Make sure you change KDrive too. Input? Yep, a lot of work in KDrive. Same with rendering, and in fact everything. If we want to make changes, we need to change KDrive and Xnest to make sure they haven't been broken. This takes time and effort we feel would be better expended elsewhere.

[daniels]

Xvfb:
Used by several packages' test suites, for automated testing. Drop it, and iceweasel/firefox/... have to
A. Drop automatic testing on X11, OR
B. Run test suites as root (not fakeroot, full root) (means packages must be built as full root)
Also, Xrdp does have reasons for existing.

(Or, drop it and replace it with a script that passes the appropriate options to Xorg/fbdev, resulting in no loss of functionality whatsoever.)

Xephyr:
Don't think about dropping this, until users can specify drivers or X autodetects when it's run nested via DISPLAY.
Useful for keeping experiments confined to one X server, while working on stuff separately.

(Or, drop it and replace it with a script that passes the appropriate options to Xorg/nested, resulting in no loss of functionality whatsoever.)

[rant]
Oh-and-by-the-way,
Whoever thinks xaa should die had better fix up EVERY driver that still needs it before they commit the change. Breaking embedded hardware like this is NOT the way to win the market; most such boards use a non-EXA driver.
The argument that "the drivers are obsolete and rarely used" is about as intelligent as a desktop user saying "We should really get rid of Apache--it's rarely used, and has had several security holes". You may not see the users, but that doesn't mean they're not there; it's just a different field.
Do you really want Windows CE/Mobile/whatever MS named it today taking over the embedded market?
[/rant]

Hi - that was me. I've been working on mobile and embedded Linux full-time for the last 6 years and 2 months now. The embedded/mobile market doesn't ship SIS GPUs. If it did, someone probably would've fixed the SIS driver so it actually worked instead of just rendering nothing but black. I agree that unmaintained and broken drivers are bad, but I'm really not sure what that has to do with XAA vs. EXA.

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.

[curaga]

(Or, drop it and replace it with a script that passes the appropriate options to Xorg/fbdev, resulting in no loss of functionality whatsoever.)

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.

[Nobu]

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.

[curaga]

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?

The shell does not use Xorg's internal libraries (libshadow, libfb, libexa et al), those are the spread out files I mentioned. If you had a Xfbdev-based system, you had no need for any of those or the Xorg binary, saving the space. "du -hs lib/X11/modules" gave 32mb, of which 23mb is mesa drivers, so it's 9mb of X modules. Not counting various data files or binaries that wouldn't be needed with Xfbdev either. (yikes, my pulled-from-the-air 3mb Xorg number seems grossly low now)

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.

[Ibidem]

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.

Consider that Xfbdev is used instead of Xorg.
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.

[daniels]

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.

[daniels]

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.]