Slashdot Log In
DirectFB: A New Linux Graphics Standard?
Posted by
michael
on Tue Oct 23, 2001 07:51 AM
from the X-reigns-supreme dept.
from the X-reigns-supreme dept.
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?"
This discussion has been archived.
No new comments can be posted.
DirectFB: A New Linux Graphics Standard?
|
Log In/Create an Account
| Top
| 437 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
They're nothing like each other! (Score:5, Informative)
(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, and the need for (a) is growing. But that's not what the headline was saying.
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.
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
LBX = Low Bandwidth X (possibly off topic) (Score:4, Informative)
There's a standard X extension (?) called LBX that comes with XFree86 and others. Check out the LBX Mini-HOWTO [paulandlesley.org] if you are interested.
Cheers //Johan
Goodbye Platform Interoperability... (Score:3, Insightful)
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.
A way to reduce software costs .... (Score:4, Interesting)
BTE, whatever has happened to embedding X into the web browser (X11R7? Broadway?) How come that's not being used to port some of the older X utilities across to work over the internet?
LL
Kudos to the LinuxTV.org guys (Score:3, Informative)
I believe the DirectFB package was originally designed to do onscreen graphics for a TV link up so you could have alpha channels overlaying the MPEG stream.
Very clever guys... my hat goes off to them!
I wonder... (Score:4, Funny)
Does it come with an open sourced barcode reader driver?
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: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.
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
Massive security hole buddy (Score:4, Informative)
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.
Ouch- allthough your command to start the X proggie will be secure, the windowed program itself will be going over an unsecure channel if you use that method. (all your click are belong to them)
You should really look into X-forwarding (read man ssh).
Regardless- I too like the network transparency that is offered from X. If the damn X protocol would support SSL or something like it natively, then it would seriously speed up secure remote graphical logins. (search google for tcp over tcp to see why)
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.
X isn't so bad... (Score:5, Informative)
First off, the complaints are generally levelled against what they see in a particular implementation of the X protocol, not the protocol itself. There seems to be no acknowledgement that while X servers of the past may have had implementation problems, that we have moved on and produced much more efficient and well-featured implemntations, particularly XFree. Through X extensions, XFree has become an X server that keeps the good of X, and improves on the bad aspects of older X servers.
The main gripe I see is "X is slow!!". Well, with XAA, X gets the same sort of acceleration as Windows display drivers for ordinary stuff. This requires that good drivers exist for your chipset, which is a good bet nowadays, but not as likely as Windows. Not XFree's fault, and it's clear that any FB based solution won't help matters in this regard (driver support)
People also have complained about 3D performance. XFree4 has DRI which really works well to address the issue. For Video playback, there is XVideo which provides good access to hardware scalars and filters. There is work being done on an XMovie extension that could provide access to hardware video decoders, such as the MPEG-2 decoder on All-in-Wonder cards (though I haven't heard much about it lately). Another complaint I hear is that it is ugly, that it lacks the bells and whistles of 'modern' systems. Well, there is now the XRender extension which can be used to provide translucency (if anyone bothered to implement it) and in turn provide both anti-aliased text and sub-pixel sampled font rendering (ala Window XP's cleartext).
Those who complain about X and say it needs replacement need to be a bit more educated. If you look at the projects that have aimed to replace XFree in the past, you see a very interesting pattern. Berlin is a good example of this. They set out to provide things that at the time people said "X cannot accomodate these features", but by the time Berlin progresses to any usable state, XFree has most of these features in XFree4. Let's face it, XFree in particular is a good system that can continue for quite a long time, and has only improved with age, contrary to popular belief.
Give up $DISPLAY - Never! (Score:3, Interesting)
VNC is a cool and useful hack but X is a better solution.
Hmmmm..... (for al my regular readers ;-) (Score:3, Interesting)
I really think this is GREAT for the whole linux on the desktop venture, because as much as I love X (and I do) I know it is a very hard thing to do (loving it that is)
X is bloated, it is considerably slow, altough I must say that with Xfree86 4 a lot of things changed (for the better) the new "modules" system is brilliant!
But the biggest problem is that for geeks like me and you
Fact is that X is the defacto standard when it comes to remote displays, heck, even novell uses it in netware 4 trough 6
My idea: Port all the apps whatever to this new platform because what I've seen off off it, it is pretty darn nice for desktops, but we need to develop some kind of deamon which allows displays to be exported over a network when the display is NOT local.
Now it doesn't matter weither or not the display is on the localhost or not, clients always connect using the X protocol over loopback, this is a waste of resoures, why not only use it when it is absolutely neccecary?
I'd say make it POSSIBLE for programs to export their display not export them ALWAYS, I have no clue about how to do this, but if some people that know a bit more about X want to help me, we'll set up a project to implement just that, email me if interested, please flame here
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.)
Jim Gettys on X vs. GtkFB and QtE (Score:3, Interesting)
Jim: No, I believe very strongly that either GTK+fb or QtE are dead
ends. Our experience in the market (beyond the hacker community) is
that the major attraction is the ability to share with little or no
hassle applications written for the desktop: while the applications
may need reworking to deal with the screen size and touchscreen, there
are many applications not written for GNOME (or KDE).
Network transparency is worth a lot in PDA's such as an iPAQ: it is
really a full fledged networked computer in your hand, which can take
advantage of other displays, keyboards, etc. in the user's environment
when convenient. If I have a lot of text to enter, I don't want to use
a touch-screen unless I must, and I don't want to have to build two
applications, the way Palm or WinCE does. Others will experimentally
determine that frame buffer based environments are a waste of time,
but we won't...
At CRL (Cambridge Research Laboratory), we are working on the Mercury
project for pervasive computing. With the advent of high speed
(wireless) network connections and large (currently 1 gigabyte)
storage devices like the IBM microdrive, we foresee an environment in
which you will want to take advantage of the computing environment
around you, including keyboard, mice, projectors, and servers of all
sorts. Note that the ability of an application to interact with
desktops in your network environment is therefore vital, and sometimes
at levels beyond file and web sharing. Most of what you hear about X
being too big are from people who know little or nothing about the
topic. After all, we wrote X Version 11 on 2 megabyte VAX 11/750's:
iPAQs have 16 or 32 times that much RAM, and a CPU 200 times faster
(for integer operations).
Keith Packard, in his TinyX server using his new frame buffer code,
has reduced the X server to 500-700K bytes of code (depending on
whether you want his new render extension for anti-aliased text and
graphics). Most of the perception of bloat is caused by how Linux
reports memory. An X server maps the display card into its address
space, and on current graphics cards this can easily be 8, 16, 32 or
even 64 megabytes of address space (for the frame buffer and registers
of the display). Naive people look at "ps" or "top" and draw the wrong
conclusion. Clients may be asking the X server to preserve pixmaps on
their behalf (which should really be charged to the client, but it
shows up in the X server). So, for example the RSS size on my iPAQ is
2.2 megabytes when running Familiar, with backing store and save
unders still enabled (arguably, on a device like an iPAQ, I should
disable them, which would further reduce the RAM footprint).
I recently completed work to remove the dependency on Xt, Xaw, and Xmu
that many of the little X utilities had accretted over the years: this
saves 1.1 megabytes of code on a device like the iPAQ (presuming no
user application wants/needs Xt, which is easy to arrange). These
changes have just been checked into XFree86.
The remaining work is to put Xlib on a diet. There is about
megabytes of code and static data that has accumulated since Xlib left
my hands that few applications and toolkits use (the CMS and
Internationalization parts of Xlib). These are either never used
(CMS), or only used by Motif (which few Linux applications care
about). By making CMS and the I18N parts of Xlib dynamically loaded
libraries, we can avoid breaking binary compatibility, but allow PDA
users who don't need them (essentially everyone) to avoid the waste by
not loaded those libraries. John McClintock has patches for the CMS
changes which I hope to look at soon, and the I18N work is straight
forward.
Keith and I believe that a basic X environment will end up a bit over
one megabyte of code, when this is done, while preserving complete
compatibility (a full X implementation).The replacements for X don't
come free either (they also have to have frame buffer code, window
operations, etc.). The true cost of network transparency is well under
a megabyte, IMHO. At the current cost of RAM, it's not much cost, even
on low end PDA's... We could make things yet smaller, but we'd then
be sacrificing some compatibility, which, while reasonable, is less
desirable, as knowing your application should "just work" is worth a
lot. So I see either QtE or GTK+fb as dead-ends, interesting for a
short while on the smallest devices, but will be just a passing
footnote in history.
Don't know if this is it, though it sounds good... (Score:3, Interesting)
Maybe it's not all due to X, who knows. But dragging around baggage beneficial to only a portion of users (that seems to be getting smaller with a growing Linux user base) almost seems unfair. If I spend most of the day in front of the framebuffer, with only occasional remoting of the display, I'd prefer to have the fastest possible performance during that majority of time, and would in exchange accept worse performance during remoting. That's essentially what happens with VNC on Windows right now. And I know we can do better than that, because Windows has notoriously few graphic hooks, and any new display system could easily improve on that without giving up performance in spades like X.