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.
(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
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.
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)
... 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});
Have none of the "time to replace X" posters heard of Berlin?
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.
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?
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 -------------------
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?
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
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.
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
An alternative to X at the Linux console is overdue, but not a replacement for X.
X is a messaging and event handling system. There's nothing about it that says you ever have to open a window. You can use it for all sorts of local and remote event handling and messaging. The graphical aspect of it is what it's most used for. When you're writing a native X application, your last step is to start a loop that waits for events. Those events can be local or remote, and it's that capability that X should have been adapted. That it's had a great windowing system, X-Windows, built around it is perhaps even unfortunate. X is a marvelous technology that has never seen its full potential.
- Sig this!
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.
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
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.
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.
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
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
You want the X Resize And Rotate extension, short RandR. This extension will probably be in an upcoming release of XFree86. It's already in the kdrive server (mostly for handhelds). It allows the dynamic resize and rotation of the root X Window. You can also change the root depth without restarting.
As for the network transparency, useful as it seems to be to many people, does it need to be tied to the video functions?
It is not tied to video functions.
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
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
Comment removed based on user account deletion
you can run X apps on FB but not vice versa.
would that not be sufficient? if you had and X-server on your system to render the remote applications, could DFB not create a terminal to house the rendering? I would think that would work quite well.
I am the Alpha and the Omega-3
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!"
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)
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.
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 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.
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
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.
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.
I just don't get it. Why do people hate X? It's a fairly powerful system. There are implementations with excellent 2d and 3d hardware acceleration.
It does *not* use up "tons of RAM", as some people who don't understand the X architecture like to claim. If you see the X server using lots of RAM in top or the like, there are two very good reasons. (a) device mappings. Top counts this towards the total, but it isn't "real" physical memory being eaten. Have a 32MB video card? Guess why X looks 32MB bigger than it should?
(b) X stores pixmaps locally. This is why X *client* programs use less RAM than their Windows counterparts. One of the two (client or server) *has* to store any pixmap that's going on the screen. For speed over a network, it's much more intelligent for the X server to do so, since the pixmap will probably be drawn many times. So the client doesn't have to store its own copy...but it makes X look "bloated" because it's using some RAM itself to take load off the client programs. The overwhelming majority of RAM that X uses goes to this. If you're using Enlightenment with a pixmap GTK theme, the reason X is taking up more memory is because the client programs *aren't*.
The only real issue people have with X performance is that between the time an application wants to draw to the screen and the time the drawing happens, a context switch needs to occur. This is why the XFree folks came up with DGA, which avoids exactly this -- if you're just playing a game on the local computer, X imposes no overhead.
X does some damn cool things that Windows and friends will never do. Obviously, you can run programs over a network (without incredibly inefficient hacks like vnc). However, on a copy of XFree, hitting control-meta-kp or control-meta-kp- will let you switch resolutions, zooming in on something and letting you show stuff to people across the room (I use this a lot in my dorm room)
There are a few things that I don't like about X. X has a very sophisticated color management scheme, allowing you to output to just about any type of X server, but which can get complicated if you just want to draw something to the screen on your x86 box on XFree. That's why almost no one uses raw Xlib (X's own interface) and uses stuff like SDL or GTK, which handles the nasty details for you, and just lets you do your work.
XFree supports multiple monitors, desktops larger than your monitor, hardware alpha blending, shaped windows...
It's true that existing GUI "E-Z X configuration tools" haven't impressed me much, so you do have to maybe do a bit of poking to tweak out your configuration exactly the way you want it...but that's also true with most operating systems.
Oh, and Xlib doesn't natively support detatching windows from one X server and reattaching to another. I suppose this could be an issue, but since proposed replacements to X mostly don't do this *either* and since toolkits built on top of Xlib *can* do this...
Of course, you don't *have* to run an X server if you just want a console box...this guy doesn't run X.
For GUI systems, though, X is where it's at.
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.
I see what you are saying now, but, could they not allow directFB to redirect an application to the X server if it required network access from a remote user? or will that cause to many problems to be worth looking at?
I am the Alpha and the Omega-3
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
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!
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.
> 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.
We really like to support newer cards like GeForce or ATI Radeon. The problem is to get enough documentation to implement all the features supported by DirectFB. Taking X driver source does not much help, because X drivers support only the basic operations.
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.
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.
My proposed fix is to scrap visuals completely. For back compatability the server would advertise one TrueColor visual with support for all image formats of n*pow(2,m) bits, where n is 1,3,or 4 and m is 0,1,2,3, or 4.
A new interface would be provided for the few programs that care about the actual frame buffer format, and a new event that says "the frame buffer format changed" that indicates this information changed.
As for the resolution changing, the reason is that the window managers assumme the root window will not change size and are unprepared to move the windows. The programs also get the screen size when they are run, but most do not use this for anything and it is probably ok if it is wrong.
This sounds much easier to fix, however, and I'm not sure why it has not been done. I propose that the X server send a normal ConfigureNotify event to the root window when it's size changes. Window managers could be rewritten to look for this and respond as needed to move the windows so they are all on the screen. It may also be a good idea to add some interface that Xlib would use to stuff the new values of the screen width/height into the XDisplay structure, though that is probably not that important (lots of Windoze programs also cache the screen size at startup and don't handle screen resizes all that well...)
I'm not sure why nobody has added this.
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.
Well, most modern hardware (regardless of architecuture) is of one of two classes:
Packed pixel and color mapped.
Forget about colorplanes... even the Sparc 10s have an ATI controller using an 8bit colormapped display.
The only things you have to watch out for is 24-bit vs. 32-bit, 16-bit support (if you want it), and RGB vs. BGR order (with respect to the endianness of the platform). This can all be handled by blitting functions if you do 32-bit internally and double buffer.
Since fb is so low level, then DirectFB should have no problems porting to other architectures at all. Since the video hardware is the same, then the technique is the same. There would be no difference in the screen layout on your PPC nVidia then there would be on the x86 nVidia. The only important information to consider is byte ordering and bit depth. BTW, does fb.h support hardware panning/windowing through ioctls?
No, I haven't looked at the fb API, but I've used similar (very) thin abstraction layers like PTC and Allegro, both of which, by the way, can use fb as a drawing target.
Black holes are where the Matrix raised SIGFPE
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
Actually, using Windows Terminal Server is a bit of an eye-opener.
X-Windows is extremely sluggish compared to Windows Terminal Server. You can't do a lot with X over a 56k dialup link, even using ssh-compression or TightVNC, though a WTS session is quite usable.
Obviously, this is because client-side native widgets are used with WTS, keeping the network traffic to a minimum, but it strikes me that it couldn't be that hard to make X-Windows use a similar scenario.
i.e. If I am on a Linux machine, talking to another Linux machine, using UI libs that exist on both machines, why not have the server invoke the client UI libraries directly using some type of RPC, instead of using the uber-verbose X protocol?
Falling back to the X protocol would be good in the case of not having compatible libraries on both ends of the connection, but as Motif/GTK/Qt become available on Sun, Apple, Linux and other UNIX-like OSes, surely this approach becomes very viable?
There may be huge problems with this approach I haven't thought of, can anyone provide any insight into why this would be unviable?
I gots ta ding a ding dang my dang a long ling long
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.
I am NOT a MicroSerf, and I don't like a lot of Windows cruft nor am I terribly fond of trusting Microsoft for pretty much anything. But we could learn something from their approach - it works better BECAUSE they have a standardized widget toolkit. As another poster suggested, X is a good fallback option, but where possible all the rendering of widgets should be done on the client side for GTK/QT/whatever apps, assuming the libraries are there.
Furthermore, I am unwilling to accept, as are most users, that we should bend over and take the performance hit on local operations (80-90% of the time for non-server machines) for the 10-20% of the time we want to run something remotely. No, I don't want to give up the capability to run remotely, but I don't like the X performance hit for it (though some here seem to claim X performance problems are due to bad drivers - who knows?).
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.
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.
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
This has got to be the most ignorant post I think I've seen on Slashdot. First, you point out complaints, and then "address" each one, but don't really address it at all.
>>"X is slow!"
>Solution? Get rid of your bloated, feature-creep ridden sorry excuse for a window manager.
You're presupposing that it is the window manager which is the problem. Maybe X is the problem. Maybe my big bloated window manager makes ME as a person much more productive. I don't give a damn how many megahertz and megabytes it takes. But why have X introduce slowness that cannot be fixed by simply throwing hardware at it? Your solution, use a primitive stone age WM that works for geeks, but not for mere mortals. With this attitude, Linux won't go anywhere.
>>"X is bloated!"
>Umm.. Riiiiiiight.
Yet, you don't say anything to counter the argument that it is bloated. Yet you complain of WM's being bloated when they provide useful functionality.
>>"I can't play games!"
>Buy a console, or get a Windows box.
This is the most arrogant attitude I've ever seen. So you're suggesting that Linux (popular distributions using X) is obviously not useful for some things. It would have looked much better (on your part) to argue that X can play games. But ignoring that, you imply that rather than use something like <alternative to X> (i.e. DirectFB??) which (hypothetically) can play games, instead one should keep X, and give up the ability to use the system for one of his stated goals. Playing games is not my primary computer use. But that doesn't make gaming an illegitimate use for a computer. Even as a primary use. You suggest getting a game console instead of the hypothetical solution of abandoning X, rather than countering that X could play games, or that abandoning X wouldn't make gaming any better.
>>"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.
This attitude is further evidence of the "rite of passage" mentality. Linux should NOT be easy or approachable for mere mortals. We want to keep it complex on purpose. Only high priests wearing white robes (lab coats) should touch the computer. 25 years ago, this was the same argument about mainframe programmers. They called microcomputers "toys" and said to "get a real computer", just as today you hear zealots say "get a real OS". But microcomputers were approachable to the masses instead of having to go through a bureaucratic intermediary to get your program run on the computer, come back hours later to pick up your printout. Just as (it should be) with Linux, microcomputers enabled ordinary people to approach computers without spending millions of dollars and kissing up to the priesthood.
Go ahead. Keep Linux unapproachable to mere mortals. Keep your rite of passage attitude. Linux will never become mainstream. And either MS or something else will fill this role. It's not inconceivable that another free OS, in time, could displace Linux as the heir apparent MS killer -- given a different attitude towards mere "lowly" end users.
I'll see your senator, and I'll raise you two judges.