JUL
19
2003

GPL'ed Qt on DirectFB!

The first, very-alpha, release of the Qt library on
DirectFB 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

Here's the scoop:

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.

Oh, and before anyone says that DirectFB is an X replacement, let me remind you:
* XFree86 = graphics layer + 100 other important things
* DirectFB = graphics layer

Personally, I'd just like to see DirectFB used as a replacement for the XFree86 graphics layer. In fact, you can already do this with XDirectFB (it's a port of XFree86 to DirectFB).


By Justin at Mon, 2003/07/21 - 5:00am

You're right. Correct me if I'm wrong but it seems that with XDirectFB you get all the benefits of DirectFB without loosing the benefits of X.


By grouch at Mon, 2003/07/21 - 5:00am

It should be possible (possibly even easy) to port Konqueror embedded to this platform. Anyone up to the job?

Rich.


By Richard Moore at Mon, 2003/07/21 - 5:00am

What's the difference between this and QT/Embedded? I thought QT/Embedded was Qt ported to the frame buffer and that Konqueror runs on QT/E already.


By cbcbcb at Mon, 2003/07/21 - 5:00am

It is very similar. Qt/Embedded accesses your /dev/fb device directly, while the Qt in this news article uses the DirectFB API.

Going through DirectFB is a more sensible approach, as it provides software fallback for all operations.


By Justin at Mon, 2003/07/21 - 5:00am

Qt/E drivers also provide fallbacks for operations not available in hardware.

Although I am still happy to see Qt on DirectFB, just for different reasons.


By Ian. at Mon, 2003/07/21 - 5:00am

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.


By Frauke at Wed, 2003/09/03 - 5:00am

Yes, you need a process with root permissions to coordinate them and a special kernel module for communication between them.


By AC at Wed, 2003/09/03 - 5:00am

> A lot of things still have to be implemented, so please don't expect
> to be able to run Konqueror on DirectFB (yet).

The KDE libraries are licensed under the LGPL. We can run LGPL'd code on top of QT because of the Q Public License. Is it legal to run LGPL'd libraries on top of a GPL'd toolkit?


By Burrhus at Mon, 2003/07/21 - 5:00am

Yes, the LGPL and GPL are fully compatible, just like the GPL and BSD licenses are.

-Tim


By Timothy R. Butler at Mon, 2003/07/21 - 5:00am

> Yes, the LGPL and GPL are fully compatible, just like the
> GPL and BSD licenses are.

I thought the compatibility only went one direction. You could run GPL code on top of LGPL, but not the other way around.

http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

What is to stop someone from creating an LGPL interface to GPL'd code, and then extending the system with proprietary code?


By Burrhus at Mon, 2003/07/21 - 5:00am

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.*


By Timothy R. Butler at Mon, 2003/07/21 - 5:00am

> 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.*

By that logic, all closed source KDE applications will suddenly violate the GPL as soon as KDE is ported to a GPL-only QT. That is naturally absurd.

The whole point of the LGPL (originally the LIBRARY General Public License), was to avoid the licensing issues with GPL'd libraries.


By Burrhus at Mon, 2003/07/21 - 5:00am

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.

-Tim


By Timothy R. Butler at Mon, 2003/07/21 - 5:00am

what's about fresco? i think this could be a X replacement (full hardware accellerated AND full network transparent):
http://fresco.org/


By panzi at Mon, 2003/07/21 - 5:00am

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. :)


By LV at Mon, 2003/07/21 - 5:00am

Is directfb responsible for the alpha-blending on Anna Falchi's top (in the screenshots)? If so, it must be some very clever software.


By nonamenobody at Tue, 2003/07/22 - 5:00am

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)

dietlibc - a "thin" libc implementation

DirectFB - a hardware accelerated framebuffer (http://www.directfb.org)

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 !


By .jon at Wed, 2003/07/23 - 5:00am

Pages