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?"
AHHH (Score:2, Interesting)
I wonder if the Texas guys with the colon in their name are gonna try to sue..
Supported in ClanLib IIRC (Score:2, Interesting)
No, I don't want a tranparent video player. (Score:1, Interesting)
hardware acceleration (Score:2, Interesting)
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
Re:Goodbye Platform Interoperability... (Score:3, Interesting)
The current XDirectFB uses DirectFB in fullscreen mode, it does its own window management. Just think of a rootless X on DirectFB, like on MacOS X. You could have X applications going through the server and DirectFB applications or games running directly at full speed. When the X server has been enhanced to use DirectFB's window management it would be easily possible to set the window opacity (ranging from 0-255) of any legacy application.
X is a great technology and I think DirectFB is rather a good base than a replacement of this technology.
Re:Goodbye Platform Interoperability... (Score:3, Interesting)
On Linux I would benefit from an efficient Qt or GTK implementation on DirectFB without running any X. I wouldn't ever have to see any ugly primitive X applications either.
On non-Linux platforms, Qt and/or GTK can be implemented in the traditional X fashion, or in any other fashion if that platform also has something more efficient.
Modern apps will still compile and run.
And if you like X apps (i.e. non-GTK and non-Qt), there is nothing here saying that you can no longer use X. X isn't going to disappear. Individual apps that use GTK or Qt can still use a Qt or GTK lib that supports X to draw on a remote display.
On Linux, on the X server end of things, you could use only one single X server. Yea! No more xf86config and all that crap. You could still see traditional ugly X applications or you could see remote GTK or Qt applications. Local GTK/Qt apps could be more efficient, going to DirectFB. The local X server could be iimplemented in a manner much like on some other platforms, where the X windows are integrated into a local window system -- or could use a traditional X root window.
Anyway, just my opinion. But since it makes things simpler and cleaner, I'm sure many old school people will be against it. Just my opinion, but I think this is a step forward. I'm sure it will encounter lots of resistance.
I think it fills a needed niche nicely (Score:2, Interesting)
Now, I use my Linux box as my development platform, web server, mail server, etc, but I've got to keep Windows around for gaming.
Re:They're nothing like each other! (Score:2, Interesting)
The network transparency of X is immensely useful (and brilliant). I'd rather take the superior, albeit slower, architecture of X over any super-fast, yet functionally neutered, architecture.
Sometimes I wish all of those "web standards" were thrown out in favor of a newer better version of X. Imagine: web applications could be the real thing, and all that (MS)HTML/(MS)XHTML/(MS)XML/(MS)JavaScript cacaphony could be tossed.
Re:How about client/server? (Score:2, Interesting)
X is a messaging and event handling system. There's nothing about it that says you ever have to open a window. You can use it for all sorts of local and remote event handling and messaging. The graphical aspect of it is what it's most used for. When you're writing a native X application, your last step is to start a loop that waits for events. Those events can be local or remote, and it's that capability that X should have been adapted. That it's had a great windowing system, X-Windows, built around it is perhaps even unfortunate. X is a marvelous technology that has never seen its full potential.
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
X.. (Score:2, Interesting)
- it's fairly simple to implement
- it's a standard
- it works
- it's here now
A few notes in DirectFB's favour
- a modern, and hopefully clean, implementation
- good object-oriented principles
- as a result, fast and easy to program in
So the solution, as I see it, is a little different. I've looked at Berlin and all those other windowing environments. Look, if what you want is direct access to one video console, then go with DirectFB. But if you want a windowed system, stick with X. Just reimplement it yourself.
(Although I don't know what to say about Window Managers.. they still seems like a nasty hack to me..)
XFree86 is old, and is carrying a lot of baggage functionality. What should happen is that it be rewritten to abstract the windowing portions away from the hardware level. I figure that if this is done, it'll be a drastic improvement, stability and OO-wise, over the current arrangement.
This is the main gripe I've heard, time and again, and it's the one that annoys me, too. So I think someone should do something about it. Start removing this functionality from XFree86, and stuff as much of it as possible into kernel drivers. (These wouldn't have to be included with the standard kernel; it would be enough to have a set of loadable drivers you could download from somewhere else and load into the kernel.)
I doubt this'll happen, though, because it's too OO. The current linux kernel is monolithic as high hell, and the people behind it support that mind-set. Perhaps there's hope for the GNU/Hurd.
GGI Perspective: clean code is good code. (Score:2, Interesting)
Not supposed to _replace_ X. (Score:2, Interesting)
No more DRI, et.al, just FB modules in the kernel, and DirectFB with some window manager.
As far as the annoying whining about how we can't replace X, it's a standard, we need remote display support, blah blah blah, it seems to me that developing an X server that runs through DirectFB is the obvious solution. D'uh?
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.
Re:Jim Gettys on X vs. GtkFB and QtE (Score:2, Interesting)
Of course this doesn't matter much for the desktop, but it does matter if you are developing for the embedded market where the costs for RAM and CPU decide if a product has a chance on the market.Another problem with X we faced is that certain features like true alpha channel and color keying are simply not available. These are absolutely needed when developing software for digital TV. DirectFB not only replaces X for us, it gives us a whole lot more X can not (yet) do. It was meant as a replacement for X on settop boxes, not primarily as a replacement for X on your desktop.
Drivers for FB - Do they exist? (Score:2, Interesting)
Re:I'm afraid you're mistaken. (Score:2, Interesting)
Packed pixel and color mapped.
Forget about colorplanes... even the Sparc 10s have an ATI controller using an 8bit colormapped display.
The only things you have to watch out for is 24-bit vs. 32-bit, 16-bit support (if you want it), and RGB vs. BGR order (with respect to the endianness of the platform). This can all be handled by blitting functions if you do 32-bit internally and double buffer.
Since fb is so low level, then DirectFB should have no problems porting to other architectures at all. Since the video hardware is the same, then the technique is the same. There would be no difference in the screen layout on your PPC nVidia then there would be on the x86 nVidia. The only important information to consider is byte ordering and bit depth. BTW, does fb.h support hardware panning/windowing through ioctls?
No, I haven't looked at the fb API, but I've used similar (very) thin abstraction layers like PTC and Allegro, both of which, by the way, can use fb as a drawing target.
X is nothing but a protocol... (Score:3, Interesting)
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.