Slashdot Mirror
DirectFB: A New Linux Graphics Standard?
Spy Hunter writes: "Some people really dislike the X Window System. DirectFB seems to be the answer to their prayers. Building on the framebuffer support available in recent Linux kernels, DirectFB adds hardware acceleration, input devices, and window management. It has been made (and LGPL'd) by Digital Convergence as a Linux video/television solution, but it is much more than that. It has the potential to replace X for Linux desktops. You want a transparent terminal? How about a transparent video player? Development is proceeding rapidly, with a GTK port and even an X server for legacy apps in progress. Could this be the future of the Linux desktop?"
Who else felt their heart race when they saw that 'digital convergence' piece? phew it's just some dudes in Europe borrowing the name.
I wonder if the Texas guys with the colon in their name are gonna try to sue..
The ClanLib Game SDK even supports DirectFB directly, so some cool games will be available under full speed.
Seriously. What possible use would a transparent video player have? While ditching X is a great idea, I think a more useful demonstration of their technology is necessary rather than just a screenshot were everyone says "Ohhh Ahhh Isn't that pretty"
These guy's website says 'convergence integrated media'...
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com
(a) DirectFB is a thin abstraction layer over graphics hardware; ideal for blindingly fast games, video rendering, etc. Sure, that could be useful.
(b) The X window system is a network-transparent graphical desktop environment based around the client-server paradigm. Sure, that could be useful.
You can't really have it both ways. It would probably be true to say, though, that the need for (b) is dying out, and the need for (a) is growing. But that's not what the headline was saying.
These sigs are more interesting tha
The X Window system was/is nice...
My only problem with it is that it's pretty slow.
DirectFB could be a nice way to "integrate" everything together kinda like the MacOS for much Faster Performance...
-h
--- #@$DF@#2%@^%3^&*$%FRHG%%[NO CARRIER]
I want something which also works trough a network-connection. Like X.
www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
If you use hardware acceleration for your GUI, like people want for OS X, how will apps like VNC display this, if it goes straight to the graphics card?
There are many apps that will need to be ported over in order for this thing to fly. I do see that they do have a gtk port so that will help in getting some application ported over. I would like to see the best of both worlds here. They can even port Xfree86 to DirectFB but that will only defeat the purpose. What I will really like to see next is the Troll Tech libray port of directfb which will really another good portion of apps to directfb. if we can do that the mayabe in a few years we can see this as the next new standard.
This thing looks pretty sweet... I want to download it and play with it once I'm no longer stuck on the Win2k boxes at work. :)
But does anybody know if they support any sort of multihead? They list the Matrox G400 (which is dual-head) as a supported card... anybody played with this?
- fader
which is the whole point of X. You can have an X server running on Windows (ptui), Linux, *BSD, Solaris, Tru64, AIX, HP-UX, Max OS X, etc, etc, etc and display clients that are actually running on one of the other bazillion X supported platforms. The DirectFB solution works only for the Linux framebuffer. If you hate X, great, then this might be a place for you to develop tools and applications. For the rest of us old hand UNIX folks who have worked with X for years and years who love the network aspects of it, we'll stick with what we got. Even if developing software for it is way hard without several layers of software abstraction (toolkits).
I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher (1898-1972)
A new standard? No, that's a stretch. It will allow for a wider footprint because it could play to a wider audience, but X will not be replaced IMO.
.
Take all good things in moderation, including moderation.
A replacement for X is long long overdue but DirectFB doesn't seem to support a client/server model that allows a remotely running app to address your local display over the network. That capability is what brought us cheap X terminals.
The writer of the anti-X page got 50% of what he/she wanted: DEC has long since been wiped off the face of the earth. DEC->Digital->Compaq->HP. Anyone know when that piece was written?
Comment removed based on user account deletion
... is to refactor VNC to multicast directly to a bunch of Linux frame-buffers (a la SunRay). If companies are insisting on per CPU licensing and refusing to offer floating licenses (think legacy apps) then by running it on a half-decent back-end server (with fast storage) you can amortise the cost of the software over a wider geographical region, as well as support multiple legacy versions. Of course, you better have a decent network first.
BTE, whatever has happened to embedding X into the web browser (X11R7? Broadway?) How come that's not being used to port some of the older X utilities across to work over the internet?
LL
These are the guys who run the Linux DVB (Digital Video Broadcasting) aka Digital TV projects, if you get a DVB-s (satellite) board from Hauppauge their package does amazing things, you can save the MPEG2 transport stream directly to disk and have a TiVo like system without any A/D conversions in the process. They have even garnered support from Nokia for their DVB API, Nokia want to use Linux in their STB's, the Media Terminal has been well publicised on /.
I believe the DirectFB package was originally designed to do onscreen graphics for a TV link up so you could have alpha channels overlaying the MPEG stream.
Very clever guys... my hat goes off to them!
Does it come with an open sourced barcode reader driver?
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
I think that this has some potential. It said that it has X compatability, so there is not legecy issues. and porting the KDE/GTK+ applications is as easy as porting the tool kit
I am the Alpha and the Omega-3
I found that the abstraction functionality has gotten so minimal in the newer display libraries that it's easier just to access /dev/fb0 directly.
/dev/fb0. FBDRI does all the /dev/fb0 calls.
If you're doing all your graphics in OpenGL there's no reason to abstract
Since no-one's writing desktop software anymore the framebuffer device is ideal for the new one-device one-purpose market.
The idea of staying at command line and bringing up a GUI tool as needed is very appealing.
By definition, a government has no conscience. Sometimes it has a policy, but nothing more. - Albert Camus
...yes, that there are so many to choose from.
Look, Linux zealots, while there's nothing wrong with inventing something new, can you stop re-inventing the wheel just to look l33t, please?
Especially since the whole graphics-in-the-kernel was Microsoft's pheersome move in NT 4, yes, what a great move for stability that was...
And one step up, there's OpenGL under X.. oh look, it does exactly what you want already...
P.S. www.convergence.org coined the term "Convergence" over 5 years ago, i.e. before any of the above. Its meaning being, the idea that alternative platform developers work TOGETHER rather than create more disparate standards and geeky schisms. It's such a pity we didn't servicemark the name... (the site's all but dead now, BTW, because geeks like fighting over stupid little things rather than uniting to a strong common front)
Why is so much of the innovation in the Open Source field taking place outside the USA?
Why is it that it is European governments that are considering moving to Open Source, and not USA governments?
Why is it that it is big companies in the UK that are grouping together to fight Microsoft's restrictive licensing, and not the USA?
Is the USA in danger of losing its lead in the technology sector?
Great, this will be the 106,102th standard graphics system for Linux!
OK, I'm familliar with X, and with DirectFB now. Care to list the other 106,100 please?
While main of you correctly point out the lack of network support in this, let's be honest here, the majority of users want a fast, pretty desktop. This would be the way to do it.
Applications are not a problem; both GTK and QT have abstracted the window drawing from the widget set (GDK for GTK) so someone could potentially relink (not necessarily rebuild, if the symbol tables stay the same) their apps and have a wealth of stuff to choose from.
I like the network transparancy in X, but what is to keep you from running X for remote applications, and using DirectFB for your desktop? X is nice, but it's filled with lowest-common denominator decisions, and the majority of people polled (cough) want to run with things like alpha blending, anti-aliasing, and windowed 3D. X supports them, but not without a lot of pain.
So, if you want to use X, you could potentially keep it; if you want DirectFB, you can use all your GTK/QT apps (theoretically) Why rain on someones parade when both crowds could potentially win here?
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
It's all fine and dandy, but as long as KDE won't run smooth above it, I don't see a reason to care. I do dislike X11R6, but I belive X12 would be a better solution in the long run...
Read and and learn:
http://catalog.com/hopkins/unix-haters/x-window
It's taken this long for
in its current form does not cut mustard?
Try manipulating 10K by 10k images in Gimp on an
X-desktop and watch things crawl to a halt.
Though M$ mspaint will gobble up 1GB of ram in
the process, manipulating images that size is a
dream in comparison. Things get even better when
you switch to photoshop in Windows.
Bypassing all that protocol nonsense for local
- none remote - clients is the only way that X
will achieve the levels of performance that
Windows machines have had for years.
NO. this is not a troll.
- Shoot ma Penguin.
Whatever happened to Berlin? I thought it was going to be the one to replace X.
. AC
It would be except all the 3D drivers on Linux are closed source (congrats to everyone for supporting them :P) and need XFree86's driver loader, and what X provides as DRI.....
"Some people really dislike the X Window System. DirectFB seems to be the answer to their prayers."
and a little further down,
"with a GTK port and even an X server for legacy apps in progress. Could this be the future of the Linux desktop?"
This seems more than a little contradictive to me.
/T
Wow, this is great great news. Currently I run X 4. whatever. But when I installed mandrake it gave me a choice of X4, X3, and X3 with experimental 3d hardware accelleration. I really need the stability and features of X4 with non-experimental 3d with my TNT2. if this is any good, I'm so there. As long as I can still use ssh to X-Forward stuff from the CS lab.
The GeekNights podcast is going strong. Listen!
There's a standard X extension (?) called LBX that comes with XFree86 and others. Check out the LBX Mini-HOWTO if you are interested.
Cheers //Johan
Installed the Bubblemon yet?
This stuff has potential, but does anyone have some performance information (memory useage/leakage, speed relative to X, stability, etc)? I would really like to hear from people who have used this and would like to share info. I think this may be on the site somewhere, but that has been
Secondsun
There is nothing wrong with being gay. It's getting caught where the trouble lies.
Why has this been modded as flamebait? It is a serious question.
Just because you don't agree with it or don't like what it says, doesn't mean it is flamebait.
Now, I use my Linux box as my development platform, web server, mail server, etc, but I've got to keep Windows around for gaming.
Please Rate my comment (and help support Fre
however being able to ssh into any box and typing export DISPLAY=my_local_box:0.0 and then being able to run all the the remote Xapps on my box is is one of the greatest features on the planet.
if you want to increase the speed of your X its not replacing X, its replacing your KDE and gnome with fvwm2 (which is what i use) or even blackbox.
i see all these comments about enlightenment and KDE and gnome ( although i use GTK, not gnomelibs, _GTK_ for my devel and most usable apps) i shudder, because they are so slow, and then the same ppl complain about X, thats just wrong. if you want a fast system, a recommend the following:
granted transparent video will have some important uses in editing, however what has to ask how is it done in irix platforms now, is there a hardware solution that we can not compete against because its just so great?
i want X, maybe they can merged, kinda like now ppl have -nolisten tcp
-rev
If this can get the attention of some mainstream games then I think most of the geeks out there will pretty much not need winders any more. I've still got 98, the only reason is for the games... I'm looking forward to a bright, non-dualbooting future with this one (hopefully)!
Just because I AM paranoid doesn't mean they're NOT out to get me.
I want my Berlin/Debian/GNU/Hurd :(
You want a transparent terminal? How about a transparent video player?
Yea I do! Its call "Default Install" on Mac OS X 10.1. The best part, I have it today. I won't be waiting for it.
Strange women lying in ponds distributing swords is no basis for a system of government.
I think systems like directFB are a step backwards. XFree86 already has shared memory and direct draw extentions (see vmware), designed for high speed local graphics. When running remotely, the X library falls back to it's normal protocol, and the apps slow way down, but still operate. The network transparency of X is far, far too usful to encourage a crop of apps that can't use it.
I keep seeing people dissing X as a horribly inefficient system that is long overdue for replacement, but the justification always seems to be a myth.
First off, the complaints are generally levelled against what they see in a particular implementation of the X protocol, not the protocol itself. There seems to be no acknowledgement that while X servers of the past may have had implementation problems, that we have moved on and produced much more efficient and well-featured implemntations, particularly XFree. Through X extensions, XFree has become an X server that keeps the good of X, and improves on the bad aspects of older X servers.
The main gripe I see is "X is slow!!". Well, with XAA, X gets the same sort of acceleration as Windows display drivers for ordinary stuff. This requires that good drivers exist for your chipset, which is a good bet nowadays, but not as likely as Windows. Not XFree's fault, and it's clear that any FB based solution won't help matters in this regard (driver support)
People also have complained about 3D performance. XFree4 has DRI which really works well to address the issue. For Video playback, there is XVideo which provides good access to hardware scalars and filters. There is work being done on an XMovie extension that could provide access to hardware video decoders, such as the MPEG-2 decoder on All-in-Wonder cards (though I haven't heard much about it lately). Another complaint I hear is that it is ugly, that it lacks the bells and whistles of 'modern' systems. Well, there is now the XRender extension which can be used to provide translucency (if anyone bothered to implement it) and in turn provide both anti-aliased text and sub-pixel sampled font rendering (ala Window XP's cleartext).
Those who complain about X and say it needs replacement need to be a bit more educated. If you look at the projects that have aimed to replace XFree in the past, you see a very interesting pattern. Berlin is a good example of this. They set out to provide things that at the time people said "X cannot accomodate these features", but by the time Berlin progresses to any usable state, XFree has most of these features in XFree4. Let's face it, XFree in particular is a good system that can continue for quite a long time, and has only improved with age, contrary to popular belief.
XML is like violence. If it doesn't solve the problem, use more.
The arguments for and against X
So I welcome this move; because the only way we're really going to know which direction the Linux community wants to take, is to have both options available; with GTK/GNOME and QT/KDE toolkit ports on offer.
Only then, when people can vote with their screens, will we get an answer as to whether or not there is a place for DirectFB in Linux's future.
So lets see the code and try it out for ourselves!
The problem isn't X. It's much more simple. Linux is (still) way too complicated for people that use computers because they have to. I don't see another windowing system change that.
While we're at it... What would help linux tremendously, is ordinary, not-geek people using it. Linux is still mostly used by geeks, and, let's face it, they're (we) not known for their social super-skills. When people with better communicating skills and brains that work more average start promoting linux, other people might find more use and understanding in their words, than in those spoken with geek-passion. Just admit it, when you start talking about computers, everybody looks like you're speaking Chinese (or falls asleep...
It's easy, really. Make it simple, and get as many people without cs-background to use it. Then the others won't be scared of its' "difficulty".
Maybe I didn't get this, but from what I gather, it has X compatibility on one side only: it can run X applications. The other side is somewhat problematic - X can use different backends, FB can't. (I'm thinking VNC here, and networking). That's where you get legacy issues.
IOW, you can run X apps on FB but not vice versa.
They can't afford people to run the system and most of the :Cue:Cat barcoders have given up on them- how can they afford to sue anyone?
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
The real strenght of LINUX/UNIX is it's X windowing system. I can not imagine doing
my work, here in Silicon Valley - California,
not having X11. X11 network transparency is
something I can not be without it.
Can "frame buffer" be exported accross the network
to different workstations ? For example, from
LINUX to SunBlade ?
-SVGAlib
-QT Embedded
-aalib
-GGI
-MicroWindows
and probably many more.
Just use both on one machine? I havn't read the artical yet, but that dosn't sound unreasonable, and you can have two environments with 2 specific purposes? Dunno, just rambling :)
What I never liked about X is that I can't just open any video mode I like (and the card supports).
For changing depth I have to restart the X server.
Changing resolution dynamically may be possible (though not on my old card Diamond Edge, NV1 chipset, wich I don't get. The documentation said it was a hardware limitation...hmm?) but how come all supported modes aren't added to the XF86Config file by default (on my geforce2 mx anyway). Ok, so that's perhaps not really X's fault, more like the configure tool.
As for the network transparency, useful as it seems to be to many people, does it need to be tied to the video functions?
X may be old but it has adapted to the times and continues to adapt. Direct frame buffer access is great for games and may be some graphically intensive applications but i'll take the ability to run an application on one machine and display it on another of possibly an entirely different architechure any day. My little pentium 133 laptop is still a very useful machine simply because all it really has to do is run X, i can even access pigs like star office without any problem.
VNC is a cool and useful hack but X is a better solution.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
Just as a quick info for the people asking about vnc. I'm in the process of writing a vnc client based on DFB. The project can be found on sourceforge here. I havent done an official release yet but the basics are there. Feedback appreciated.
Although the site is almost /.tted it still looks pretty mean and clean to me. BUT ;-) X provides us with all we need to prevent phisical activities as much as possible (in other words check your mail on your main machine while sitting on the couch watching TV, not to mention those tedious walks to the server room ;-))
;-)
I really think this is GREAT for the whole linux on the desktop venture, because as much as I love X (and I do) I know it is a very hard thing to do (loving it that is)
X is bloated, it is considerably slow, altough I must say that with Xfree86 4 a lot of things changed (for the better) the new "modules" system is brilliant!
But the biggest problem is that for geeks like me and you
Fact is that X is the defacto standard when it comes to remote displays, heck, even novell uses it in netware 4 trough 6
My idea: Port all the apps whatever to this new platform because what I've seen off off it, it is pretty darn nice for desktops, but we need to develop some kind of deamon which allows displays to be exported over a network when the display is NOT local.
Now it doesn't matter weither or not the display is on the localhost or not, clients always connect using the X protocol over loopback, this is a waste of resoures, why not only use it when it is absolutely neccecary?
I'd say make it POSSIBLE for programs to export their display not export them ALWAYS, I have no clue about how to do this, but if some people that know a bit more about X want to help me, we'll set up a project to implement just that, email me if interested, please flame here
Fighting for peace is like fucking for virginity
Check out #DirectFB on irc.openprojects.net
Ok. Basically the problem I have with this is that we allready know what happens when EVERYTHING is stuck into the kernel (M$ Windows). The kernel is supposed to be lean, mean, device/task management machine. Look at what happened to microsoft when they stuck all the video code into the kernel? It only made things worse. I am all for the fast desktop, but we have to come to a point where we must say NO! We will not put this hog code into the kernel. I just don't see the guaranteee of stability of the kernel once you dump something as flaky as video drivers into it. I may just be wrong (god knows I have been in the past.. on limited occasions however :) )
:)
Just my $0.02. Flams me if you want.. I dont care...
Just a few quick notes about X.
- it's fairly simple to implement
- it's a standard
- it works
- it's here now
A few notes in DirectFB's favour
- a modern, and hopefully clean, implementation
- good object-oriented principles
- as a result, fast and easy to program in
So the solution, as I see it, is a little different. I've looked at Berlin and all those other windowing environments. Look, if what you want is direct access to one video console, then go with DirectFB. But if you want a windowed system, stick with X. Just reimplement it yourself.
(Although I don't know what to say about Window Managers.. they still seems like a nasty hack to me..)
XFree86 is old, and is carrying a lot of baggage functionality. What should happen is that it be rewritten to abstract the windowing portions away from the hardware level. I figure that if this is done, it'll be a drastic improvement, stability and OO-wise, over the current arrangement.
This is the main gripe I've heard, time and again, and it's the one that annoys me, too. So I think someone should do something about it. Start removing this functionality from XFree86, and stuff as much of it as possible into kernel drivers. (These wouldn't have to be included with the standard kernel; it would be enough to have a set of loadable drivers you could download from somewhere else and load into the kernel.)
I doubt this'll happen, though, because it's too OO. The current linux kernel is monolithic as high hell, and the people behind it support that mind-set. Perhaps there's hope for the GNU/Hurd.
But making claims that that you can't have it both ways is being ignorant of the fact that X is merely a protocol and XFree86 is an implementation of a graphics renderer and input system that fully supports that protocol- you can have an X server sit on top of the thin framebuffer layer (In fact, they HAVE one already.) that drives the framebuffer layer and receieves inputs accordingly.
It's not just "a" or "b" it can be "a" and "b"- and for many things, that IS what you want.
When you're talking about things like tuner cards, strictly speaking, you're never realistically going to be able to do a video push to a remote window- you're going to go to DGA (Uh, that's a hack in XFree86 that allows you to do the DirectFB thing in the context of X...) or you're going to encode it realtime to some compressed format and push the lowered bandwidth data stream to a player on the other machine to be decoded. Otherwise, you're going to need gigabit speeds to do this well for more than one machine. The same goes for videogames, etc.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
IMHO this is a good thing; the more (friendlhy) competition we have, the better the resulting products will (eventually) be. So maybe a year from now, we'll have the choice of which GUI environment you want to start. If you want to do Word processing, email, and other 'normal' stuff, you could do "startx"; if you want maximum FPS for the latest strategy simulation or Quake clone, you could do a "startdfb". Since there's a GTK port, it should be possible to run all your favorite Gtk/Gnome apps either way ...
Hopefully once of these we'll have an alternative to X. I was hoping for the Berlin project to provide this, but there doesn't seem to be much movement on their front (but then again, I don't follow it closely). Don't get me wrong, I have no major complaints about X (actually like it) but another system geared towards maximum perfromance (at the cost of sacrificing some flexibility) to choose from is good; especially in light of the fact that most modern apps (Gnome, KDE) should be pretty easy to port (./configure & make should suffice) once the base libraries have been ported.
You are an idiot. Because Gimp is slower than MS Paint and Photoshop you think Windows is better than X? You really need to learn something about logic.
You don't even know what the X protocol is, how is anyone going to believe you know how X would be better?
Yes that was a troll.
Just to be clear: the Digital Convergence named in the story isn't the same Digital Convergence which gave people a hard time for messing with their "CueCat" foo.
So will this new system be locking its software's users into X86 and SVGA hardware? One of the appeals of Linux is its ability to run on different platforms. And while I can think of worse things than forcing people to use X86, it seems to me that a new de-facto video standard, probably targeted at hardcore gamers, could break the system.
The X server renders directly into a window, and you can have your remote sessions right there. Only load it up when you need it.
Black holes are where the Matrix raised SIGFPE
Why don't you visit the sites referenced by the links sometime? They HAVE an X server that sits on top of DirectFB- think of X as being merely a protocol, once you've done that, it matters little how you render to the screen or accept inputs (This is what DirectFB does...) so long as the implementation you're using works at least as well as any others.
Having said this, they're not quite there yet, but it's coming along nicely and is quite promising.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
The name of the group is NOT Digital Convergence.. its 'Convergence Integrated Medai' and I think you owe them an apology for associating them with such a company!
Nobody's twisting your arm to use a transparent XTerm- or DirectFB for that matter.
Wow, who would have thunk it?
They give away thousands of marital aids bundled with Wired Magazine and in Radio Shack stores,
They go morally and financially bankrupt with attempting to prosecute Open Source developers,
And now they release a frame buffer video driver for Linux to unseat X11!
Way to go, Digital Convergence!
[
Aren't Digital Convergence the CueCat people?
Posted from the wireless couch.
And how many of them have support for hardware acceleration and alpha transparency?
Right, none.
It sounds like DirectFB would make an excelent video abstraction layer (i.e. the driver layer) and X could then sit on top of it (i.e. remove all the driver's from XFree86 and add a DirectFB driver - you could still install XFree86 with a driver if your don't like DirectFB - no one is locked in either way). This would not be all that different from DirectX on windows. Software could bypass X and use the video driver (and hardware) directly while other software used X through gtk, qt, ..., etc.
Spell check? Why bother. That is what grammer/spelling Nazi freaks who waiste band width posting "spell right" are for.
They HAVE an X server- it's just not required for everything like it is with XFree86.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Even using DGA2 and all the other latest X speedups, the same program running on Linux is in my testing between 10 and 20 FPS slower than Windows *on the same hardware*. That's IMO unacceptable *especially* for e.g. 400 MHz systems like yours.
FYI, framerates in OpenGL games aren't the issue since with DRI/DRM/the NVIDIA driver they pretty much just bypass X anyway. I'm talking about blit speed for windowed or fullscreen 2D games, which DirectFB sounds like a terrific solution for.
You're missing the point that you're inserting a raftload of indirection in the picture when you use X as it's currently specified. Everything HAS to go through your TCP/IP stack. While it's GREAT for networkability (and I'd not ditch that feature), it's not as great for apps needing peak performance locally- it requires more muscle on the machine doing it this way than if it were direct.
/. blurb- they HAVE an X server for this and are advancing it as well because for most things, it's better to use X.
DirectFB was developed not for games, but for media convergence devices (Entertainment systems with Linux running as the core OS, etc.)- other people are latching onto it because of the above problems. DirectFB ditches the need for hacks like DGA (which is needed for things like tuner cards) and allows you to run things like video on demand systems, etc.
Oh, and next time, read up on the actual story, not the
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Can this thing run in a different virtual terminal? Then you could run X and DirectFB at the same time, just different terminals. Compatibility issue solved.
Slashdot is like Playboy: I read it for the articles
I have been coding in the X windows source for a while now, adding in extensions and etc. All I can say is it is a disaster. The goal of X windows is to retain backward compatibility all the way back from it's initial implementation. What this means is that almost none of the source is ever removed or replaced, it just has wrappers written around it or hacks to decide which source to use. The source is littered with #ifdefs. The code is not very modular either. A change to one section of the source means a change to others to keep things synchonized. Good luck finding the spots to change. For example I added an extension and had to edit the command line argument processor in the main() function, the extension init routine, some hardware initializing routines and ANOTHER commandline argument processing routine. X windows is just so big that when you have many coders working on it at the same time, everything gets out of synch more and more... Oh the best way to find the spots to change is to find where it is segfaulting, and browse a lot of core files.
Ok, now the only good things about X windows is that.... umm... it's a "standard" which is a word a lot of people like. I think DirectFB will be successful as long as X windows is still around to run all the older Xwindows dependant applications.
Outdoor digital photography, mostly in New Engl
>transparent video player?
Does it support fully asynchronous operation between multiple applications? X does and it's major feature of it. Without it we are just like in the days of Windows 3.1 (cooperative multitasking).
It is bad enough that we have to suffer cooperative multitasking in mozilla/netscape (it sucks). Suffering it trough the entire window system is not acceptable (I'd rather go to NT which doesn't have this misfeature).
It seems to be a nice thing for an embeded device. But I'd never use it on my desktop machine. (The lack of network support doesn't bother me much, VNC is cool).
DirectFB was originally developed for set-top-box applications, i.e., for systems that have neither 3D-acceleration, nor the extra megabyte of RAM that X eats up. So OpenGL-on-X was no option (and yes, we did consider that, we're not stupid, you know).
And DirectFB is a userland library.
You better check your facts before flaming like that.
I present to you *cough* Windows XP.
I'm a microsoft bitch, so feel free to mod me down.
Comment removed based on user account deletion
This is something that Linux can definately use. X is cool, but is really better for client/server desktop applications than as an actual desktop.
Of course, what would really make this nice is if they can make it easy to set up. The number one newbie problem that I see with Linux is getting X to work. I have been running Linux for a few years now, and configuring X is still a huge pain. Apologies to Frank Herbert, "Who controls the easy setup tool, controls the Linux desktop!"
"Could this be the future of the Linux desktop?"
god I hope so!
-Mark
however being able to ssh into any box and typing export DISPLAY=my_local_box:0.0 and then being able to run all the the remote Xapps on my box is is one of the greatest features on the planet.
Ouch- allthough your command to start the X proggie will be secure, the windowed program itself will be going over an unsecure channel if you use that method. (all your click are belong to them)
You should really look into X-forwarding (read man ssh).
Regardless- I too like the network transparency that is offered from X. If the damn X protocol would support SSL or something like it natively, then it would seriously speed up secure remote graphical logins. (search google for tcp over tcp to see why)
People are understandably feeling very patriotic right now, so it seems people are somewhat over zealous with moderation on any comment that is seen to criticise the US in any way, even if the comment is a million miles away from politics, or geopolitical comment.
:)
I wouldn't call it blind patriotism, but maybe it's being vented in the wrong way, maybe due to frustration, anxiety etc, it's very understandable.
In fact, this analysis may well be mod'ed down in the same fashion as the original thread
Normally I would be one of the ones saying "Ugh, not another half-ass graphics standard," as I am developer for the GGI Project, which, if very slowly, is creating the ultimate (IOO) cross-platform and cross-display-system graphics API/library. I make no such complaints about DirectFB (well, OK, I do complain about their input system :-) and here is why: DirectFB is coded in such a way that it contains easily reusable, easily understandable graphics driver code. Both DirectFB and X have unique content -- there aren't that many implementations of hardware level blitting/overlay libraries available. Unlike X, DirectFB is modular and developer-friendly. In fact so much so that the current version of LibGGI can use DirectFB's binary graphics driver modules.
Someone had to do it.
You say drop GNOME but then you suggest running two GNOME-lib based apps.
While DirectFB is good for small lighter devices, direct video, and the occasional game X leaves directFB for dead in most areas.
DirectFB is a serious functionally step back from X and is designed as a fast simple cut down version to just display raw graphics. Its not a high end user interface manager like X. X will continue to be be the first choice for a desktop, with DirectFB been an extra display you run for that fast graphics your looking for.
There is soo many greant and lovely things about X that make it oh so great. Been able to remotely run apps of other computers, manage a huge amount of perciples, displays etc, been able to remotally connect to your computer though X, been able to play 3D games off someone elses computer and watching your frame rate drop to less than 2 per second. Anyway the point is theres a place for both technologies and they can co-exist quite happily. They just have 2 compitly different purposes like DOS and windows do.
Where the hell do I sign up to help!
Seriously! I've been pushing for the death of X for a long time now. DirectFB is a very promising replacement from the sounds of it.
As for the network transparency layer, nothing says that you have to lose that. If done correctly, you won't even need to recompile your apps for each different use. Quite simply, assume that every app on a system uses DirectFB instead of X. Now you want to remotely use a gui on that system. DirectFB simply needs to present the ability to run in a detached hardware mode. A client system can attach it's DirectFB to a DirectFB layer on the server.
The rest would run a lot like X: the application writes it's video output to DirectFB, which saves it in a memory buffer. That memory buffer is output to the client system as quickly as possible, but moderate loss is acceptable. All hardware blits are performed in software instead (since you really aren't using the system's video card at that point).
Yes, it sounds a lot like X, but without a few major X problems. Video updates are not required. So your windows won't hang on slow networks. Bonus #2 is that a lost connection doesn't have to kill an app. Just reconnect to the server when you get a chance and pick up where you left off.
I hope I managed to get across the major difference. I have a feeling that I haven't. I have a better explanation in my journal for those who really want to understand my major bitch points for Unix these days. (Even though I'm still a huge Unix advocate these days.)
Consider the applications. If they are written in terms of DirectFB, you don't get network transparency. If they are written in terms of X, you don't get performance.
(Unless they are claiming that X-on-DirectFB will be faster than XFree86.)
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
DirectFB uses the Linux Framebuffer interface, which even works on the Compaq iPAQ, AFAIK. It's a lot closer to the kernel, but it's still abstracted enough to be portable.
But you do have a point, people who target DirectFB might make optimizations and assumptions in their code (read: inline assembly) that would tie it to a particular architecture (x86). However, this is a seperate issue, and it is not limited to the scope of DirectFB, or games for that matter.
Black holes are where the Matrix raised SIGFPE
DirectFB would be great for fast graphics and stuff (as many people have pointed out already).
No more DRI, et.al, just FB modules in the kernel, and DirectFB with some window manager.
As far as the annoying whining about how we can't replace X, it's a standard, we need remote display support, blah blah blah, it seems to me that developing an X server that runs through DirectFB is the obvious solution. D'uh?
Q: When I specify SDL_FULLSCREEN in X11, the screen goes black and my window is centered in the middle, instead of covering the whole screen!
A:
X needs to be able to switch to the desired resolution. For this to work, you need to have the resolution listed in the 'Modes' line in your XFree86Config file (and your Monitor must support it). SDL does not currently support changing resolutions on X servers that do not support the XVidMode extension.
The following example is taken from my config for XFree86-4.0.1, but 3.3.x is similiar. Note that if your monitor isn't capable of using these video modes, the X server will drop these modes from the list of available video modes.
Example:
Section "Screen"
Identifier "Screen 1"
Device "3dfx"
Monitor "Samsung LCD"
DefaultDepth 16
Subsection "Display"
Depth 8
Modes "1280x1024" "1024x768" "800x600" "640x480" "320x240"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 16
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
EndSection
Note the different entries for 8 & 16 bit screendepth. I.e. the 320x240 resolution is *not* available when X is started with 16bit depth (the default).
To test these entries, restart X after you modified XF86Config and press ctrl-alt-plus and ctrl-alt-minus to cycle through the resolutions.
It's so nice to see the ignorant Slashdot hordes rallying around the "X sucks!" flag. Here is what someone who actually knows what he's talking about has to say: (from http://www.linuxpower.org/display.php?id=211)
.5
Jim: No, I believe very strongly that either GTK+fb or QtE are dead
ends. Our experience in the market (beyond the hacker community) is
that the major attraction is the ability to share with little or no
hassle applications written for the desktop: while the applications
may need reworking to deal with the screen size and touchscreen, there
are many applications not written for GNOME (or KDE).
Network transparency is worth a lot in PDA's such as an iPAQ: it is
really a full fledged networked computer in your hand, which can take
advantage of other displays, keyboards, etc. in the user's environment
when convenient. If I have a lot of text to enter, I don't want to use
a touch-screen unless I must, and I don't want to have to build two
applications, the way Palm or WinCE does. Others will experimentally
determine that frame buffer based environments are a waste of time,
but we won't...
At CRL (Cambridge Research Laboratory), we are working on the Mercury
project for pervasive computing. With the advent of high speed
(wireless) network connections and large (currently 1 gigabyte)
storage devices like the IBM microdrive, we foresee an environment in
which you will want to take advantage of the computing environment
around you, including keyboard, mice, projectors, and servers of all
sorts. Note that the ability of an application to interact with
desktops in your network environment is therefore vital, and sometimes
at levels beyond file and web sharing. Most of what you hear about X
being too big are from people who know little or nothing about the
topic. After all, we wrote X Version 11 on 2 megabyte VAX 11/750's:
iPAQs have 16 or 32 times that much RAM, and a CPU 200 times faster
(for integer operations).
Keith Packard, in his TinyX server using his new frame buffer code,
has reduced the X server to 500-700K bytes of code (depending on
whether you want his new render extension for anti-aliased text and
graphics). Most of the perception of bloat is caused by how Linux
reports memory. An X server maps the display card into its address
space, and on current graphics cards this can easily be 8, 16, 32 or
even 64 megabytes of address space (for the frame buffer and registers
of the display). Naive people look at "ps" or "top" and draw the wrong
conclusion. Clients may be asking the X server to preserve pixmaps on
their behalf (which should really be charged to the client, but it
shows up in the X server). So, for example the RSS size on my iPAQ is
2.2 megabytes when running Familiar, with backing store and save
unders still enabled (arguably, on a device like an iPAQ, I should
disable them, which would further reduce the RAM footprint).
I recently completed work to remove the dependency on Xt, Xaw, and Xmu
that many of the little X utilities had accretted over the years: this
saves 1.1 megabytes of code on a device like the iPAQ (presuming no
user application wants/needs Xt, which is easy to arrange). These
changes have just been checked into XFree86.
The remaining work is to put Xlib on a diet. There is about
megabytes of code and static data that has accumulated since Xlib left
my hands that few applications and toolkits use (the CMS and
Internationalization parts of Xlib). These are either never used
(CMS), or only used by Motif (which few Linux applications care
about). By making CMS and the I18N parts of Xlib dynamically loaded
libraries, we can avoid breaking binary compatibility, but allow PDA
users who don't need them (essentially everyone) to avoid the waste by
not loaded those libraries. John McClintock has patches for the CMS
changes which I hope to look at soon, and the I18N work is straight
forward.
Keith and I believe that a basic X environment will end up a bit over
one megabyte of code, when this is done, while preserving complete
compatibility (a full X implementation).The replacements for X don't
come free either (they also have to have frame buffer code, window
operations, etc.). The true cost of network transparency is well under
a megabyte, IMHO. At the current cost of RAM, it's not much cost, even
on low end PDA's... We could make things yet smaller, but we'd then
be sacrificing some compatibility, which, while reasonable, is less
desirable, as knowing your application should "just work" is worth a
lot. So I see either QtE or GTK+fb as dead-ends, interesting for a
short while on the smallest devices, but will be just a passing
footnote in history.
I second that!
Sorry, but your comment smells like a clueless troll.
My exception safety is -fno-exceptions.
but something needs to be done about X. I have a very mainstream video card (TNT2), and under Windows it flies for 2D work (1600x1200x32)--full window moving, resizing, scrolling etc are perceptually instantaneous. This same card under KDE 2.2.1--using what appears to be a fairly well supported XFree86 4 server, at the same resolution and color depth--feels roughly like an unaccelerated SVGA driver under Windows, maybe a bit better. Many drawing operations become visible under heavy graphic load, such as when moving windows above other busy windows that need to be redrawn. Resizing windows feels sluggish, scrolling web pages and such feels sluggish etc. We'te not talking 1990-slowness, but in a world where graphic lag of any kind is essentially a thing of the past, this is very noticeable.
Maybe it's not all due to X, who knows. But dragging around baggage beneficial to only a portion of users (that seems to be getting smaller with a growing Linux user base) almost seems unfair. If I spend most of the day in front of the framebuffer, with only occasional remoting of the display, I'd prefer to have the fastest possible performance during that majority of time, and would in exchange accept worse performance during remoting. That's essentially what happens with VNC on Windows right now. And I know we can do better than that, because Windows has notoriously few graphic hooks, and any new display system could easily improve on that without giving up performance in spades like X.
I, for one, would just LOVE to see the ability to actually use a SunRay with a linux server. I don't suppose sun is going to fork over the specs though...
Just think of it. Those awesome SunRay terminals, without the need for a rediculously expensive Sun server.
Why are you forwarding X connections manually when you are using SSH? SSH does this for you. PLEASE read up on X forwarding in SSH. It's excellent. And secure.
What you are suggesting is not secure at all.
Most X implementations share the same source. Most of it comes from the main X.org source tree. There are plenty of direct cut and pastes from the X.org tree right into other trees, Xfree86, Suns, etc... The core source of the trees really are not much different. They are suppose to all implement the same standard, so there isn't much room to have a different core system.
Outdoor digital photography, mostly in New Engl
Heh...the idea of aalib with hardware acceleration and alpha transparency seems really funny to me... :-)
Hacker Public Radio is our Friend
Then some people really need a good dose of shut the hell up. The X-Window System protocol is genius. A network transparent, platform agnostic, graphics communication layer is an incredible feat and it has yet to be fully duplicated anywhere else. You want Berlin? You want fbcon? That's fine, you can have them! But X isn't going anywhere!
The framebuffer died in modern graphics card several years ago when they all started implementing OpenGL/Direct X internally. At this point a DirectFB implementation is about as interesting as a new enhanced Floppy Disk Driver. Useful for backwards compatability and fun to code, but not very forward thinking.
-Don
Take a look and feel free: http://www.PieMenu.com
-Don
Take a look and feel free: http://www.PieMenu.com
It might work, but shipping bitmaps over the network is basically what VNC does, and if folks are complaining about X being slow, let's not bring up VNC.
X works very well remotely because it was designed that way - ie ship the commands, not the result of the commands because the commands are much smaller. (much the same principle as HTML or XML)
X and FB can co-exist, but not by using FB as the abstraction, because it's too low level. You need a higher-level abstraction that can render to either X or FB. This is why the port of GTK etc is a critical part of the effort. Essentially, what it will probably entail is a switch to an X server that renders only to FB, and either an FB-aware "Window Manager" or possibly local proxies to remote X clients. Could work pretty well, but will take a fair amount of work.
Now you're obligated to correct me three times.
X-Windows! X-Windows! X-Windows! X-Windows! X-Windows! X-Windows!
You owe me six more corrections!
X-Windows! X-Windows! X-Windows! X-Windows! X-Windows!
There's five more! You're getting behind. Better hurry up!
-Don
*hint* *hint* the problem in your setup is KDE...
KDS can do a lot more than windows, but is also quite a bit heavier, and slower...that is what is using up your memory. And X is not even the problem here! you should switch to twm or if you are NOT entirely into 2 color mode + background, go to mwm or fvwm(2). The implementation of X is what needs to be more hardware accelerated, perhaps, (which would unfortunately make it Linux specific) but X is wonderfully useful and genius beyond what directFB comes up with. If they say that they will support all the features of X currently (which I am sure they will eventually, if the project ever matures), then wait a minute...... X has those features NOW!!!!, and all we need are better device drivers / implementations / updated and accelerated Xfree
BSD is for people who love UNIX. Linux is for those who hate Microsoft.
1) Use port forwarding over ssh instead of DISPLAY=insecure_as_hell. Please, firewall X (6001-6006)!
;-)
:-).
2) Component programs like Gnumeric are cute, but with Gnome it's kind of all-or-nothing for the novice user. This is an issue since X performance is not up to par with Windows in many respects. Believe me, I've set users up with both Gnome and other WM's (fvwm, Windowmaker, etc.) and they all prefer Gnome. Even though it sucks
3) Ok, maybe the Mutt comment bears the Insightful label
Bottom line is that most X apps run well on a local workstation, and if you're not tunneling X from, say, an SGI Onyx in New York to a demonstration on a workstation in DC, you may not really want the overhead of being able to do so. Don't get me wrong, X is magically delicious for a handful of users, but most admins (myself included) can control things very well with a terminal or VNC, and most users are never going to use the most powerful features of X, rendering it needless bloat for them. DirectFB solutions would make Linux far more attractive for these sorts of users are their managers.
Remember that what's inside of you doesn't matter because nobody can see it.
It's called SCGUI (Server-Controlled GUI). Although not suited for video games, it is ideal for business and general GUI's over just about any kind of network, fast or slow.
http://geocities.com/tablizer/scgui.htm
Table-ized A.I.
I've lately been looking at the fb support in the kernel, and unless I'm missing something, the majority of graphics cards are not yet supported. Most cards can just use the VESA support, but it does not currently allow for changes in refresh rate and won't be as fast as a driver written for a certain card. So are there drivers planned for FB?
I am not aware of any country in Europe where the police can raid your house if you don't pay the tv license. You must have picked that up from some of your NRA propaganda.
Wow, I've just looked at your web site. What fun!I love the section about gun education for children! Brasco (TM) The Liberty Bear Coloring/Story Book sounds great!
Am I glad I live in Europe.
Of course, browser can't display XML so doesn't anybody know what's going on?
(These guys are really into the "latest thing")
I'm sure there will be a back-end for X at some point. When that happens, I'll check DirectFB out.
The UNIX-haters link was funny. For those of you who might have taken it seriously, just don't bother. It's a skewed version of history mixed with a lot of personal bile. I'm particularly amused that he chose to call it "X-Windows", and insisted the publisher use that form because it would "piss off" the X folks. The reason he says this is because the X Consortium goes out of its way to point out that "X-Windows" is an encumbered term, so folks are supposed to say "X" or "The X Window System". Nutball. Nuff said.
Thanks to capitalism being run unchecked for so long.
So long, tech industry! We hardly knew ye...
This sounds like it would be a *HUGE* step forward for the *NIX community as a whole. Unfortunately, it will probably fail because our community is so stubborn. If X is so great how come Apple chose to go their own way and implement Aqua? X certainly would seem more advantageous for them...just port X-Free and you've got thousands applications instantly supported on OS X...the problem is that it takes a lot of hard work to make X pretty. Look at KDE, Enlightenment, and Gnome. These projects have taken years trying to make a square round when reinventing the wheel would have been much easier.
If Linux is ever to be a player on the desktop, we will have to abandon X. X and DirectFB are not mutually exclusive and there should be a relatively painless transition. X just doesn't make sense anymore for a PC dominated world. When was the last time any of you used a dumb terminal? I've never used X on anything other than PCs and I'm sure that most of my generation can say the same.
In short we need a new king for a new generation.
Slashdot, the site where everything's made up and the points don't matter
speaking of "blindingly" fast games, and amazingly optimized hardware accelerated graphics, i stopped over @ the directFB site to check out the modules they have, and what video cards they currently support, even though they are obviously @ a very early stage. either way, kind of odd that they started with supporting the OLD cards, namely those that were HOT a few years ago, but which now are quite out of date... if they speak of blindingly fast game graphics, why dont they start with writing a radeon driver (or 8500, j/k) or the geforce 2 or 3....although it would most definitely be too early to judge the project JUST based on those characteristics, the trend they are setting is similar to that of berlin: we will start with supporting the very basic vid cards such as the ati rage 128, and we will support the REAL stuff later...sounds like a rather doomed plan to me :-\
BSD is for people who love UNIX. Linux is for those who hate Microsoft.
- replace KDE/enlightenment/gnome with fvwm/blackbox/twm
- replace kmail with mutt (read the help mutt as more features)
So you're actually saying : "Let Linux desktop users stay/go-back to the Medieval Times ?"Man, what a load of *insert-something-here* is that ? Are you blind maybe ? Never seen a screenshot of GNOME/KDE/MacosX ?
Never even used a mouse maybe ?
blaah !
We desperately need a good, solid, and easily managed replacement for X. Whether DirectFB is right for the job is beyond me.
But dragging around baggage beneficial to only a portion of users (that seems to be getting smaller with a growing Linux user base) almost seems unfair.
Ah, the tyranny of the majority rears its ugly head, even here in the land of the free. We are more numerous so let's vote on everything. That way we get to rule while pretending to be fair. Let's dump all those old bearded Unix types who made Linux into the premier server and workstation platform. We don't want workstations or servers, we want gaming platforms. We don't want Linux to replace Win2K, we want it to replace the X Box.
A Government Is a Body of People, Usually Notably Ungoverned
I mean, really. The screenshot linked to is just awful! Which window's on top? Can I click on "Expand All?" Boo!
But the software itself looks keen . . .
Al Qaeda has ninjas!
You can easily embed X apps into a web browser with Tarantella. It even uses a lightweight protocol that you can use over a dialup connection, unlike X.
michael.ossmann@alttech.com
I use vim. vim == 1994.
Aren't these the same people who made the CueCat?
;)
Yes. DirectDraw comes to Linux after only 6 years. Thank God, we can finally start coding interesting 2D apps.
I think you've been watching too much CNN lately . I've noticed that the benefits of X are extolled suspiciously often within the context of servers and remote administration. May I just observe that most serious admins shun graphical tools for the command line anyway? I've seen very few admins attach their display to a remote server for anything, yet most of them live in telnet. I dare say that telnet fulfills most of the duties X is accused of for these kinds of uses. Most of the X apps that would work comfortably remotely over extended periods probably take minimal advantage of a GUI anyway and would likely work just as well in text mode.
IMHO, XFree86 is great, but could this have applications in areas where smaller/faster is better? Like (as the hype increases) PDAs or older, slower machines. Xfree was always slow to come up on my old P200 (I'm not talking about KDE but just to the familiar grid). X rocks for network stuff but having a lighter GUI would add tons of value to Linux.
My only question, would VNC have to run as setuid/root?
Sorry their site is /.ed and i have a quick question. Isn't it possible to just run both? Perhaps not at the same time, but just drop X down to play a game?
A different kind of animal
> KDS can do a lot more than windows,
While I'm not particularly a Windows whore, this statement is hard to swallow. Explain.
> but is also quite a bit heavier, and slower...that is what is using up your memory.
Memory? Who's talking about lack of memory? I've got gobs of memory. I'm talking about moving framebuffer memory around, and rendering graphics primitives. A 32-bit display takes the same time to render regardless of how much memory your app uses. I've tried those other WMs, and I'm not impressed. Sure you can get faster if you lower the resolution and color depth, but that's hardly a fair comparison.
> The implementation of X is what needs to be more hardware accelerated, perhaps
I can't say how optimized the various servers are (e.g. my TNT2), but the real culprit is not the failure of sequeezing out a couple more nanoseconds out of Bresenheim et al, but the big overhead of marshalling graphics primitives to a network protocol, or even just reducing this to shared memory operations. Add to this the many generations of code(rs) in the X code base, and I can't see how it could approach any level of efficiency.
the company name is 'convergence integrated media GmbH' or simply 'convergence', NOT 'Digital Convergence', so they're NOT the company who did the infamous (license-wise) :Cue:Cat (this company is called 'Digital:Convergence', btw), but the company who also does the (pretty cool) LinuxTV-drivers for DVB-cards from Siemens/Hauppauge.
..
the portability issue is softened by direct support of DirectFB as backend by ClanLib, GTK 2.0+ and even SDL (from not-yet-released version 1.2.3 on, get it from CVS), so basically writing code for one of these will give you portability beyond Linux. GGI supports it as well, but not the way it was intended (they're just re-using the binary drivers with their own API).
while replacing X might be something you COULD do with DirectFB (if you'd really want to), code-size and speed seem to be of more concern to the developers, which is quite understandable if you've got settop-boxes in mind. The approach of X is at totally different one, i.e. network-transparent, hardware-independent, portable graphics. DirectFB can simply (additionally and optionally) support the needs of a typical X application/client, so the article was maybe a little bit too anti-X
now I can watch my pr0n in real time with alpha blending and transparency!
I knew that reply would come ;-)
gvim rules ;-)
blaah !
You probably don't have hardware acceleration set up under X. My Voodoo3 card is well supported but was slow as hell before I installed Redhat 7.1, which autoconfigures hardware acceleration.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
I use vim. vim == 1994.
M = 1000
V = 5
I = 1
Thus, 1000 - (5 + 1) = 994
-l
Incidently, mvim would equal 1994... (think how MCM equals 1900).
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
Why call X programs "legacy" apps? I would welcome directFB IF AND ONLY IF it is used JUST by those programmers that need the speed, like games programmers and perhaps some CAD/rendering programmers. I would hate to see the situation where everyone forgets how useful remote apps were and the notion falls by the wayside. For most apps, the lightning fast video speed is irrelevant, and for those apps, portable X should be used.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
I've coded with Linux Framebuffer. It is not abstracted. All they do is give you a little bit of information, a mmap() device, and say, "hey, kid, you're on your own".
Userland framebuffer apps are expected to handle several device types (packed pixels, planes, textual, EGA and older VGA...) as well as several visuals (2 types of monochrome, true color, mapped, statically maped, and bit-packed). Modern x86 video cards are only of the packed pixel variety, thus libraries are only likely to support that (I've written framebuffer code, and I don't even have any of the other types of hardware, so guess what only works?)
If you don't believe me about how insanely raw the framebuffer interface is, you can look at /usr/src/linux/include/linux/fb.h. Try to write code based only on that header, I dare you!
That is, if you do code at all, and you're not one of those ignorant blobs with nothing better to do than whine about X sucking on Slashdot... "Framebuffer is the savior!" I can honestly tell you, the framebuffer interface is not so terrific. Unless you happen to have the documentation to a zillion chipsets on hand, in most cases you'd just end up slower than X.I'll second this as far as nVidia chips go, too. I have a GEForce 2 MX(400) and it was butt slow in redhat, until I configured nvidia's xfree driver. Suddenly, it became faster than windows' window updates. It wasn't quite stable, but that was a few months ago. The installation instructions are also somewhat unstraightforward.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
X may be poorly designed and implemented, but the people who rant about it just don't seem to understand its usefulness. We have 6 computers at home. Do we want 6 monitors? No way! The X server on the Linux box my monitor is connected to lets me use programs on all the Unix boxes on our LAN.
I have the impression that X implementations are improving. Crashes are extremely rare in my environment. OK, it used to take 50% of a machine's resources when workstations ran at 40MHz and had 8MB of memory, but those days are long gone. It takes a negligible fraction of the resources of a modern workstation.
It feels like an "unaccelerated SVGA driver" because it is. The nv driver that comes with XFree86 performs no hardware acceleration at all. You should be using NVidia's accelerated drivers from http://www.nvidia.com/view.asp?PAGE=linux. Yes, they are closed source, but at least they exist, unlike drivers from many other manufacturers.
I've noticed that the benefits of X are extolled suspiciously often within the context of servers and remote administration.
It also means I can sit at home, log into work, and pretend like I'm really there. Just one in a long list of X benefits that have nothing to do with sysadmining.
A Government Is a Body of People, Usually Notably Ungoverned
Thanks to both of you, I'll check out the nvidia driver. I had heard of its existence, but I guess I assumed the driver that came with RH7.1, Mandrake8.1 etc was it.
Most of the people on devel@xfree86.org would know. The nv driver shipped with XFree86 has poor acceleration for 2D as well as 3D. This is due to lack of specs from the manufacturer. You'll get significantly better performance using nVidia's binary-only driver from their website.
Well supported cards are easily flooded by XFree86 for 2D. The cards cannot draw fast enough to keep up with the XFree86 process. It isn't an architectural problem. It's almost certainly a driver or application problem.
It would be useful to develop a standalone benchmark system that used XFree drivers directly. That would make it much easier to determine when the performance problems lie in the driver, in XFree, or in the application. I suspect this would be really hard to write.
Well, I gotta say this DirectFB has nice eyecandy screen shots. But the 'more GTK' pic makes me feel like I've been drinking too much. I sure wouldn't want every window to be transparent.
I can see transparency being a nice feature for menus and certain types of popups or CPU meters, that kind of stuff. But I generally don't want, say, my Mozilla browser to be transparent.
One reason I really like X and this is about the only reason, is that it is network transparent. Can DirectFB make that claim?
1) It's networked. People don't use this any more, mostly. If they do, it's via ssh, which doesn't use the network features of X anyway. X ought to just specify talking to a local server, which may be a proxy over ssh.
2) Its core protocol is missing a ton of features that program want. For example, nobody on the team knew how to do splines, so they left them out. Splines still aren't really supported, and won't be supported any time soon in the core protocol.
3) It's too extensive. It is generally implemented as a set of drivers, library, network server, resource manager, plus windowing system. Some of those features ought to be separate. In particular, splitting off the drivers (as well as implementations of operations the actual card doesn't support) from the windowing system would save a lot of hassles.
I think a layer for doing graphics under the level of the X server would be better. The main problem is that XFree86 has really good free drivers, which would be a shame to reimplement, but they are all for the X API.
There are some cases where you don't actually want the main features of X, so it would be good to provide a more fundamental graphics layer to programs that want it.
Sasami2k. I don't quite see the point of transparent video, but the option to use a video for your wallpaper is quite neat.
That's the whole point, of course. Linux users want to be able to do fun things on the OS they use for their work - rebooting to Windows is an icky solution, and Mac OS X is no solution at all for most of us (at least while it remains hardware-specific).
- Berlin
- SDL
- Allegro
- OpenGL
- Linux Framebuffer
- DGA
- SHM
(don't forget that some can nest on top of others which can nest on top of others)
I was unaware of this, but now that I think about it (having hacked a little X code myself), it makes sense. Does anyone know if X was originally used for something else before it was used for X-Windows, or was a remote application interface always the intent?
::ducks flames::).
In any case, this means that DirectFB is doing something new; it's only job is to be a windowing system and video/input interface. This is something for linux that should exist, as it is a central feature of other desktop-friendly x86 OSs (Windows and BeOS). It would make it a great system for doing various graphical applications (more so than it is now, MORE SO THAN IT IS NOW
Also, I think an important future feature of GTK/QT should be to support multiple backends, as in they would automagically detect DirectFB or X11, and pick the more appropriate one. For example, they would check the DISPLAY environment variable to see if you have a remote display set, otherwise, they'd look for DirectFB, and failing that, a local UNIX socket for X11.
Black holes are where the Matrix raised SIGFPE
The only thing that any other OS would need to do (if they wanted to) would be to have a Framebuffer device that behaves like the Linux one. For example, OSS works on a large variety of operating systems, even though it is a largely linux-centric standard for audio. This is possible because the drivers use the same API across all the platforms; the apps that use them just need to be rebuilt on the target OS. The same could easily be done for the Linux framebuffer. Furthermore, if the Linux framebuffer interface is simple, it would be trivial to add additional rendering code to deal with SPARCS, Amigas, and any other hardware directly (like SVGAlib). One could even pull the code straight out of the drivers from the linux kernel for these targets.
Black holes are where the Matrix raised SIGFPE
considering the new 'modular' nature of XFree86 4.x, how feasable would it be to implement DirectFB using drivers written for XFree86.
On a side note, if you consider a driver in general, even a windows graphics driver, basically it is a library with some exported C functions that either the OS (windows), or the windowing system (XFree86) call, would it be feasable to write an X server that used windows drivers?
Broadway was trying to solve an extremely complex non-problem for which it was never intended, that doesn't do anyone any good.
The only people who need Broadway are the people desparately promoting trash like X11 and Motif and CDE, who were put out of business by the web, Linux, Gnome, KDE, TCL/Tk, Python, and other useful technology.
What I said about the ICCCM would certainly apply to Broadway, had it ever gotten off the ground:
"In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor."
And of course JWZ's comment still applies:
"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." - Jamie Zawinski
For more thoughts on the subject: The X-Windows Disaster.
And here are some notes on why X11 window management has gone so horribly wrong, which helps to explain why Broadway is necessarily such a horrible failure.
Window Manager Flames: Why the ICCCM Sucks.
-Don
Take a look and feel free: http://www.PieMenu.com
let me scan a coke can and take me to coke.com?
Why do the kids in West Side Story have to join a street gang if they can afford $70 Gap khakis?
mac os x can do all of that...
but i do wonder if writing opensource software to run on only one kernel is a good thing or not.... isn't the whole idea of the gnu project and open source is to provide tools for users to use no mater what they use for an os... this to me is linux zelats trying to be like bill.
He thats what I think on this... what do you think? How is this really good?
Why not just write this shell over the top of SVGAlib (or a new framebuffer), and run XFree86 in a window on the local GUI to run X programs? XFree86 for win* systems runs in a window on the local GUI.
That way another app supports all of your networked programs, or stuff displayed on screen owned by another user (I do this all the time because it's a pain running two Xservers for two people and switching views), and you have your fast desktop shell (or windowing system or whatever) only handling supported programs.
"X is slow!"
Solution? Get rid of your bloated, feature-creep ridden sorry excuse for a window manager.
"X is bloated!"
Umm.. Riiiiiiight.
"I can't play games!"
Buy a console, or get a Windows box.
"But Microsoft is evil!"
Clueless MSCE's are why Unix people get paid a hell of a lot more. You want that to go away? I shoot you now, you are winner, haha.
> 1) Use port forwarding over ssh instead of
> DISPLAY=insecure_as_hell. Please, firewall X
> (6001-6006)!
Well, if you encrypt all of your X connections that
may be the reason why you feel X is slow.
Use xauth authentication and X is not insecure
and is fast.
It's my hope that they allow (like in the OpenGL standard) for various classes of transparency. There's a whole list of them, but it amounts to the sort of "mixing modes" you can assign to layers in Photoshop, wherein the amount of mixing is controlled by the alpha channel. This would allow for different types of transparency that would be appropriate for the application, and could clue you in to the stacking order of windows (it looks different in different orders if you use subtractive vs. blend vs. multiply). Also, the open window list / stacking order should probably be indicated somewhere on the screen anyway, like in a gnome-panel-lookalike.
As an aside, it's called the alpha channel because the values represent the a parameter used in the blending functions. For example, a standard blend would be:
d = s_1 * a + s_2 * (1 - a)
Black holes are where the Matrix raised SIGFPE
I'm having terrible experiences with the Nvidia
closed source driver from their hardware. It does
work for 3D acceleration but it doesn't play nice
with Xinerama (dual head) and it crashes all the
time. I have a TNT2+Millenium I, a dual PIII-500
and running 7.1 with 2.4.12-ac4.
Ok, here's a little thought experiment for you...
You've got a server machine with all those shared libs, right? Does an X terminal need those shared libs locally on itself to operate or can you get things like KDE to run on the X terminal session? No? If it's a "no", those shared libs are an application interface to X to make it easier to use its protocol accordingly.
Another experiment for you...
Take those shared libs and the apps that use them. Rip out the XFree86 server and replace it with a GGI or the XDirectFB server. So long as your apps don't use DGA or SHM (and maybe even then...) your apps will still work largely the same- why? Because, X, at its heart, is a protocol not shared libraries, etc. It has to be for it to all work transparently over a network with so many differing GUI rendering targets.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Network transparency for a tuner card, DVD player, many video games, etc. is verging on irrelevant- you're wasting loads of energy and efficiency for something that will, under almost all cases, never ever be used in that manner (I challenge you to play Quake 3 via remote- you'll not be doing very well...). For those things, peak performance is what matters.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Any time you're using any sort of RPC mechanism, you're adding some sort of indirection (and if SHM was so great, why are people using DGA with things like xawtv?)
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
No.
I did, however, say that some things didn't need network transparency or the indirection caused by all the trips to the server and back. Doesn't matter if it's unix domain sockets or network sockets (which is picking nits, BTW)- it's still indirection and a lot of it that things like SHM doesn't fix (If it did, why do we have things like V4L support and DGA in XFree86?).
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
One point not mentionned here: DirectFB is actually a solution to an old and ugly problem. Anyone here hate having this big heavy ROOT app running on your desktop 24/7? Anyone asked themselfs why this video output device isn't treated as every other device in the system : as a kernel driver? Moreover, who here has seen how insanely complex DRI is? It shoudn't be. This DirectFB with acceleration buit-in, is an answer to reestablish order to the Linux world. Push back video driver stuff back in the kernel, make shure it's stable, and leave complexety and crash prone code outside of root code. I see X on top of the DirectFB as an excellent solution to a cleaner, more stable, easyer to port Linux.
Everyone seems to be going on about how slow XFree86 is, and how we need a direct framebuffer layer bla bla bla... well on my box, Quake3 runs about 20% faster in Linux than it does in Windows.
Hardware: ASUS-CUV4X (via chipset), p3 866, 390mb RAM, Geforce256+32mb
Linux: Redhat 6.1 upgraded to Xf86-4.02, kernel 2.4.6, NVidia-1.0-1541
Windows: WinME with latest NV drivers, and all tweaks. (Was win2k and that was even slower)
Nothing special about that system, and I don't have any speed problems. Admitadly X does take up a fair bit Of hard drive, and about 4 megs of ram, but its I could scale that down pretty easily
It basically works, except for one glaring annoyance: at 1600x1200 the right quarter of the screen (starting about one inch from the top of my 19" monitor) seems to be displaying some memory locations other than the framebuffer. This area shows funky colored bars, which dance around within that area then I move windows around. The rest of the display is perfectly fine and snappy. Strange indeed.
Please stay there. We don't need smelly socialist scum like you over here. When the KGB is poking you with hot irons I'll be wathing it on MS-TV.
From Netcraft.com
[The site www.catalog.com is running Apache/1.3.12 (Unix) on Solaris 8.]
'nuff said.
The X protocol is designed for, and works just fine with, high latency links. The problem is with applications and toolkits that add unnecessary synchronization points by asking for lots of server information repeatedly, by asking for events at the wrong time and with the wrong APIs, etc. (some "modern" toolkits are particular offenders). But LBX also provides partial workaround for that by caching a lot of information.
X11 was designed from the start to allow implementations on both thin clients and workstations, a goal that it achieved admirably. The X11 designers, developers, and users were, from the start, primarily workstation users. Project Athena, one of the main users of early X11 implementations, was a big network of workstations, not thin clients. And the people who designed X11 knew what they were doing, given that they had several years of experience with X10.
I was begining to think that something is smelly here. :)
-- The ballad of arrivederci
Um, having developed for X for a long time, I must ask, what exactly is the problem? For plain GUI apps there isnt any that I've seen. Pick the toolkit that fits you the best and go ahead. What windowmanager unknowns? If you're dealing with the windowmanager outside of your chosen API you're going to make a very annoying application that doesnt work according to user preferences. Let the API and windowmanager work that out. Same if you're even close to getting to the parts of X programming that could reasonably be called 'aged' or 'cranky' (or more correctly, a PITA lowlevel API). If you're messing around there, you're not doing things right. Those parts were not meant to be used by the ordinary average application programmer, they were meant to be used by the toolkit designers. That's like dumping Win32 going for the lowerlevel parts of windows.
We have a secure, fast, reliable and stable standard. It's called X.
Comment removed based on user account deletion
Svgalib has the architecture to support hardware acceleration, but the drivers are crap. No alpha support in the API (that was back in the day that alpha was science-fiction stuff). Should die and stay dead IMHO.
I don't know anything about QtE.
aalib, please.
GGI is supposed to support hardware acceleration, but I don't know about alpha. I also don't know about the status of their drivers and how much they accelerate.
I don't know much about MicroWindows/NanoX. Transparency is mentioned.
There is also SDL, which has a FB target that provides some acceleration for a few cards, and there is also alpha support. I do not know the extent of the acceleration.
My opinion is that when you have a properly abstracted API, adding hardware acceleration is not that hard (it's basically as hard as the hardware makes it). The problem is when the hardware has features that the API doesn't have anything close, like for example alpha transparency in the Xlib API. XRender basically extends the API to have this, and even provides hardware accelerated implementations for some cards.
So citing "hardware accelerated" as a feature is not that impressive. It all depends on the API being flexible enough.
What I do see DirectFB providing is a single-application window support, much like OpenGUI does. OpenGUI supports the framebuffer, Svgalib, DGA2 and Mesa as back ends. Accelerations for the framebuffer could be much less than what is provided by DirectFB, but still, consider that it could be the exact same thing.
While none are exact replacement for each others, there is a HUGE amount of overlap between what all of these projects do. There is definitely room for some unification.
Why don't someone write a Xlib driver for DirectFB?
Why isn't DirectFB limited to the simple task of doing hardware acceleration, and something like OpenGUI layered upon it to take advantage of those acceleration?
Why do everyone think that a library that can only have one single application at a time can suddenly replace X?