The first, very-alpha, release of the Qt library onDirectFB is now available for testing! A lot of things still have to be
implemented, so please don't expect to be able to run Konqueror on DirectFB
(yet). You can find screenshots and a link to the source here.

Comments

XFree86 currently accesses your hardware directly, essentially bypassing the kernel. Historically, this is because Linux, BSD, and other unix systems never had their own video drivers.

However, as Linux modernized, it now has video drivers, otherwise known as the "Linux Framebuffer." The idea is really cool. You can insmod / rmmod a video driver, just like any other Linux driver, and the video device is /dev/fb0 (and so on) just like any other device. Unfortunately, the Linux Framebuffer is severely underused, and so many cards are unsupported and the drivers are not very optimized. In contrast, XFree86's drivers are a lot more mature.

DirectFB is an API that layers over the Linux Framebuffer. It's sorta like DirectX, in that there is a HAL/HEL system (if your card doesn't support a certain feature, for instance such as alphablending, DirectFB will do it in software for you). However, DirectFB is not intended for just games, like DirectX often is reserved for.

I believe with DirectFB you can run multiple framebuffer apps at once. QT/E takes over whole screen and input device so no framebuffer app can coexist on the same screen. QT/E also typically includes its own window manager and launcher.

To the best of my knowledge, the most restrictive "compatible" license sets the course for the rest. That is, while you can run LGPL'ed software on a GPL'ed library, you can't take advantage of the extra "freedoms" of the LGPL.

So if you try to extend an LGPL program that interfaces to GPL'ed code, you must avoid violating the terms of the GPL. *I think.*

Well, you don't run QPL, but not GPL, compatible applications on a GPL-only Qt. That is not absurd in any way, shape, or form, if you really think about it. You can't expect closed source KDE apps to somehow be compatible with GPL'ed Qt just because kdelibs are LGPL'ed. The higher level LGPL can't force its will on the lower level GPL'ed library.

Thus, proprietary apps like theKompany's Kapital will need to remain on Qt/X11.

DirectFB isnt an X replacement. fresco aims to be, DirectFB doesnt. and fresco can run on top of DirectFB, as fresco isnt concerned about direct hardware access. The most supported fresco interface is GGI... the general graphics interface. That would make GGI the graphics layer which is similar to how DirectFB would be the graphics layer, except that GGI is just an interface and is itself a layer on top of another layer (like SDL, XFree, or even.... DirectFB).

fresco does not talk to hardware directly.

DirectFB isnt a windowing system but JUST the graphics layer (and mouse handling, etc) that talks to hardware.

XFree86 is a windowing system and also accesses hardware directly.

XDirectFB is a port of XFree86 to use DirectFB for it's hardware access.

QT is a toolkit that draws widgets (essentially, but does other things).

I hope this explains why fresco has nothing to do with this article at all. :)

Introducing it should be noted, that DirectFB is a project of a german company called "Convergence" (http://www.convergence.de), who has several projects besides "DirectFB" in their pipline which include:

the DVB (Digital Video Broadcast, the standard for digital television in the EU) driver for Linux on the first available cards (based on a reference design by Technotrend)

and a reference implmenentation of the MHP (Multimedia Home Platform) for Linux, (which itself uses DVB as transport-mechanism).

There also exist other projects, having mainly to do with MPEG2 encoding and replay (DVB as well as DVD are MPEG2 based).

From these projects, all hosted on http://www.linuxtv.org, and from reading the companies website one should get a clearer picture.

This stuff is not being developed to replace X11 anytime soon. Instead it is an essential part to provide STB projects with a high-level graphics engine and assorted media frameworks. This stuff is not about your average "desktop", it is about Digital Convergence devices. Toucscreens, TV screens and VGA displays of course. Portable, STB, AV devices, not desktop-PCs. And as such the gfx-card manufacturers are more or less interested. Maybe the best example is the nearly complete support for the TVIA CyberPro 5xxx. The CyberPro is a powerfull (I have been told) graphics engine that gets used in STB (http://www.allwell.tv uses them, i.e.) with Video, TV and PiP support and some other "goodies", that you will require when using the TV.

And this is where "translucency" is not a playfull feature but a very good thing. One may think about OSDs (on screen displays) and similare. So it is a framebuffer with a mutlimedia/entertainment bias.

So all these ppl here who are standing up the front with their swords raised and their flags having a nice 95% banner should try to look at the world a bit more differenciated. The fact, that now QT, formerly GTK+ and parts of XFree got ported is just a win for all of us, especially who use DirectFB as part of their HTPC system (check out http://byzgl.sourceforge.net as an example distro) and want to do more than running some spare apps. Additionally it is good to see, that software like MPlayer supports DirectFB natively.

If DirectFB progresses and gets some better hardware support (blame the manufacturers for closing their drivers) not much would be needed in order to create a powerful embedded (sort of) MultiMedia engine on top of Linux.

All that I personally miss (I did not buy a G550DH by accident when building my MediaServer...) is a port of Mozilla. There is even two MPlayer plugins for Moz. Use your fantasy !