DRI Comes to DirectFB

Pivot writes "To further heat up the discussion about the future of the graphical desktop on open source OSes: Now the DirectFB project works with DRI!. Screenshots are available. I guess what is lacking now is only XAA driver support, or native drivers for your favourite graphic card." We've mentioned DirectFB before.

Comments

Here we go....

[IamTheRealMike]

I was wondering when this one would show up on Slashdot. A few thoughts:

1) Today, DirectFB can do some things XFree cannot, but the reverse is also true. But, the XFree infrastructure could be (and will be) upgraded to do stuff like full use of hardware accelerations, proper save unders, alpha blended windows and so on. DirectFB cannot gain network transparency or code portability however.

2) On the other hand, using DirectFB does not mean we lose network transparency. The X11 protocol won't disappear. If it had better hardware support, or was able to use the XFree drivers, I'd have no problem at all using this software. For apps that used GTK/Qt I'd always have the choice of network transparency when I needed it. Software written for DirectFB specifically probably isn't the sort of thing you'd want to run remotely anyway.

3) Window transparency is overrated. Window double buffering is not.

4) DirectFB still has a lot of questions to answer. AFAIK there is still not window management protocol for instance - X11 provides a lot of things most people don't think about, DirectFB would have to provide equivalents first.

5) Half the comments in this thread about XFree will be misinformed ;)

Re:Here we go....

[Yarn]

It's not designed as a windowing system, it's for embedded systems. I looked at using it for my PVR system, but I didn't like the API.

I didn't use X because it provided a whole load of functionality I don't need (windows, input devices), and didn't have some things I did need (reliable access to the BES on the video output card).

I do like X, it's great for my desktop, but it's not the only way of putting pixels on a screen, nor should it be.

Re:Here we go....

[MartinG]

DirectFB cannot gain network transparency

Not only can it gain network transparency, but it gains everything that X has functionally in the form of XDirectFB, a rootless X server that puts X compatability on a layer _above_ the windowing system. Many people believe this is where network transparency belongs rather than entangled within the windowing system.

Re:Oh, by the way...

[IamTheRealMike]

It's a thin layer on top of the kernel framebuffer driver - provides useful APIs and some other services that you need for a windowing system, like WM support. They were also working on a fast IPC mechanism called Fusion when I last checked up on them. Dunno how far that's got.

The idea is to replace X with something closer to the hardware as far as I know, but today it's mainly useful in embedded scenarios. They have a backwards compatability thing for X clients, which means if you have a supported card you can run your desktop on it and make windows transparent with the capslock key. It's fun for about 2 minutes I should imagine.

As an aside, does anybody know if the girl in that screenshot lives is single? :D

Great 'article' about how to get a nice console

[humming]

It's tailored for gentoo, but most stuff applies to most distributions I guess. Not that I'm using them. ;)

http://forums.gentoo.org/viewtopic.php?t=49036

Then you can get consoles which look like this:
http://www.alledora.co.uk/images/fb0.jpg
o r
http://www.bootsplash.org/silent-mode.jpg

Files can be recived from
http://www.bootsplash.org/

Obligatory regular expression

[Znonymous Coward]

Screenshots are available.

~ s/are/were/

Re:This will kill X in the long term.

[DrXym]

Some people need X11 and some don't. If local desktop performance and modern windowing behaviour can be achieved by completely bypassing XFree86 and its associated window manager and other processes then it should be done. After all, GTK & QT are abstractions over X11, so most apps really shouldn't care whether they're running on X11 anyway - they just link to the widget lib and let it decide how to do things. Now not every app is clean this way but a good many must be. As the app starts it would straightforward enough to dynamically link to the appropriate version of QT / GTK.

If the net result of a native fb GTK lib is that someone can run all their apps locally with better performance and less screwing around in different places configuring mice, resolution etc., and better support for their hardware and better support for games and multimedia, it means Linux is better suited for the desktop. It doesn't preclude using X11, or even running X11 in rootless mode (as it does on OS X) if people want to but it sounds like a great project to support.

And in some ways it helps Xfree86 since a single direct DRI driver can support a whole range of display hardware without XFree86 having to maintain them themselves.

Come on, I have to try...

[IamTheRealMike]

Fellow Americans! I have a message for you, that you should all heed. It should be noted that thanks to the evils of the DCMA and M$ Palladium, using the kernel to display graphics poses a grave threat to our freedoms, which were so vigourously defended by our brave soldiers in Iraq (unless you are one of those cheese eating surrender monkeys, the french *spits*).

You see, this is not a new nor innvoative technique! M$ also has some graphics in kernel - this is what allows them to pander to the MPAA/RIAA when they demand unbreakable DRM. They is almost certainly patented as a result! Do you want to be sued for playing MP3s with DeCSS on Linux? NO! There is only one choice - just say no to having your multimedia use the kernel... just say no to DRM!

DirectFB puts our freedoms at risk my fellow Americans, because the government assumes that all P2P users are terrorists, as opposed to freedom loving consumerists who merely wish to try before they buy. Everybody knows that piracy isn't theft - how could it be, when most pirates wouldn't have even bought a copy anyway?

So you see, if people use DirectFB you don't only lose network transparency (who uses that anyway?) - you lose something far more important - your FREEDOM. With X, at least you can swap out XFree for another server, becuase being BSD licensed means it is truly Free, unlike that pinko commie Linux kernel.

Karma: Was Excellent, Before I Posted This
Karma: Was Excellent, Before I Posted This

Re:This will kill X in the long term.

[Christianfreak]

Face it: we don't need X any longer.

Then why is it that Microsoft keeps trying to copy it (failing miserable) ala Remote Desktop etc.? I for one would love a handheld device that gave me complete control over my home machine from anywhere it the world. You can't do that without a network GUI.

X is bloated and you compare it to "High Performance" Win XP? From what I have seen XP is useless on machines less than Athlon or PIII, and even then it starts slowing down if you have more than a few apps open, while my wife can run Mandrake 9 with full blown KDE, Mozilla and Open Office (even at the same time) on a K6-2 450 with only 192 megs of RAM. Its not the snappest machine in the world but its useable enough that I don't get annoyed at it. Its even faster when I run Blackbox.

KDE works automatically. And this would weed out Gnome this obsolete, second desktop system which just draws resources from the KDE pool and thus slows down advancement of open source systems.

If you want your apps and look and feel dictated to you then go back to Windows because that's what its for. No choice, you can feel good that everybody just uses what is handed to them. Linux is about choice. While I agree that Gnome and KDE could work better together (and should strive for that goal) I would be extremely upset if the people that work on Blackbox, or GAIM or Mozilla decided they were going to work on KDE apps instead. I like the GNOME apps I use, I like Mozilla and no one has the right to dictate those choices to me.

Open Source development isn't about what everyone wants, its about what the developer wants and she/he's nice enough to give that to other people in case its useful to them and they are free to do with it what they want.

Finally are you a KDE developer? because if not then you certainly don't have any right to complain about other people not working on the project you want them to work on.

X and networking

[ceswiedler]

To prevent uninformed comments about X:

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

Look here for an explanation of what Unix domain sockets are. They have nothing to do with networking and are the most efficient form of IPC on Linux. As a bonus, you can write code which uses either AF_UNIX sockets or AF_INET (TCP/IP) sockets seamlessly--but AF_UNIX sockets still have nothing to do with networking. Got it?

Re:Usual discussion

[FooBarWidget]

"Crowd: X is bloated
X DefenderS: X is not bloated it is just everything else on top of X"

Proof: use twm/fvwm/IceWM/BlackBox/Xfce. Behold the speed.

GNOME and KDE are slow, X is not.

"Crowd: Network Transparency is a hog
X Defenders:No it isn't there is just not a single app which does it right,"

Proof: try running xterm remotely. Now, do the same thing with Konsole and Gnome-terminal (2.x). Behold the difference in speed.

It is also important to know that XFree86 does not use TCP/IP locally! Pixmaps are transferred using shared memory. Other (significantly smaller) data are transferred using a Unix Domain Socket, which is just as fast as shared memory (at least on Linux).

"Crowd: X is slow
X Defenders: No it isn't run two X servers side by side and see that they have comparable speed"

I've never heard of an X defender say such a stupid thing. Obviously you made this up. That makes you a liar.

Anyway, it can be proven that X is not slow. Run the x11perf benchmarking utility:
x11perf -rect500
x11perf -repeat 3 -shmput500

On my system (ATI Rage 128, Athlon 1,4 Ghz), XFree86 can:
- Draw 1190 500x500 rectangles per second (1190 fps).
- Blit 210 500x500 square images per second (210 fps).
- Scroll 530 500x500 pixels per second (530 fps).

There, I have numbers. Now show me your numbers that X is slow.
However, if x11perf *does* report significantly lower framerates on your machine, then that only proofs that the main bottleneck is drivers, not X itself.

Crowd: X is bloatware
X Defenders: No every single line of the 7 million lines of code is needed, even the code from the flight sim"

Lots of code does not equal bloat. I'm sure you already know that, but you only say this to troll.
The oh-so-high-performance-and-oh-so-consitent-and-fri endly-Windows-XP has millions of code too.

"Crowd: Look there is something better and faster
X Defenders: We don't need that we have network transparency (which implicietly is unusable over slower lines)"

Except DirectFB is not better and faster. Hello, there's more about a windowing system than just drawing pictures!
- Even with this OpenGL/DRI backend, DirectFB still doesn't support nearly as many video cards as XFree86.
- What about inter-process communication? Like drag & drop or event notification?
- Where's the compatibility? You can't expect everybody to rewrite their app for DirectFB. Oh sure there's XDirectFB, but 1) doesn't that make the whole point of ditching X a joke and put us right where we started? 2) does it support important extensions like Xrender, Xshm and XVideo?

You are just another "we-are-the-biggest-group-so-we-are-better-than-yo u-no-matter-how-uninformed-we-are"-zealot.

Re:Naive Question

[Paul Jakma]

First of X is not that bloated - have a look at TinyX (part of the XFree tree), its 868 kilobytes in size and is currently using about 5.9MB of RAM on my Ipaq (868KB for the exe, 2MB for libraries and just 2.6MB for data - and thats with a few apps open too).

People who say X is bloated are either ignorant or liers.

Also, X provides things which plain framebuffers do not which must /still/ be done somewhere if one wishes to actually have more than one app displaying to that framebuffer, ie arbitration. If you look at toolkits designed for plain fb's, eg QtEmbedded, they have a good bit of code in them to allow for arbitration between different apps for access to the framebuffer (and hey, now you need scheduling code too!). Iirc, there was an interview with one of the guys who was involved early on with the Berlin project, and he said that by time they had all the things needed to allow apps to work together on displays they werent far off the size of an X server anyway.

Also, often when people blame X for bloat they're blaming the wrong thing. They see X taking up 80MB on their desktop and go "oh bloated" - but in all probability it is all your fancy graphical apps not cleaning up the pixmaps they create as they go along! Fix the apps!