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 ;)
I read that as "DRI Comes to DirectFBI", and just couldn't understand what DirectFBI is... DirectSound, DirectX, DirectFeds?!
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.
Embedded devices are probably _the_ place where DirectFB makes the most sense. These don't have the same needs a desktop has, and lack the network interfaces (right now, I guess) to make the networking features of X useful.
However... I don't see any point in moving DirectFB to the desktop, or using it anywhere that has a network interface and the appropriate hardware to run X. There are many, many areas where X makes a lot of sense (even in embedded devices!), and DirectFB is not going to be performance panacea that some people make it out to be. It's going to be best as a "light" display system for embedded hardware, IMHO.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
I use X, running apps off of a central development server. ddd over the network anyone? Every Windows box here even has an X server installed. I use X at home, and often run apps from home when at work using you gessed it, the X protocol.
I need X.
As for Linux not being a "real gaming platform", hardware accelerated OpenGL is fast enough on linux. And if you actually can get the specs to your graphics hardware, as in the PS2 linux kit,
there's nothing stopping you from writing "real games". SDL give you everything you need, running on XFree86, framebuffer, etc.
PS I write games for a living.
Dave
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.
Dirty Rotten Imbiciles are going to work on a free and open project...glad to see punk music making the "crossover" with computers.... ...oh wait
So rise up, all ye lost ones, as one, we'll claw the clouds.
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
All good questions. I'm not knowledgeable about the internal workings of Qt/Embedded, but I know my Sharp Zaurus runs a version of Qt without running X at all.
But, in case you didnt notice, you always see one app at a time and everything runs as root.
Cos anyone with any real experience uses remote displays regularly.
We use it for engineers, for secretaries, for managers, for salesmen, for janitors even, but it seems that script kiddies like you don't use it.
BTW, You wanna know why xterminals are still used and why the X protocol is more important today than it's ever been before? Nothing to do with hardware costs these days. It's because 1 administrator can manage hundreds or thousands of desktops, with ease. Wanna know what the single largest set of costs in I.T. are? Support. Those dozens of wintel administrators needed to manage the big iron mainframes under every desk.
Face it, you're a moron.
Government of the people, by corporate executives, for corporate profits.
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.
I was wondering the same reason. Why cant DirectFB be the driver/interface for the Display, and let Xfree just port the Xserver to the OS. Xfree doesnt need Driver support anymore, All drivers are for DirectFB now.
Xfree for cygwin doesnt care what GFX card I use, and I can use it in rootless mode. Only thing I wonder is if Xfree can support all the hardware features in DirectFB. (And widget support doesnt rely on the gfx card, just the xserver, so no problem with X network transperancy)
Sounds like a great Idea to me, let xfree be a straight xserver, and let DirectFB handle the gfx drivers. (Then we dont have to wait for Xfree to put the driver fixes that has been shelved for months, example ATI's submissions, and the reason for the Xfree spinoff.)
Dirty Rotten Imbeciles, a great early punk/thrash crossover band.
Let's fork XFree, merge it magically with DireectFB and produce a lightweight X-windows brother...
:)
Then, let us call it DirectX.
I have to second this notion. I've always looked at Unix/Linux as the ultimate pick-and-choose OS .. I can build in what functionaility I need and get rid of functionaility that I don't need. Unlike Windows where lots of apps are bundled (IE, Outlook Express, etc..etc..), Linux gives me the freedom to customize virtually every aspect of my system...
well except one --> X11.. It might be great for a network / sysadmin configuration, but for a desktop, it blows. With so much activity happening at the desktop, it is imperitive that X11 be REMOVED!
We need to back something like DirectFB that will allow for a much more responsive interface, an interface that can meet the needs of desktop users and provide for the needs of the desktop Linux user. Like Apple, if X11 is needed, it should be provided in-addition-to the core fast desktop.
It would be pretty cool... :) Not quite sure of the likelihood or feesibility of such an undertaking, but definitely something to think about.
Wow, another DRI reunion tour? Any original members on board this time?
wordclock records
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
Heck, even if it IS a KDE developer, then he STILL doesn't have any right to complain about other people not working on the project he wants them to work on.
I'm sorry, how does remote desktop fail to do the things we really want from X? Admittedly it does not allow you to run single applications on your existing desktop, but what we really want it for is for logging into systems remotely and doing maintenance. It also does things which X doesn't do without addons, such as audio redirection. (I know you can use network audio daemons but now you have another network connection to make. It's fairly trivial to add it if you're already using ssh tunneling but otherwise it can be a network annoyance.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Rather worryingly, it's at -1 Funny and yet no "Overrated" mods are shown in the box below - considering that overrated moderations are no longer shown and are not meta-moderated, this seems like a wide open hole for people who want to abuse the moderation system. What is the reason for this inconsistancy? Why is overrated/underrated special?
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.
...you know, a 21st Century version of the GUI by (Intergalactic) Digital Research, Inc. (DRI)... you know, the originators of DOS, when it was known as *cough* *cough* C/PM... I'll go find my Atari ST for comfort...
"Right now, somewhere in this world, Scott Baio is plowing a woman he doesn't love," - Peter Griffin, *Family Guy*
Other people have said it, but you are so wrong I have to say it again. Remote Desktop and Terminal Services are not failures. They're the only way we can serve database-intensive applications to remote sites on slow connections.
Microsoft has got some things right. Deal with it.
irb(main):001:0>
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 wrote the blitting function for the nvidia DirectFB driver. I had to take the code from the radeonfb driver. They didn't have a working blitter when I was into directfb awhile ago.
I still like DirectFB, and would like to see better support for hardware in it. Then I'd probably ditch my XFree86, and run DFBX exclusively.
BTW: the nvidia blitter is still probably hacked together, and hasn't ever supported transparency.
I am unamerican, and proud of it!
%s/a great/the great/g
/.
Cool that DRI is getting some good plugs on
(+1 Funny) only if I laugh out loud.
There are open source drivers for Radeon Mobility chips in XFree86 4.3.0 and in the DRI. That covers 2D and 3D. What were you hoping for?
Think hard. Imagine how network transparency would be "added on" to an API that is designed to not be network transparent, for instance one that uses shared memory to read/write to the screen pixels.
Answer: it is not possible. Network transparency requires design considerations in the API. Fortunately these requirements are exactly the same as are needed for all security and stability reasons so that crashing programs or hostile programs cannot take down the window system.
X already bypasses network code when the system is local. This is the only way to make "network transparency" a "plugin", and it is already being done.
Why is X slow? It is because of the horrid design of the Xlib api so that lots of graphics are impossible without huge amounts of communication, and because of huge numbers of synchronous value-returning calls (a mistake done, interestingly enough, because the designers were using local servers with low latency, thinking about the network would have prevented this), and because of the seperate window manager that makes synchronous update impossible no matter how fast your hardware or communication is.
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
Can I ask you a question? What exactly does this have to do with DRI and DirectFB?
That's two questions. The answer to the first is "Yes", and the answer to the second is a complaint that drivers are rather difficult to install in Linux compared with just about any non MS OS. Said complaint was quite rightly modded down as a troll.
1. Compile your kernel without module versioning.
Can I do that? Fair enough. I'll look into it.
2. Good luck getting it signed. However, that's up to you. Most people don't understand what a driver does, much less why one would need to be written.
It's not essential to get it signed. Even XP will still use unsigned drivers, and unless MS want to annoy a lot of developers by forcing them to use a special "development" version of windows. Generally speaking nobody needs to do write drivers.
Really? The Linux kernel (the Linus tree, in particular) contains lots of driver code for hardware I'm sure Linus doesn't personally own. A lot of risky changes are meant for architectures that Linus doesn't have, or may not even have seen. In fact, it may be interesting to see what percentage of Linux (in terms of lines of code or whatever) Linus personally uses.
Yet Linus accommodates these changes, and adds them to his tree. They make Linux a better product for many other people, even though it does less than nothing (any feature you don't need is an unnecessary potential bug) for him. Do you think Linux would be nearly as successful if Linus refused patches for any hardware he didn't own?
Sure, the developer can do whatever he or she wants, but the successful projects keep their users in mind.
The parent to your article was IMHO a flamebait, as judged by the phrase "high-performance Windows XP". I don't think any serious /. reader thinks Windows any version is more "high-performance" than some version or clone of Unix. Prove me wrong!
YHBT. YHL. HAND.
-uso.
High performance?
C:\>_
Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
I thought FreeBSD at least was binary-compatible with Linux. And isn't Solaris able to emulate Linux as well? :\
-uso.
(-1 Redundant, so go ahead and mod me down)
Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
I think the hardware manufacturers worry too much about information leakage due to drivers. Their worry being real however I think a good solution would be closed source drivers for say 3-5 years after a card is released followed by the release of all specs + driver source. This ensures that older technology can be supported on all systems and for many years to come while at the same time protecting the cutting edge stuff. I'd hate to have Linux have the same problems as windows versions with binary only drivers.
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.
100x a faat PC isn't really that much. I wouldn't be such a braggert.
Newer models (sl5600, slc700) run as a non-root user.
A lot of manufacturers aren't supporting the community. Know what that means don't you?
Which community?
You're exposed to the development model. While in a closed-source OS (BeOS), the process is hidden from you. For all you know the (former) BeOS developers could have been wrangling with the same issues as you, but since the majority are never exposed to that. They believe that something mysterious and magical is happening when they go to use their computers.
I don't give a damn. As long as it works.
Don't tell me to use Windows just because the GNOME project isn't capable of tight integration.
Stating on Slashdot that I like cheese since 1997.
"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.
"And besides, INET sockets aren't all that much slower than UNIX sockets. Both are incredibly slow next to no IPC (shared memory)."
This is not true.
First, shared memory *is* a form is IPC. If it isn't IPC it wouldn't be called "shared".
Second, on Linux, Unix Domain Sockets are just as fast as shared memory. There has been an attempt to make XFree86 communicate entirely using shared memory. But it turned out that Linux's Unix Domain Socket implementation is just too efficient and that there is almost no performance gain.
"Some Xservers I thought used shared memory for large objects also."
Like XFree86...
"If you look at Windows, they got an enormous speed boost by making as many APIs as possible run right in the user memory space and making the ones that couldn't do that run in the kernel space."
See my other posts. I did a benchmark. On my machine, Windows is NOT faster than XFree86 when it comes to pure frames per second! My benchmark says they're both just as fast.
The main bottleneck is and remains to be drivers. The XFree86 driver for ATI Rage 128 is good, so I get the same performance as in Windows.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Binary compatible != kernel module compatible.
A big part of DirectFB is implemented in kernel space.
THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT
THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT
THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT
Got it? Good! Stop the nonsense regarding X! Stop trying to throw out the baby with the bathwater.
Network transparency is used by a lot of people. Network transparency does not slow down X locally. Network transparency does not add considerable bloat.
Blah blah blah. Stop the insanity!
Sticking feathers up your butt does not make you a chicken - Tyler Durden
This has nothing to do with Linus accepting or refusing patches. The issue would be if IBM came to Linus and said "Hey Linus we need Linux to work on our big mainframes, but we aren't going to help you or pay you to do that we just want it to work." Would Linus agree to that, probably not. That's what I'm talking about here. In Open Source the users should contribute, and if they don't they shouldn't complain about features lacking or not lacking.
It isn't about wheither or not developers should listen to users (they should) but its about wheither developers should take seriously one person who's screaming "Fundamentally change Linux because I said"
The Anti-Blog
I didn't say that people who like KDE should go to Windows. I told the parent poster to go use Windows if he wanted an OS where the graphical interface is (mostly) dictated to him.
If you like KDE, fine, use KDE, you have that choice. I like a combination of Blackbox with GNOME and KDE apps better, I don't want to be forced to use KDE which was what the parent was suggesting.
The Anti-Blog
I'm well aware of what X has to offer. I was responding to the assertion that Microsoft had somehow failed to deliver with Remote Desktop and Terminal Services. And not only do I not give a shit who did it first, but the software we need to serve doesn't run on Linux, making any comparison academic at best.
irb(main):001:0>
Heh. Of course, there's the whole issue where the high-end open source drivers don't perform nearly as well as the closed sourced ones. ;-)
:(
;-)
This is isn't a problem with open-source, simply the fact that the closed source drivers are better, currently.
Granted, a better kernel interface for this kind of stuff would elminate the whole problem; it shouldn't need porting of a _driver_ between different user-space systems.
(Sure I'll receive flak for this opinion on the AP list now.
I am no expert on how every layer of a windowing system interacts. I do know however that on exactly the same hardware, if I use XFree86 with the Nvidia drivers, instead of Windows XP/2000/98, the screen takes longer to redraw, applications take longer to load up. XFree86 *FEELS* slower than windows. As long as this happens, average people (like me) will feel reluctant to use *nix as their desktop. Why not take a tip from Apple. It should be possible to have a version of XFree86 that takes full advantage of a modern graphics card. I believe that OS 10.2 uses OpenGL for the entire interface?
--------- I have no signature
"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?"
No.
You are missing the point. The point is to directly render all local desktops. Why on earth would you indirectly render your local desktop just because you are too lazy to implement a direct rendered model? That is the objective of DirectFB:
To implement the X protocol OVER a direct rendered local model, rather than implementing local models over X's indirect model. (note, this is how X clients work in win32))
The problem with all you X zealots that think you are god and all knowing is that you actually don't know everything. And you have proven this in your post.
Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
Signals and semaphores can only send a few bits of meaningful info.
Qualify that to "unix/linux semaphores" and you may be right. But not in general.
There is a variant of semaphores called "communicating semaphores" that explicitly manages queues - of messages waiting for processes, or processes waiting for messages. They can be impelmented to handle messages of arbitrary size, and yet still perform all the other primitive operations needed in an OS kernel.
With a single mechanism handling interprocess communication, interrupt handler/driver communication, producer/consumer data streaming, mutual exclusion, signaling, memory and other resource allocation and arbitration, you can build a real-time OS kernel with actor-based applications in a HYSTERICALLY tiny amount of code.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
X maps the entire video ram. So if you have an 8MB card, then 8MB of X's supposed memory usage is actually mapped video ram. X can use the remaining 5 MB (eg 3MB used for display from your example) of video ram to store pixmaps, etc.. (google for XAA - X acceleration architecture iirc). If you have a 32MB card, then X will be at least 32MB in size, if you have a super duper 128MB card, X will be at least 128MB in size - just because of the VRAM mapping.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
I second that. I have also done benchmarks. X is comparable to DirectDraw in terms of speed in blitting, and a good deal faster in primitive drawing (since DirectDraw doesn't accelerate that :). Now that finals are over, maybe it's time to properly write up some of these and post them.
A deep unwavering belief is a sure sign you're missing something...
Actually, modern glibc uses mmap() instead of sbrk() to allocate memory in many cases. mmap()ed segments get returned to the system at munmap() time.
DNA just wants to be free...
You misread something as having "FBI" in it.
"DirectFeds." You're right. That is hilarious and warranted posting about it.
"Sufferin' succotash."
The main problem is that 3D is a whole different kettle of fish than 2D. The 'nv' 2D driver is 80kb compiled. The NVIDIA 3D driver is about 6MB of code, split up over a 400K X driver, a 5MB OpenGL library (libGL is vendor specific in the ICD architecture) and a 400K GLX driver. It's a whole lot more code, it's very hardware-specific, and it's a rather specialized field. The field of kernels is something else entirely. Kernel coding is a well understood field of computer science, and there are lots of OSS kernel developers who have a lot of experience in academia and the commercial industry. There is a reason why none of the DRI drivers are particularly competitive with the native Windows versions, while NVIDIA's Linux driver is pretty much equal between the two.
A deep unwavering belief is a sure sign you're missing something...
This isnt true, using the QPE libraries you only see one app at a time, but it is possible to create your apps in windowed mode ( try showing your application using QWidget::show() and not QWidget::showMaximized()). Most QPE applicaions specifically show the window as being maximized.
Also, it doesn't have to run everything as root, but it's the easiest way to do things. QT/e needs to be able to read and write to the device files for your mouse and framebuffer, but otherwise it is doable. What it does have problems with is having apps running as different users on the same display, although it is an easy enough hack to add support for running an app as root while logged in as a different user.
I believe that OS 10.2 uses OpenGL for the entire interface?
>>>>>>>>>
This is probably the millionth time I've said this. I feel like "Celebrity Jeopardy" skit where Keanu Reeves keeps saying "whoa, I know kung-fu" and Alex Trebek keeps saying "for the last time Mr. Reeves, no you don't!"
Quartz "Extreme" does not use OpenGL for "the entire interface." It's right in Apple's Siggraph paper, with pretty pictures and everything. Quartz still uses the CPU to render graphics into memory buffers. The only time OpenGL gets used is when those buffers are composited together to get the final picture. This is a step up from the previous software compositor, but other windowing systems don't even have the extra compositing step, which exists only to support the transparency and genie effects.
A deep unwavering belief is a sure sign you're missing something...
First some background. Some former co-workers who were resently layed off, along with myself, and some who were not, but see no futur, are getting ready to start writing crossplatform internet based games. We will eventuly attempt producing a Linux based game consol. As I use to fill the roll of Software Architect, and am the most familiar with Linux and graphics issues, I have been tasked with doing a preliminary design. I was investigating DirectFB. My question is, how suitable is SDL for imbeded applications? I have more questions, but need to get back to working on my resume. Obviously, outside employment will be needed to bring in money untill this project becomes profitable ( looking at years here). So no more wasting time on /.!
You can get the ck-patches against 2.4.20 if you want the interactivity updates for a stable kernel.
Are there plans to bring dual displays to DirectFB. I use it on all my systems except my main one since it's got dual displays.
You are entitled to your opinion of what should be in the open source world. I'm not trying to change your mind.
What I am pointing out is that successful projects do keep their "customers" in mind. If a security hole is discovered in Apache, by your logic, nobody can demand a patch, much less an immediate patch. That's fine, but Apache wouldn't be successful if things worked that way.
Also, it's easy to say "you should help", but the nature of software is that it is usually many times harder for anybody else to fix something than the original author. This is even more true with bigger projects. The fix from the original author is more likely to fit in well with the overall design, and be less buggy.
So I'm not arguing that you should listen to every random idiot with an opinion. However, your statement leans too far the other way, probably resulting in software that only developers will use. The freedom inherent in open source software permits higher quality software, but IMHO not if you ignore the end user too much.
I would gladly give you a +5 informative" if it was in my power.. Not today.
Yes, some of the people writing video drivers are some of the same people doing it professionally. I just learned on xwin.org today that one of those people is Mark J. who works on XAA (among other things) and also works at NVIDIA. However, I'll assert that the number of experienced 3D driver writers working on XFree are rather small compared to the number of dedicated driver guys at ATI and NVIDIA.
Also, AFAIK, none of the DRI drivers are reverse engineered. The specs of the ATI, Matrox, 3dfx, and i8xx chips are publically available. Heck, I've read the Matrox and 3Dfx docs myself.
A deep unwavering belief is a sure sign you're missing something...
I look at it this way: who has the resources and expertise to best disassemble, interpret and live-hardware-debug your video card? Is it your competitors or the OSS developer-in-the-street? How many OSS freaks do you know carry digital scopes and logic analysers able to resolve and capture into the gigahertz range?
So by hiding the driver source and card details they're taking away advantages from their customers, not their competitors.
Your plan is a vast improvement on what we have now, but really the paranoid lawyers controlling the chipmakers need a heavy dose of reality.
Exposing details of their chips (especially for something like VIA's Savage4-derived horrors but this applies to ATI and nVidia just as well) isn't going to help their competitors very much at all, but it will help their customers lots, and a helped customer is a happy, loyal customer.
Are you listening, nVidia?
Got time? Spend some of it coding or testing
At what level? SDL? GGI? GTK? Qt? wxWindows? KPart? Six of one, half a dozen of the other, perhaps you're spoilt for choice?
Got time? Spend some of it coding or testing
QUARTZ FOR MAC OS X
T ec hnologies/graphics/Quartz2D/quartz2d.html
http://developer.apple.com/techpubs/macosx/Core
AF_UNIX sockets work just like AF_INET sockets once you bind(2) that file handle! That's not "nothing to do"! That's PLENTY to do with AF_INET! What I'm talking about is a facility meaning it makes something easier. It's not just a bonus, it's the whole point! If you do dumb things like program AF_UNIX sockets without thinking about network transparency, some day you will be cursed by the guy who has to hack in all the missing network-byte-order stuff, etc..in order to get it to work over future-speed networks that are faster than the memory bus on your computer.
One thing you have to tackle when you get into the Unix world is the concept that users and programmers are discrete sets. In Unix, the greater the union of those two sets, the better! If you're a programmer, you should "think user." If you're a user, you should "think programmer."
Oh, and BTW your spam (in the original Usenet sense of repetition)
does not contribute to the reasoning of your argument.--- Nothing clever here: move along now...
Live with this: /. is probably not very different from Joe Public. (-:
Got time? Spend some of it coding or testing
No, it's you anti-X zealots who think you know everything and blame everything bad in the world on X. It's also called elitism: you think you're better just because you're against X. Well, you're not.
Tip: apply the desktop/interactivity patches for your kernel: http://members.optusnet.com.au/ckolivas/kernel/
Before I did this, my Linux desktop was indeed a bit slower and less responsive than Windows. After I applied the patches, it became just as fast as Windows, and in some areas even faster. Try it out, you will notice the difference.
As for applications taking longer to load, I don't know why that happens, but app loading time has got nothing to do with the windowing system.
But the main problems are in GNOME and KDE, because fvwm/twm/BlackBox/WindowMaker/Xfce are incredibly fast compared to them. GNOME and KDE are what need to be optimized further.
It's strange, I installed a RedHat 7.3 desktop for a friend and he said he can't notice any difference in speed compared to Windows 98 (even without the kernel patches).
Pardon me, but I don't think I was the original poster you were so mad at. I never denied there were professionals working on 3D.
A deep unwavering belief is a sure sign you're missing something...
Nope, YOU are blind of the facts. Everything you say is just theory. In theory, X is slower because it was designed for remote displays. But benchmarks do not lie! My benchmarks clearly proved that XFree86 is just as fast as Windows on my system. The numbers say so! If you mod down hard benchmark numbers then you are ignorant to the reality.
As you said, any kind of interface where there are "calls" or any other trappable operation could be made network-transparent. The biggest problem is that for any reasonable speed the calls must be designed so that they either return no result, or the result can be calculated locally. If you do this then you are again designing for networked use.
My big complaint is with people who say "network transparency should be an option". This is a total nonsense position to take. The only logical positions are "network transparency will not be supported", or to design for network transparency. Any plausable design where network transparency is an "option" is exactly the same criteria as supporting network transparency, as small considerations in the design can make enormous benifits for the network performance while having no effect on local performance. And in fact this is exactly the way X is designed right now. Therefore anybody saying "make network transparency an option and X will be fast" is wrong, because X is already this way and it is slow.