Slashdot Mirror
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.
It sounds like a great project but native driver support and linux, whoa back right up. For most consumer hardware that is far form a reality. Personally I have an ATI card so this is good for me but it may take quite a while to ad support for others. I can't wait to give it a try though should be exciting to see and work with because gui speed definently is lacking in the major desktops for linux which just slows down the programs that run on them.
Checking out my form of escapism.
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 ;)
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
"The embedded-1-branch of Mesa is a port of DRI to the framebuffer device (fullscreen only, no input). Currently supported are ATI and Matrox (after porting the driver a few days ago)".
Once again NVIDIA is not supported. NVIDIA wake up and release your specs and manuals under NDA to the developers. You are only hurting yourself by denying your product less acceptance in the open source world. And for the NVIDIA supports open source argument try moving between X versions and see how well your NVIDIA card is supported with all the bells and whistles you thought you paid for.
Anyone know where I can find a MATROX AGP 1x card?
A disgruntled NVIDIA customer.
It's tailored for gentoo, but most stuff applies to most distributions I guess. Not that I'm using them. ;)
o r
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
http://www.bootsplash.org/silent-mode.jpg
Files can be recived from
http://www.bootsplash.org/
I'm too stupid to preview.
Screenshots are available.
~ s/are/were/
Karma: The shiznight, mostly because I am the Drizzle.
That almost made sense until you started ranting about Gnome being obsolete.
I don't use KDE or Gnome, but I do think that the choice is a good thing.
If you would port Qt to DirectFB... what would manage your windows? How could DCOP work without authentication over X11? What server manages drag&drop and cut&paste?
X11 does far more important stuff than only letting you access the framebuffer.
Beside that, no mainstream system will have a chance to succeed if it only fulfills the needs of 95% of the users. Unless you get 100% it doesnt have a chance. MS understands this, thats why they have put *a*lot* of effort into the Terminal Services and RDP.
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.
That's one of the stupidest things I've ever heard. It's a retrograde step. The reason that X has been around for so long is because it's a design that works. Hell, even NT, 2K and XP have client server graphics at the core, just not as good as X.
The problem with Linux is not the X design but the implementation. XFree is rather boaty and slow. What we need is a new version of X rather than to throw away the protocol. There are plenty of established extensions to support graphics, overlays and the like when you need them.
You must also remember that Linux != UNIX. X wouldn't die even if the kiddies stopped using it on their Lienucks boxes. I have Solaris and IRIX machines at home which use X. Your NVidia graphics card was probably designed with the help of engineers who developed IRIX's X implementation.
If someone wants to do a framebuffer implementation than fine. The whole point of open source is that it allows choice. If someone wants something and they are willing to develop it for the community, that's great. Open source also exhibits evolution, survival of the fittest. Those which are are found wanting fall by the wayside.
X is still here because it works, plain and simple. Throwing it away would be madness.
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
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.
The Anti-Blog
Let's fork XFree, merge it magically with DireectFB and produce a lightweight X-windows brother...
:)
Then, let us call it DirectX.
I've noticed that a lot of the discussion on DirectFB is like all other X 'replacements' -- half the people talk about how great it will be because it will jettison the useless bloat in what they call outdated technology, while the other half rail about the loss of the network-transparency that they can't live without.
Well, this may seem naive, but maybe both sides are right? I mean, sure, network-transparency is wonderful but how many people are really using it? 1 in 20? Maybe? At the same time though, that one person is probably using it for somthing uber-useful, like eliminating 200 desktops in lieu of dummy terminals :)
So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular? Why can't you have a well-written, clean API (I've heard horror stories from people who've had to write code directly to X) that lets you plugin in modules like 'network-transparency' or 'anti-alisased fonts', or even everyone's favourite 'alpha-blended windows'?
I'm not saying this would be trivial, but surely it'd be worth the time and effort so that the 95% of users who don't want it can simply turn off network-transparency, and the 5% who do can plug it in without a lot of hassle.
As I said, surely this is naive. So flame away.
Wood Shavings!
- Godai
Why is the parent modded as flamebait?
/. article demonstrates precisely the downsides of closed hardware (implied from closed source drivers), ie the open source community cant hack on them and do new things with them.
The post is 100% correct, this
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
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?
"Crowd: X is bloated
i endly-Windows-XP has millions of code too.
o u-no-matter-how-uninformed-we-are"-zealot.
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-fr
"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-y
I read that as "DRI Comes to DirectFBI", and just couldn't understand what DirectFBI is... DirectSound, DirectX, DirectFeds?!
Ahem....
DirectFBI's communication protocol is FedX.
Your answer is exactly the attitude of the X people/defenders I wanted to critizize. Basically the attidude X does everything right there are always others to blame.
:-)
:-)
But lets go back to the arguments. Your speed argument is exactly what I wanted to point out
(X is not slow I compared X to X), face it no matter what window manager, put an X box side to side to a MacOSX Jaguar box or WinXP box and you will see that both later ones outperform your fabolous X box by the factor two til three. That KDE is another drag on the whole performance is another issue. As for your network argument, you picked up pretty much the only app which you can tunnel via a modem connection, the fact that an entire RDP Desktop needs as much bandwidh as xterm alone should say a lot.
As for your compatiblity argument. 99.9% of the most important apps sit on top of toolkits, now if qt and gtk2 are ported (gtk already is) see people flock away from X left and right.
Again Xterm probably besides some other stone old apps will be one of the apps which won't be portable.
XV, nice argument, but you know were the DirectFB project developed from, there won't be too much need of XV then
As for bloat. 7 millikn lines of code for a simple windowing system is bloat (as for m%$ windows it has around 10 million lines but only a fraction of that goes into GDI and other directly windowing related stuff) and basically unmaintainable, constant reports of bugfixes never worked in
in various forums pretty much resemble what I assume.
Just another question, now that you have given valid arguments, why do 99% of all X apps implement things wrong
Not necessarily. In the default Sharp install, running Java programs (as one example) will create movable windows that partially obscure programs below them. There is a simple kind of "window manager" behavior going on.
Also, it is completely possible to rearrange file permissions so that Qt on the Zaurus can run as non-root. Why Sharp chose not to do this is difficult to imagine.
"Your answer is exactly the attitude of the X people/defenders I wanted to critizize."
I don't know if you are the same AC as the one I'm replying to, but this sentence imply you are.
"Basically the attidude X does everything right there are always others to blame."
X doesn't do everything right. But there are other things to blame.
And I critisize people like you because of your attitude: the attitude that all bad things in the world is because of X and that it must die off no matter what.
"But lets go back to the arguments. Your speed argument is exactly what I wanted to point out
(X is not slow I compared X to X)"
OK if absolute numbers from x11perf aren't enough I'll show you my results from a Windows ME - XFree86 comparison.
A year ago I wrote an app in SDL that blits 1000 640x480 surfaces and calculates the average frames per second.
On Linux, I compiled it with no optimizations (gcc 2.96). The SDL binaries are from RedHat: optimized for i386.
On Windows, I compiled SDL manually using Mingw (gcc 2.95) with Pentium optimization, and the testing app (no code modified) with no optimizations.
Then I ran the test app in both Linux and Windows. I expected the Linux version so show a slightly lower FPS because of the IPC/driver/whatever overhead. But surprisingly, the FPS in Linux is VERY close to FPS in Windows. The FPS in Windows is like 2 frames higher than the FPS in Linux. I repeated the test several times and sometimes the Linux FPS is slightly higher, sometimes equal and sometimes slightly lower.
Conclusion: on my system, XFree86 is just as fast as Windows ME in blitting. The differences are caused by other processes and other random stuff.
"face it no matter what window manager, put an X box side to side to a MacOSX Jaguar box or WinXP box and you will see that both later ones outperform your fabolous X box by the factor two til three."
Not on my machine. See above.
"the fact that an entire RDP Desktop needs as much bandwidh as xterm alone should say a lot."
I've never used RDP before so I'm not going to comment on this.
"As for your compatiblity argument. 99.9% of the most important apps sit on top of toolkits, now if qt and gtk2 are ported (gtk already is) see people flock away from X left and right."
Right, just take a look at the Nautilus/kde-libs/gnome-panel source code. You can find lots of references to xlib functions.
"As for bloat. 7 millikn lines of code for a simple windowing system is bloat (as for m%$ windows it has around 10 million lines but only a fraction of that goes into GDI and other directly windowing related stuff)"
How do you know how many lines code the GDI has? (*insert scary music here*)
Windows by default doesn't ship all drivers for all video cards. XFree86 on the other hand ships *all* drivers it has. I think it would be more fair to compare XFree86 minus drivers with Windows GDI minus drivers.
"and basically unmaintainable, constant reports of bugfixes never worked in in various forums pretty much resemble what I assume."
I think that has more to do with their organization than X's architecture. And that's exactly what Keith Packard is protesting against.
If there's something better than X, in all areas, then by all means go ahead and replace X. But there is no such thing. DirectFB is not a worthy full replacement for X and is not finished yet. Fresco is far from usable. GGI is stalled. What else is left?
Until somebody comes up with something significantly better, we should fix existing thins rather than complaining over and over that X is the root of all evil and that it must die.
Sticking feathers up your butt does not make you a chicken - Tyler Durden