Slashdot Mirror
DirectFB: A New Linux Graphics Standard?
Spy Hunter writes: "Some people really dislike the X Window System. DirectFB seems to be the answer to their prayers. Building on the framebuffer support available in recent Linux kernels, DirectFB adds hardware acceleration, input devices, and window management. It has been made (and LGPL'd) by Digital Convergence as a Linux video/television solution, but it is much more than that. It has the potential to replace X for Linux desktops. You want a transparent terminal? How about a transparent video player? Development is proceeding rapidly, with a GTK port and even an X server for legacy apps in progress. Could this be the future of the Linux desktop?"
I think that's a bit too simplistic a notion.
All X is really about is adding network transparency to GUI apps. To accomplish this, the protocol has a notion of windows, window managers, decorations, etc. There's nothing about X, however, that really has anything to do with hardware. X has no provisions for hardware acceleration or transparent windows, for example.
You're confusing X the protocol with 90% of all implementations of X, which themselves include a framebuffer, hardware acceleration, etc. For example, XFree86 is really just a GUI system that happens to implement the X protocol.
The main reason that implementations tend to be both a hardware driver and an X server is that the protocol can be a bit hairy to try and "map" into an alien GUI system. (And more than that, Unix systems typically don't even have anything else to map to, anyway, so if the X server isn't providing the hardware driver, there's nothing there.)
Anyway, the core issue is that there isn't (theoretically) anything that says that an X server has to be a hardware driver. Just look at Hummingbird's Exceed program, which implements an X server on Windows. Writing an X server that would run on a "native" framebuffer isn't such an exotic idea; Exceed actually works extremely well.
Granted, you can almost always tell that a particular program is an X program, because in practice X does dictate a certain look and feel (since a legacy X app would be running with a widget set that might or might not look like the native set.) But that's why they're porting GTK, and why the X server is for legacy apps.
(b) The X window system is a network-transparent graphical desktop environment based around the client-server paradigm. Sure, that could be useful.
You can't really have it both ways. It would probably be true to say, though, that the need for (b) is dying out,
My need for (b) is most definitely not dying out! I would find it sad if support for X under Linux started to seriously wane as people put all of their emphasis in having everything work blindingly fast when rendering directly to the hardware on which the application is running. I do play games occasionally, but most of the time I'm using my Linux boxen to do work. Remote shell sessions are the most common, but it's not infrequent for me to use a number of other remote X sessions, which are made possible, easy, and transparent by the client/server architecture of X. I do not forsee any time in the near future where I could hope to run the things I need to run entirely on whichever machine I happen to be working locally on.
Hopefully, there are enough other people out there like me to keep XFree86 going, so that even if "most people" start using something like DirectFB, X will still be an option. (Much as Gnome will still be an option if everybody starts using KDE, or vice versa; this is the beauty of free software.)
-Rob
however being able to ssh into any box and typing export DISPLAY=my_local_box:0.0 and then being able to run all the the remote Xapps on my box is is one of the greatest features on the planet.
if you want to increase the speed of your X its not replacing X, its replacing your KDE and gnome with fvwm2 (which is what i use) or even blackbox.
i see all these comments about enlightenment and KDE and gnome ( although i use GTK, not gnomelibs, _GTK_ for my devel and most usable apps) i shudder, because they are so slow, and then the same ppl complain about X, thats just wrong. if you want a fast system, a recommend the following:
granted transparent video will have some important uses in editing, however what has to ask how is it done in irix platforms now, is there a hardware solution that we can not compete against because its just so great?
i want X, maybe they can merged, kinda like now ppl have -nolisten tcp
-rev
If I were writing an application which had a hope of running remotely (a standard windowed word processor for example) I would write it to X. But if I were writing a new flight simulator, I would know up front that there is no hope of running it remotely, because it needs direct hardware acceleration, and I would write it for the DirectFB layer.
This is more like DirectX than anything; a way to bypass the high-level windowing system to write directly to hardware. As people have said, it doesn't replace X completely. But I would rather have a X server layer on top of a direct-hardware layer, than a direct hardware piece hacked into an old X server.
The fast pretty desktop is best achieved elsewhere. The problem isnt X, the problem is insufficient use of hardware acceleration in X device drivers and/or software bloat.
Yes, X supports these things. And, heck, OpenGL/GLX is even a network transparent protocol that too, so you can even run your hardware accelerated remote-displayed 3d programs over the net. And networks get faster all the time. So, please, concentrate on making these things less painful in X.
Any attempt to replace X will only end up going back in time half a decade, reimlementing X and eventually being back where we started.
DirectFB sounds great. For what it's used for. But X will never be replaced as the basic GUI layer for Linux/UNIX operating systems. No such attempt has ever caught on (and there have been a number of them), and none ever will simply because the only reason to is when you have absolutely no use for network transparency and you have far too little resources to support X. Today that means calculators and lowpower PDA's, and the occasional non-networkable consumer product, and with the way things are going, within a decade or two those cases will probably involve the device in question being a museum exhibit.