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?"
(a) DirectFB is a thin abstraction layer over graphics hardware; ideal for blindingly fast games, video rendering, etc. Sure, that could be useful.
(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.
These sigs are more interesting tha
which is the whole point of X. You can have an X server running on Windows (ptui), Linux, *BSD, Solaris, Tru64, AIX, HP-UX, Max OS X, etc, etc, etc and display clients that are actually running on one of the other bazillion X supported platforms. The DirectFB solution works only for the Linux framebuffer. If you hate X, great, then this might be a place for you to develop tools and applications. For the rest of us old hand UNIX folks who have worked with X for years and years who love the network aspects of it, we'll stick with what we got. Even if developing software for it is way hard without several layers of software abstraction (toolkits).
I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher (1898-1972)
... is to refactor VNC to multicast directly to a bunch of Linux frame-buffers (a la SunRay). If companies are insisting on per CPU licensing and refusing to offer floating licenses (think legacy apps) then by running it on a half-decent back-end server (with fast storage) you can amortise the cost of the software over a wider geographical region, as well as support multiple legacy versions. Of course, you better have a decent network first.
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
These are the guys who run the Linux DVB (Digital Video Broadcasting) aka Digital TV projects, if you get a DVB-s (satellite) board from Hauppauge their package does amazing things, you can save the MPEG2 transport stream directly to disk and have a TiVo like system without any A/D conversions in the process. They have even garnered support from Nokia for their DVB API, Nokia want to use Linux in their STB's, the Media Terminal has been well publicised on /.
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!
Does it come with an open sourced barcode reader driver?
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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?
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
There's a standard X extension (?) called LBX that comes with XFree86 and others. Check out the LBX Mini-HOWTO if you are interested.
Cheers //Johan
Installed the Bubblemon yet?
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
I keep seeing people dissing X as a horribly inefficient system that is long overdue for replacement, but the justification always seems to be a myth.
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.
XML is like violence. If it doesn't solve the problem, use more.
X may be old but it has adapted to the times and continues to adapt. Direct frame buffer access is great for games and may be some graphically intensive applications but i'll take the ability to run an application on one machine and display it on another of possibly an entirely different architechure any day. My little pentium 133 laptop is still a very useful machine simply because all it really has to do is run X, i can even access pigs like star office without any problem.
VNC is a cool and useful hack but X is a better solution.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
Although the site is almost /.tted it still looks pretty mean and clean to me. BUT ;-) X provides us with all we need to prevent phisical activities as much as possible (in other words check your mail on your main machine while sitting on the couch watching TV, not to mention those tedious walks to the server room ;-))
;-)
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
Fighting for peace is like fucking for virginity
Why don't you visit the sites referenced by the links sometime? They HAVE an X server that sits on top of DirectFB- think of X as being merely a protocol, once you've done that, it matters little how you render to the screen or accept inputs (This is what DirectFB does...) so long as the implementation you're using works at least as well as any others.
Having said this, they're not quite there yet, but it's coming along nicely and is quite promising.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
You're missing the point that you're inserting a raftload of indirection in the picture when you use X as it's currently specified. Everything HAS to go through your TCP/IP stack. While it's GREAT for networkability (and I'd not ditch that feature), it's not as great for apps needing peak performance locally- it requires more muscle on the machine doing it this way than if it were direct.
/. blurb- they HAVE an X server for this and are advancing it as well because for most things, it's better to use X.
DirectFB was developed not for games, but for media convergence devices (Entertainment systems with Linux running as the core OS, etc.)- other people are latching onto it because of the above problems. DirectFB ditches the need for hacks like DGA (which is needed for things like tuner cards) and allows you to run things like video on demand systems, etc.
Oh, and next time, read up on the actual story, not the
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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)
Where the hell do I sign up to help!
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.)
It's so nice to see the ignorant Slashdot hordes rallying around the "X sucks!" flag. Here is what someone who actually knows what he's talking about has to say: (from http://www.linuxpower.org/display.php?id=211)
.5
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.
but something needs to be done about X. I have a very mainstream video card (TNT2), and under Windows it flies for 2D work (1600x1200x32)--full window moving, resizing, scrolling etc are perceptually instantaneous. This same card under KDE 2.2.1--using what appears to be a fairly well supported XFree86 4 server, at the same resolution and color depth--feels roughly like an unaccelerated SVGA driver under Windows, maybe a bit better. Many drawing operations become visible under heavy graphic load, such as when moving windows above other busy windows that need to be redrawn. Resizing windows feels sluggish, scrolling web pages and such feels sluggish etc. We'te not talking 1990-slowness, but in a world where graphic lag of any kind is essentially a thing of the past, this is very noticeable.
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.
I just don't get it. Why do people hate X? It's a fairly powerful system. There are implementations with excellent 2d and 3d hardware acceleration.
It does *not* use up "tons of RAM", as some people who don't understand the X architecture like to claim. If you see the X server using lots of RAM in top or the like, there are two very good reasons. (a) device mappings. Top counts this towards the total, but it isn't "real" physical memory being eaten. Have a 32MB video card? Guess why X looks 32MB bigger than it should?
(b) X stores pixmaps locally. This is why X *client* programs use less RAM than their Windows counterparts. One of the two (client or server) *has* to store any pixmap that's going on the screen. For speed over a network, it's much more intelligent for the X server to do so, since the pixmap will probably be drawn many times. So the client doesn't have to store its own copy...but it makes X look "bloated" because it's using some RAM itself to take load off the client programs. The overwhelming majority of RAM that X uses goes to this. If you're using Enlightenment with a pixmap GTK theme, the reason X is taking up more memory is because the client programs *aren't*.
The only real issue people have with X performance is that between the time an application wants to draw to the screen and the time the drawing happens, a context switch needs to occur. This is why the XFree folks came up with DGA, which avoids exactly this -- if you're just playing a game on the local computer, X imposes no overhead.
X does some damn cool things that Windows and friends will never do. Obviously, you can run programs over a network (without incredibly inefficient hacks like vnc). However, on a copy of XFree, hitting control-meta-kp or control-meta-kp- will let you switch resolutions, zooming in on something and letting you show stuff to people across the room (I use this a lot in my dorm room)
There are a few things that I don't like about X. X has a very sophisticated color management scheme, allowing you to output to just about any type of X server, but which can get complicated if you just want to draw something to the screen on your x86 box on XFree. That's why almost no one uses raw Xlib (X's own interface) and uses stuff like SDL or GTK, which handles the nasty details for you, and just lets you do your work.
XFree supports multiple monitors, desktops larger than your monitor, hardware alpha blending, shaped windows...
It's true that existing GUI "E-Z X configuration tools" haven't impressed me much, so you do have to maybe do a bit of poking to tweak out your configuration exactly the way you want it...but that's also true with most operating systems.
Oh, and Xlib doesn't natively support detatching windows from one X server and reattaching to another. I suppose this could be an issue, but since proposed replacements to X mostly don't do this *either* and since toolkits built on top of Xlib *can* do this...
Of course, you don't *have* to run an X server if you just want a console box...this guy doesn't run X.
For GUI systems, though, X is where it's at.
1) It's networked. People don't use this any more, mostly. If they do, it's via ssh, which doesn't use the network features of X anyway. X ought to just specify talking to a local server, which may be a proxy over ssh.
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.
Ok, here's a little thought experiment for you...
You've got a server machine with all those shared libs, right? Does an X terminal need those shared libs locally on itself to operate or can you get things like KDE to run on the X terminal session? No? If it's a "no", those shared libs are an application interface to X to make it easier to use its protocol accordingly.
Another experiment for you...
Take those shared libs and the apps that use them. Rip out the XFree86 server and replace it with a GGI or the XDirectFB server. So long as your apps don't use DGA or SHM (and maybe even then...) your apps will still work largely the same- why? Because, X, at its heart, is a protocol not shared libraries, etc. It has to be for it to all work transparently over a network with so many differing GUI rendering targets.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas