DirectFB: A New Linux Graphics Standard? 437
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?"
Goodbye Platform Interoperability... (Score:3, Insightful)
Re:They're nothing like each other! (Score:5, Insightful)
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.
Innovation outside the USA (Score:2, Insightful)
Why is it that it is European governments [kbst.bund.de] that are considering moving to Open Source, [newsforge.com] and not USA governments?
Why is it that it is big companies in the UK that are grouping together [tif.co.uk] to fight Microsoft's restrictive licensing, and not the USA?
Is the USA in danger of losing its lead in the technology sector?
Re:They're nothing like each other! (Score:4, Insightful)
(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
To the Naysayers (Score:3, Insightful)
While main of you correctly point out the lack of network support in this, let's be honest here, the majority of users want a fast, pretty desktop. This would be the way to do it.
Applications are not a problem; both GTK and QT have abstracted the window drawing from the widget set (GDK for GTK) so someone could potentially relink (not necessarily rebuild, if the symbol tables stay the same) their apps and have a wealth of stuff to choose from.
I like the network transparancy in X, but what is to keep you from running X for remote applications, and using DirectFB for your desktop? X is nice, but it's filled with lowest-common denominator decisions, and the majority of people polled (cough) want to run with things like alpha blending, anti-aliasing, and windowed 3D. X supports them, but not without a lot of pain.
So, if you want to use X, you could potentially keep it; if you want DirectFB, you can use all your GTK/QT apps (theoretically) Why rain on someones parade when both crowds could potentially win here?
Re:They're nothing like each other! (Score:3, Insightful)
It isn't X that's chatty - it's the apps that use it. Some years ago I developed a couple of simple applications to display some statistics graphically in (pseudo) real-time. Over a SLIP connection on a 14400 modem, one of them worked but the other one didn't. The one that didn't had a little bug that I'd never noticed on a local machine or even over ethernet. The bug was that it redrew the graph elements even when it didn't need to.
So don't go blaming X for things over which it has no control. OK, so maybe its network model isn't suitable for video players or arcade games - but don't write it off because of that.
i'll stay with X. (Score:5, Insightful)
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
Re:X isn't so bad... (Score:3, Insightful)
Here's one. The whole X window system was designed from the get go with the idea of having a dumb terminal at the user end. As the design progressed, it became apparent that the X-terminal would require some higher intelligence. In the end X-terminals have a fully functional CPU that is being wasted by 90% of the function calls which were designed before the change of CPU demands.
Re:Goodbye Platform Interoperability... (Score:4, Insightful)
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.
Re:To the Naysayers (Score:4, Insightful)
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.
It is a about damn time!!! (Score:3, Insightful)
Seriously! I've been pushing for the death of X for a long time now. DirectFB is a very promising replacement from the sounds of it.
As for the network transparency layer, nothing says that you have to lose that. If done correctly, you won't even need to recompile your apps for each different use. Quite simply, assume that every app on a system uses DirectFB instead of X. Now you want to remotely use a gui on that system. DirectFB simply needs to present the ability to run in a detached hardware mode. A client system can attach it's DirectFB to a DirectFB layer on the server.
The rest would run a lot like X: the application writes it's video output to DirectFB, which saves it in a memory buffer. That memory buffer is output to the client system as quickly as possible, but moderate loss is acceptable. All hardware blits are performed in software instead (since you really aren't using the system's video card at that point).
Yes, it sounds a lot like X, but without a few major X problems. Video updates are not required. So your windows won't hang on slow networks. Bonus #2 is that a lost connection doesn't have to kill an app. Just reconnect to the server when you get a chance and pick up where you left off.
I hope I managed to get across the major difference. I have a feeling that I haven't. I have a better explanation in my journal for those who really want to understand my major bitch points for Unix these days. (Even though I'm still a huge Unix advocate these days.)
Re:Goodbye Platform Interoperability... (Score:2, Insightful)
So why don't we put the hooks in X so that full speed/direct to hardware access is possible? O whait? That's DRI...! XFree86 has bugs, sure, but it isn't the monster people think it is. Most of the memory the server uses are apps storing images and stuff server side.
This would be great but... (Score:2, Insightful)
If Linux is ever to be a player on the desktop, we will have to abandon X. X and DirectFB are not mutually exclusive and there should be a relatively painless transition. X just doesn't make sense anymore for a PC dominated world. When was the last time any of you used a dumb terminal? I've never used X on anything other than PCs and I'm sure that most of my generation can say the same.
In short we need a new king for a new generation.
Re:i'll stay with X. (Score:4, Insightful)
I agree. X is powerful, flexible and proven. It's like a 4x4 truck. What can you do with a 4x4 truck? Haul heavy loads, go offroad, pick up your date for dinner. But there's a lot of people who want to drive a sports car instead. What can you do with a sports car? Pick up your date for dinner. Period. Personally, if a date doesn't want to ride in a truck, I'll find someone who isn't so shallow.
If you can make DirectFB *identical* to XFree86 in functionality, then fine, I'll use it. But otherwise keep it away from me. Frankly, making gaming the primary goal of Linux is an incredible step backwards.
Do I want a transparent video player? (Score:2, Insightful)
I mean, really. The screenshot linked to is just awful! Which window's on top? Can I click on "Expand All?" Boo!
But the software itself looks keen . . .
The problems with X (Score:3, Insightful)
2) Its core protocol is missing a ton of features that program want. For example, nobody on the team knew how to do splines, so they left them out. Splines still aren't really supported, and won't be supported any time soon in the core protocol.
3) It's too extensive. It is generally implemented as a set of drivers, library, network server, resource manager, plus windowing system. Some of those features ought to be separate. In particular, splitting off the drivers (as well as implementations of operations the actual card doesn't support) from the windowing system would save a lot of hassles.
I think a layer for doing graphics under the level of the X server would be better. The main problem is that XFree86 has really good free drivers, which would be a shame to reimplement, but they are all for the X API.
There are some cases where you don't actually want the main features of X, so it would be good to provide a more fundamental graphics layer to programs that want it.
How about Correctness? (Score:2, Insightful)