DRI Comes to DirectFB

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

Comments

f.i.r.s.t. p.o.s.t.

[Anonymous Coward]

fp

Re:f.i.r.s.t. p.o.s.t.

[sExon]

...ok

Slashdotted.

[Anonymous Coward]

Damn!!! That's a record.

MIKA BOOREM == hottest cutie ever

[Anonymous Coward]

gorgeous you simply cannot deny the beauty of this luscious little girl. who else wants to stick their tongue into her belly button?

Dear God, It's me Margarte.

[Real World Stuff]

Please make michael stop touching me in my swimsuit area.

Samsung digitizes your television expereince with its LCD TVs.

Designed for maximum versatility, the 15" LTM1555 LCD TV has an internal TV tuner and external jacks to allow you to view virtually any source - HDTV, DVD, VCR, Digital Video, satellite and more. Because it's fully digital you can even use it as a high-resolution PC monitor. For HDTV, an add-on DTV receiver/decoder outputs 1080i, 480P or 720P. The screen features an XGA (1024 x 768) resolution and a 400:1 contrast ratio. When displaying a PC input, the TV supports picture-in-picture, so you can watch video and pop-up video as you work.

The LTM1555's V-chip system allows parents to block rated TV and movie programs from their children. The digital comb filter offers an improvement over a standard comb filter to virtually eliminate edge crawl and rainbow effects while enhancing picture resolution. CaptionVision (CC) displays dialog that can be read along with encoded broadcast TV programs and pre-recorded videos. Other convenience features include a previous channel button, trilingual on-screen displays, a translucent on-screen menu system, and a variable sleep timer.

W.O.O.T

[Anonymous Coward]

Developers: X comes to Y, with full Z support. Acronym, vague reference to my mother, link. Acronym, link to previous (dupe) post, acronym. Rinse and repeat, unrelated Microsoft insult.

Now all we need is a better OS

[Anonymous Coward]

Rather than one that has to have sectiones recompiled to work nicely with different hardware that is

Re:Now all we need is a better OS

[Anonymous Coward]

You are very funny, I love you so much. Touch me in warm places.

Re:Now all we need is a better OS

[molarmass192]

Trolls out already, and it's so early too! Ok, I'll bite:

1) Loadable modules, read about it. On second thought, don't, I'd rather you just stay on Win.

2) I can tweak and/or modify the drivers and recompile if I feel like it, otherwise I can just use the binaries that came with my distro. I guess you have that option under Win too, right?

This Lin vs. Win sh*t is really starting to get old -or- maybe I just need more coffee to put me back in a fighting mood.

Re:Now all we need is a better OS

[Anonymous Coward]

Loadable modules don't mean dick if you don't have a well defined API and a stable ABI for the kernel. Which Linux still does not have.

Its very nice that you can recompile your drivers from source. Its not very nice that someone has to keep back/forward porting drivers to various kernel versions, and binary drivers only sometimes work. Other Operating Systems got this right decades ago, yet Linux is still stuck with the same old problems.

Re:Now all we need is a better OS

[91degrees]

1. Loadable modules are nice. The seem to keep complaining if the driver version differs from the kernel version.

2. If I want to write a third party GPLed driver for windows, then I can. Most people don't need to and so they don't bother.

3. I suggest proper coffee. Make sure it's freshly ground.

Troll mode off, if I did decide to write a kernel, I'd probably write something very different from Linux. Aspects of it are quite good, especially the support for obscure filesystems, but really adding drivers is rather unpleasant. Somehow BeOS makes life seem so much easier. Just drag and drop. Things just work.

Re:Now all we need is a better OS

[Anonymous Coward]

Can I ask you a question? What exactly does this have to do with DRI and DirectFB?

Aww hell, I'm anonymous, so I'll answer.

1. Compile your kernel without module versioning.

2. Good luck getting it signed. However, that's up to you. Most people don't understand what a driver does, much less why one would need to be written.

3. I must agree.

I hope this answers your questions for today. Thank you for calling ;)

Re:Now all we need is a better OS

[91degrees]

Can I ask you a question? What exactly does this have to do with DRI and DirectFB?

That's two questions. The answer to the first is "Yes", and the answer to the second is a complaint that drivers are rather difficult to install in Linux compared with just about any non MS OS. Said complaint was quite rightly modded down as a troll.

1. Compile your kernel without module versioning.

Can I do that? Fair enough. I'll look into it.

2. Good luck getting it signed. However, that's up to you. Most people don't understand what a driver does, much less why one would need to be written.

It's not essential to get it signed. Even XP will still use unsigned drivers, and unless MS want to annoy a lot of developers by forcing them to use a special "development" version of windows. Generally speaking nobody needs to do write drivers.

another source on incompatibility

[eenglish_ca]

It sounds like a great project but native driver support and linux, whoa back right up. For most consumer hardware that is far form a reality. Personally I have an ATI card so this is good for me but it may take quite a while to ad support for others. I can't wait to give it a try though should be exciting to see and work with because gui speed definently is lacking in the major desktops for linux which just slows down the programs that run on them.

Re:another source on incompatibility

[Anonymous Coward]

Most modern consumer hardware *does* work in Linux. Stop trolling the threads! What do you guys do, just sit here and wait for these to pop up, and paste in some macro or something? GUI speed is not lacking in Linux. If you have a problem, it's because you are using a frickin' framebuffer mode. How many times do we have to tell you trolls this?

Re:another source on incompatibility

[Anonymous Coward]

Not used mozilla, have you?

Re:another source on incompatibility

[SubtleNuance]

?

If your gui runs slowly, patch your kernel.

Re:another source on incompatibility

[KeyserDK]

GUI "speed" /IS/ an issue. Not the way you may think of speed but as in visual artifacts.. ie 'refresh speed'.

The perfect world program would not have any visual artifacts when resizing and dragging windows. This is one of the few X issues that seem to be hard to solve ;). There has to be improvements on how toolkits AND windowmanagers work together through X.

Try resizing your window, does the toolkit follow instantly? or does it lag?
Try moving your window fast around the screen... any update lag? ie. 'white/black' trail?

The good thing is that these issues have no impact on doing 'work'. However it is cruft for the visually pleasing desktop.

Re:another source on incompatibility

[Anonymous Coward]

I agree totaly I have no problems with my windowing even with my two year old laptop screen
redraws are fast and I even have all the Eye candy I could ever want.

Re:another source on incompatibility

[jandrese]

Try resizing your window, does the toolkit follow instantly? or does it lag?

No, and X has never done this (all the way back to my Pentium 75 with a S3 Trio64 video card).

Try moving your window fast around the screen... any update lag? ie. 'white/black' trail?

Nope, although my old P75 would lag a bit when moving around big windows. Windows was worse in this regard (although it was Windows 3.1 at the time). Once I upgraded to my PII-400, this wasn't an issue anymore. Granted I run a fairly small desktop (1280x1024x24), so it's not so hard to blit the stuff through the AGP bus.

Now, if I set up the windowmanger to have the position display in the center of the window and drag the window around, that position display will leave a trail.

However, I do not believe that having applications control their own window is a good idea. In fact I consider it to be the #2 boneheaded decision Microsoft made (#1 being the VM swapping behavior). How many times have you wanted to move an application, out of the way of something but found you can't because the application is busy? How many times have you tried to resize the window of a busy app and realized you couldn't? That drives me nuts.

Re:another source on incompatibility

[KeyserDK]

I never said i wanted the application to control their own window.

Also when i mentioned toolkits i meant "qt/gtk". And WM's metacity/sawfish/kwin. They may mean bloat to you but they do come with 'must-have' features for a user desktop.

These issues are in fact known by hackers, and they are working on it. I can't help wonder what the X SYNC extension is needed for when you claim there isn't a problem.

And if the app doesnt redraw itself if it is busy, I would consider it a bug.

Re:another source on incompatibility

[be-fan]

Try resizing your window, does the toolkit follow instantly? or does it lag?
>>>>>>>>
It follows instantly. I'm running KDE 3.1.1 on Gentoo 1.4 using a 2GHz P4 and a GeForce4 MX with the NVIDIA drivers. The only tweeks I've done:
1) Using kernel 2.5.66. There are some interactivity updates in this one, though Gentoo's stock 2.4 is probably better overall (I/O scheduler in 2.5.66 is a bit weird).
2) dotNET theme. Keramik is quite fast, but there is a synchronization issue that makes the gradient menubar seem to "crawl" across the screen when resizing.
3) "RenderAccel" turned on in the NVIDIA drivers (its off by default).

Pretty much everything resizes instantly, even JuK, which has a listview with over 1000 elements in it. The scrollbars seem a little uneasy at times, but they never tear or rubber-band noticibly, so it could just be the update rate on my LCD. The only thing I've seen that actually rubber-bands is konqueror browsing Slashdot. If anybody is using Konq, this is a great way to understand exactly where the bottlenecks are. Open up the Slashdot front page. Resize the window quite small. At this size Konqueror won't bother anymore to layout the text to fit the window. It'll let it spill off the window (which IE does at a significantly larger size, btw). Now, if you resize the window through a limited range of motion at this size, you'll see no rubber banding. Now try the same thing at nearly full size. The HTML and CSS requirements necessitate that Konq now goes through every element on the page and lays it out for the new window size. This happens for each frame. This is where a lot of the rubber-banding comes from.

Re:another source on incompatibility

[egreB]

No, and X has never done this (all the way back to my Pentium 75 with a S3 Trio64 video card).

Is that so? Impressive. I'm curious, because on my 400MHz with 128MB RAM and a Riva TNT at 1280x1024x16 (my main computer; don't tell me to upgrade, it does its job quite well), I get artifacts when I move windows around. It's actually not a "black/white-trail", but bits of the window that moves stays on the underlaying windows for a split second, creating a trail of the window I'm currently moving. Yep, latest drivers from nVidia. And do I have to say; in Windows 98 the windows moves much more smoothly (that being said, moving windows don't keep me from moving from Windows)..

Re:another source on incompatibility

[jandrese]

Well, you might try using the Nvidia binary drivers (or the native X drivers, whichever you aren't using). Also, if the blitting is too much for your machine, you can switch it to wireframe drag mode, which should pose no challenge to any video card these days.

Me too!

[Anonymous Coward]

How to gain Karma like a pro!

In this day and age, whoring Karma on Slashdot is easier than ever. With more moderators and a lower signal to noise ratio (If you don't know what that means, don't worry!) means that Karma can easily be gained by following a few simple rules when you are carefully crafting your Slashdot post.

• Vaguely mention the DMCA. It doesn't matter what the topic of discussion is, those four magic letters glow like a beacon to any moderator with points.
• You can get double points if you spell the acronym as DCMA throughout your post. This is especially effective if you're replying to someone who has just used the correct acronym in their post.
• MPAA and RIAA are another pair of gems. Use the phrase "RIAA/MPAA" in every post you make, and that Karma will flow!
• Always confuse the two. Complain loudly about the MPAA suing over MP3 downloads, or the RIAA trying to stop you from downloading DeCSS.
• Don't bother to understand the difference between Patents, Copyrights and Trademarks. If the topic of discussion is about patents, claim that "this wouldn't have happened before the DCMA" (See above)
• Always remember, It's Microsofts Fault! Try to craft vague conspiracy theories that include Microsoft.
• Spell it "Micro$oft" or "M$". Moderators will lap it up.
• If all else fails, blame the Government. Do not at any cost attempt to understand basic politics, as that will make you look opinionated. Just blame the current political leaders.
• Likewise, blame the French. Double points if you use the phrase "Cheese eating surrender monkeys".
• If you're losing the argument, start a flamewar about the war with Iraq. Accuse the other party of being French, or "a pinko commie"(See above).
• Claim that you only download stuff using P2P to "try before you buy".
• Start a flamewar by claiming that "Piracy isn't theft". Violently flame anybody who dares to disagree with you.
• Double points if you attempt to defend your position by stating that you "wouldn't have paid for it anyway, so they haven't lost a sale".
• The Iraqi Information Minister was funny, wasn't he? Your post should be like one of his speeches. It'll be funny.
• Ensure your sig has a Karma joke in it. You know the ones, something like "Karma: Bogus!" Ensure you retype your sig every time you post a comment; double sigs look cool and you wouldn't want the people who have sigs disabled to miss out, would you?
• Remember! Never, ever read the related article or any background information before you state your opinions. You're too busy to do that, and its not like the moderators will notice either!

Good luck! Within no time at all, your Karma will be Excellent!

Re:Me too!

[Anonymous Coward]

This is the hard truth, and any moderator who mods this down should be shot, if you don't agree, don't touch it, modding it down will send your worthless existence to hell!

Re:Me too!

[awol]

Post an article describing how easy it is to be a Karma whore and the Karma will flow

Oh, by the way...

[Anonymous Coward]

What the fuck is DirectFB anyway?

Re:Oh, by the way...

[Anonymous Coward]

And what is DRI, for that matter?

Re:Oh, by the way...

[IamTheRealMike]

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

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

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

Re:Oh, by the way...

[Erwos]

Embedded devices are probably _the_ place where DirectFB makes the most sense. These don't have the same needs a desktop has, and lack the network interfaces (right now, I guess) to make the networking features of X useful.

However... I don't see any point in moving DirectFB to the desktop, or using it anywhere that has a network interface and the appropriate hardware to run X. There are many, many areas where X makes a lot of sense (even in embedded devices!), and DirectFB is not going to be performance panacea that some people make it out to be. It's going to be best as a "light" display system for embedded hardware, IMHO.

-Erwos

Re:Oh, by the way...

[Frothy Walrus]

Dirty Rotten Imbeciles, a great early punk/thrash crossover band.

Re:Oh, by the way...

[SomeOtherGuy]

%s/a great/the great/g

Cool that DRI is getting some good plugs on /.

Here we go....

[IamTheRealMike]

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

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

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

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

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

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

Re:Here we go....

[Anonymous Coward]

Sears, Wal-Mart, etc. DO have children in their underwear, AND these catalogs/flyers are sent directly to your home, my home, AND to the home of a pedophile. Why is it ok to see a child in her underwear in a Wal-Mart ad, but appalling to see a girl dressed in CLOTHES on a website??? (And Cindy had clothes on in every picture I saw on her site). Pedophiles should be punished and medical/mentally treated, but is locking our children in the basement or having them live in a bubble the answer???

Re:Here we go....

[popeyethesailor]

See Michael's comment - Choice is indeed better.

Re:Here we go....

[Yarn]

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

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

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

Re:Here we go....

[Anonymous Coward]

So many people complain about X because so many people have problems with it. This isn't rocket science. X is shitty... X is slow... X is loaded with 1980s features that no-one uses while desperately needed stuff is ignored, or left on the back-burner for years.

Plus, X is designed to be slow from the ground up with its crappy network transparency. Windows manages to do a better job by adding network use on top of a local system - it has lower bandwidth requirements and more stability. It's a pretty damning indictment of the rank incompetence on display in the X system.

Re:Here we go....

[Tyler Eaves]

I must say, that's lowest UID I've ever seen. /offtopic

Re:Here we go....

[IamTheRealMike]

That's what they're developing Fusion for - to allow multiple windows to interoperate on the same desktop. It doesn't have to be used for this, but AFAIK that's a long term goal of the project.

Re:Here we go....

[Anonymous Coward]

This is the lowest UID I've ever seen.

Re:Here we go....

[MartinG]

DirectFB cannot gain network transparency

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

Re:Here we go....

[Thud457]

That User is a known unreformed troll.

Re:Here we go....

[FooBarWidget]

But does it support important extensions? Xrender? Xvideo? Xshm?

Re:Here we go....

[Anonymous Coward]

I agree, with small correction: DirectFB is not *windowing* system, it is rendering one. Windowing is done in X protocol.

Re:Here we go....

[infiniti99]

... puts X compatability on a layer _above_ the windowing system. Many people believe this is where network transparency belongs rather than entangled within the windowing system.

Yup, this is my feeling exactly. I have no problem with X11. DirectFB is interesting because it allows us to have a much better design for our graphical subsystem (first and foremost, by using Linux kernel drivers). It does not replace X11 at all, just the driver base of XFree86.

Can everybody please stop the X11 naysaying? DirectFB and X11 are complimentary.

Re:Here we go....

[Anonymous Coward]

This is the best troll ever, and it even got modded up.

Re:Here we go....

[Anonymous Coward]

Amen, preach it brother. People love to dis Windows (myself included), but the sad fact is the Windows GUI feels much snappier than Xfree86. AND we can get X11 just fine on Windows (I run X-win32 in rootless/multi window mode on my windows machine. lets me bring up applications from either the on campus solaris workstations or my Linux machine, though the Linux machine is on a kvm so it's not very beneficial to use x11 to use it). I think embrassing DirecFB could yield a much better desktop system for Linux in general. Keep backwards compatibility, but make make it external. Don't base current things on an infrastructure as old as X11 when we can create a superior solution with X11 "on the side" for those who need what it offers.

Re:Here we go....

[LazyBoy]

So what did you use?

Re:Here we go....

[IamTheRealMike]

Ah, no, I didn't make myself clear, sorry.

DirectFB apps, that use the DirectFB API, are not network transparent, and probably never will be. DFBTerm for instance.

The fact that most apps are capable of using the X protocol today, and that DirectFB implements a small X server, does not mean that apps which talk to DirectFB itself are network transparent.

Re:Here we go....

[Arandir]

The people who want DirectFB seem to be the same people who complain that they can't get a 648FR in Doom. "It's that damn networking transparency stuff in X! It's slowing me down!"

Instead of throwing out X just to please a tiny segment of gamers, let's take a sensible approach. Win32 didn't become obsolete when DirectX showed up. In fact, they seem to work nicely together. Why can't the same thing happen in *NIX land? Why must it be one or the other? Have DirectFB tell X that it's going to use this region on the screen, and then have X promise it won't do anything in that region.

p.s. This may be the way that DirectFB is designed. I'm not sure. But I do know everytime the name "DirectFB" comes up, people crawl out of the woodwork complaining that a general purpose solution isn't optimal for their specific purpose task.

Re:Here we go....

[damiam]

Really?

Re:Here we go....

[burner]

True, but if it does catch on, I'm sure someone will port the vncserver to directfb. That'll be good enough for most purposes.

Re:Here we go....

[Koatdus]

2) On the other hand, using DirectFB does not mean we lose network transparency. The X11 protocol won't disappear.

Lets be honest with ourselves here, Network transparency is nice and all but how often do most people use it? I administer to a bunch of machines all over the place but I use ssh or ssh and tightvnc. It is pretty rare that I open an Xterm across the network.

For my home and laptop machines I would gladly recompile "no_network_trans" if such an option were available and it would speed up my display.

I am not saying that it is not useful but it is not as great as it once was. TightVNC is much faster across both fast and slow networks. (especially if you put a light weight window manager on the far end.)

Re:Here we go....

[MartinG]

I see what you mean now, and I completely agree. However, I see this as an advantage. It means those apps where network transparency is desirable (which could be _everything_ for some users) can use it, but those which only care about raw speed and/or smaller memory footprint etc, such as embedded apps and possibly some games that want to get close to the hardware can ignore the network transparency, or not even include it in their distro.

Personally, I think network transparency can be retained without the app developers having to think about it, but still take advantage of dfb. For example, gdk could use xlib etc if it finds a $DISPLAY, but otherwise use dfb. That way, local users dont even need X installed to use gtk apps, but those who want the transparency can get it by installing the client side parts of XFree and exporting a DISPLAY.

Of course, if dfb really took off and supported the range of h/w that xfree does, then the hw support part of xfree could be ignored, leaving the dfb folks to concentrate on the fastest most efficient h/w access, and the X11 ppl thinking about important non-hw issues like polishing RENDER etc.

The question I don't know the answer to is this:

Is is a good idea generally to do the low level hardware access in a more kernel based way like directfb does, or should it be almost all userland based like we see with XFree86.
I don't know the answer. My usual feeling is obviously keep it out of the kernel, but then again sometimes if it needs to be fast and/or it has a close relationship with other parts of the kernel then perhaps it should go in. (eg. nfs)

Re:Here we go....

[Yarn]

I've written a small wrapper library to allow me to switch between the different frontends. It's currently going to SDL as it allows me to do some of the development on my laptop when I'm idle at work.

No chance

[Anonymous Coward]

I have no intentions of touching your armpits, you sweaty little oik.

Re:No chance

[Anonymous Coward]

How about Mauritias?

Gotta get my eyes checked...

[Anonymous Coward]

I read that as "DRI Comes to DirectFBI", and just couldn't understand what DirectFBI is... DirectSound, DirectX, DirectFeds?!

Re:Gotta get my eyes checked...

[Anonymous Coward]

From the ass of Satan, direct to you!

Re:Gotta get my eyes checked...

[jdgeorge]

I read that as "DRI Comes to DirectFBI", and just couldn't understand what DirectFBI is... DirectSound, DirectX, DirectFeds?!

Ahem....
DirectFBI's communication protocol is FedX.

wow

[Anonymous Coward]

Already /.ed

SHUT UP YOU SHITFUCK PAEDOPHILE !

[Anonymous Coward]

NVIDIA not supported

[Anonymous Coward]

"The embedded-1-branch of Mesa is a port of DRI to the framebuffer device (fullscreen only, no input). Currently supported are ATI and Matrox (after porting the driver a few days ago)".

Once again NVIDIA is not supported. NVIDIA wake up and release your specs and manuals under NDA to the developers. You are only hurting yourself by denying your product less acceptance in the open source world. And for the NVIDIA supports open source argument try moving between X versions and see how well your NVIDIA card is supported with all the bells and whistles you thought you paid for.
Anyone know where I can find a MATROX AGP 1x card?

A disgruntled NVIDIA customer.

Re:NVIDIA not supported

[Anonymous Coward]

Huh? NVIDIA is the first company which provided professional quality Linux drivers. Because of this many companies have moved to the Linux. Isn't this enough for your acceptance?

NVIDIA cards work very nicely with every XFree 4.x version.

If you are complaining about closed source drivers, then I have a bad news for you. There isn't a SINGLE company which releases specs for open-source developers for the new hardware.

Matrox Parhelia 2D driver is closed source, ATI has stopped DRI funding and DRI drivers won't work with new R300 and R350 (Radeon 9500, 9600, 9700 and 9800) cards.

That's why adding 3D support to DirectFB seems to be quite pointless. I doubt that ATI, NVIDIA or Matrox will port they drivers to DirectFB.

Re:NVIDIA not supported

[RdsArts]

What help does a NDA give to someone releasing a free, open sourced software?

If the code will eventually have to be released free and open, then a NDA only impeeds their ability to code a driver, as now they can't even reverse engineer a driver. If it's binary only, who'd write it? Will it, and the NDA, be used to outsourced a driver to a professional team, or will it be a amature team making drivers?

Both ways the code would never be auditable by the community at large.

The current drivers are at least partially open. Heck, has anyone considered seeing if we could write a wrapper to get it working in the framebuffer? There are ways other then a NDA that a solution can be found.

*tosses 2 cents*

Re:NVIDIA not supported

[Anonymous Coward]

3dfx were the first company. They supported Daryll Strauss' production of 3dfx linux drivers for years.

Re:NVIDIA not supported

[phaze3000]

You're completely missing the point.

If nVidia provided specifications for their cards then they wouldn't need to write drivers. ATI and Matrox don't need to port their drivers to DirectFB because they provided these specs, so others can write them for them.

Re:NVIDIA not supported

[Paul Jakma]

This is bull. Lots of graphics vendors used to provide open specs to the open source community. I had a Matrox MGA2064W Mil2 with perfect open drivers and high quality 2D 1600x1280@24bpp a /long/ time ago. It took lots of lobbying and pressure from users/developers, but eventually those companies that wouldnt provide specs usually would open up.

Then the rot started, Matrox (who up till then always were very good about open specs) stopped providing full specs. At first, they restricted information to the Warp engine included with the G200 (needed for 3D), and provided binary microcode. This was sort of ok, as it was code that could only ever run on the card ASIC. Then they provided a binary only library for some of the dual-head and other features rather than releasing specs. NVidia stopped providing specs (which they had previously under pressure and NDA) and released binary only drivers.

The worst part is that the new-wave of linux users accepted this. Bought the cards and downloaded the drivers and used them without any complaint - glad even that the vendors were releasing binary only drivers, but completely ignorant and, worse, undoing the many years of earlier hard lobbying by open source developers and users to get manufacturers to provide specs.

I think you're wrong about Parhelia btw, the open Matrox mga driver works with it in 2D iirc. The open NVidia driver also works with most NV cards in 2D. But for how long will we continue to have open graphics drivers, now that the new wave of linux users have shown the manufacturers they are more than happy with closed drivers.

Oh, and if you're not using x86 - you're screwed..

Re:NVIDIA not supported

[Anonymous Coward]

Do you know how scarce good X driver writers are?!! Even if NVIDIA released full specs today, it will probably take years before open source drivers are at the same level as the current NVIDIA drivers are today.

• Writing 2D/3D graphics drivers is not trivial
• Open source developers capable of actually writing these drivers are in short supply.
• By the time good drivers are out, the hardware is 3 or 4 generations behind .
• Choose between 2, 3 Open source developers coding in their spare time vs. the whole driver engineering team of a company? Easy pick!

NVIDIA has the best damn driver support on Linux, period. Matrox? Just try to get a Parhelia going in 3D under Linux. We're still waiting for proper ATI support in Linux. The current one is severely lacking (Radeon 9700 Pro, glibc 2.3.x, OpenGL 1.4, etc).

Re:NVIDIA not supported

[Anonymous Coward]

How about some cheese with that whine! If you think Nvidia's binary goo is so evil you should try ATI's with anything other than an rpm based distro.

Re:NVIDIA not supported

[be-fan]

Actually, I've looked into wrapping the NVIDIA driver to load it independently of X. It would be a giant pain in the ass. There are 243 functions referenced by the current NVIDIA XFree86 module (down from over 300 in previous releases). They fall into 3 major catagories.

--- Trivial remappings: Stuff like xf86sin() vs sin() and xf86open() instead of open(). These calls are there to abstract each driver module from the underlying OS.
--- Support routines. These include stuff like software fallbacks for rendering routines, hardware detection routines, etc. These would take more work to reimplement, but aren't that closely tied to X.
--- X-specific routines. Stuff like graphics contexts, etc. These would be hard.

Suppose it would be doable, since XAA is well documented and the source is available, and the drivers don't appear to use any functionality not defined in the X driver API, but I certainly would not want to try.

Re:NVIDIA not supported

[Anonymous Coward]

ATI has stopped DRI funding and DRI drivers won't work with new R300 and R350 (Radeon 9500, 9600, 9700 and 9800) cards.

When did ATi fund the DRI project? If they once did and now don't why should we care? It's not like DRI has ever been solely dependant on hardware manufacturers for support. As far as R300 R350 support goes, IIRC ATi gave Tungsten Graphics the (NDA'd) specs and hardware samples to boot for those cards. Give it some time, between XFree86, Mesa, DRI, and the differing drivers that need to be written, those guys have some work cut out for them.

Re:NVIDIA not supported

[Anonymous Coward]

How about some cheese with that whine! If you think Nvidia's binary goo is so evil you should try ATI's with anything other than an rpm based distro.

Did the poster say ATI's binary goo is not evil. NO.
Did the poster say all binary goo is evil. NO.
Did the poster say all binary goo is not evil. NO.
Did the poster say no specs is evil. Yes.
Please take a logic class before replying again.

Some of us out here have the capability to write drivers but can not because of the restrictive practices of most companies in the graphics card business. Could we reverse engineer there own drivers? Well Yes we could but few will go to such lengths.

Now with that said do you think Richard Stallman is a loon because he thinks software should be free. If so you must logically think Linus and company are loons. Now imagine a world where all open source operating systems do not exist (OpenBSD, FreeBSD, Linux, parts of MacOS 10, etc). Be afraid.

How do you like your troll whine with your cheese?

Great 'article' about how to get a nice console

[humming]

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

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

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

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

Re:Great 'article' about how to get a nice console

[SmegTheLight]

Besides being a cool thing, what does this have to do with the DirectFB product ?

I thought the bootsplash stuff just used plain vesa framebuffers to load a background image that console text overlays on ?

Re:Great 'article' about how to get a nice console

[Yrd]

It does, but it's something else to do with the framebuffer device...

Re:Great 'article' about how to get a nice console

[SeanAhern]

Please, people, make links to your pages:

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

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

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

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

Note, I didn't check the links, I just pasted them.

Dirty Rotten Imbecilles?

[Anonymous Coward]

Skate or die, dude!

Obligatory regular expression

[Znonymous Coward]

Screenshots are available.

~ s/are/were/

This will kill X in the long term.

[Krapangor]

DirectFB has much more capabilities to compete with high performance desktop systems like MS Windows XP. We might get some DirectX alike stuff very soon which enables Linux to be a real gaming platform.
Many people will shout now: "Behold the holy X-protocol ! For it is network transparent and make your desktop run everywhere." But how often you really need X these days ? Most remote work done is professional admin or research stuff. All people I know working in this area use just a plain text shell. This graphics stuff is for admin job completely obsolete. And if you are kinky-winky then you could always get a secure admin-webinterface using OpenBSD.
Face it: we don't need X any longer.
The X window system has it's roots in the ole mainframe area where people had slow, cheap terminals and there was a big mainframe in the cave together with a group of homo neandertalis.
But these days are gone. Today every kiddy has the capacity of the mainframe on/under his desktop. We don't need bloated, slow graphics protocols anymore for doning work on the big iron. The big iron is under your desk.

I think the linux community should switch it's direction on the desktop completely and drop the bloated X Windows support. Just port QT to DirectFB and we are done - KDE works automatically. And this would weed out Gnome this obsolete, second desktop system which just draws resources from the KDE pool and thus slows down advancement of open source systems.

Re:This will kill X in the long term.

[Jellybob]

That almost made sense until you started ranting about Gnome being obsolete.

I don't use KDE or Gnome, but I do think that the choice is a good thing.

Re:This will kill X in the long term.

[Bazman]

Big iron just got bigger. I bet the 'big iron' under your desktop doesn't have 1/100 of the power of the High Performance Cluster of Sun machines we have here. And we do run apps on there with graphical output, so we need remote X displays.

You kiddies can play with your little iron under your desk, we grownups will always want to work with bigger stuff.

Re:This will kill X in the long term.

[Anonymous Coward]

Eh? With the KDrive Tiny X server memory use is negligent... maybe next you will say that terminals should stop being ansi compatible, as no-one needs that too? It really doesn't add too much in the way of resources if thats what your looking to do and you do gain a lot

Re:This will kill X in the long term.

[Anonymous Coward]

speak for yourself. X is just fine for my needs and I can even play UT2003 on Linux and ALMOST get (3 or 4 difference) the same frame rates as I do in XP. If you don't need network transparency, fine, but it does NOT MAKE YOUR DESKTOP GO ANY SLOWER!

Re:This will kill X in the long term.

[Anonymous Coward]

I use X, running apps off of a central development server. ddd over the network anyone? Every Windows box here even has an X server installed. I use X at home, and often run apps from home when at work using you gessed it, the X protocol.


I need X.


As for Linux not being a "real gaming platform", hardware accelerated OpenGL is fast enough on linux. And if you actually can get the specs to your graphics hardware, as in the PS2 linux kit,
there's nothing stopping you from writing "real games". SDL give you everything you need, running on XFree86, framebuffer, etc.

PS I write games for a living.

Dave

Re:This will kill X in the long term.

[tjansen]

If you would port Qt to DirectFB... what would manage your windows? How could DCOP work without authentication over X11? What server manages drag&drop and cut&paste?
X11 does far more important stuff than only letting you access the framebuffer.

Beside that, no mainstream system will have a chance to succeed if it only fulfills the needs of 95% of the users. Unless you get 100% it doesnt have a chance. MS understands this, thats why they have put *a*lot* of effort into the Terminal Services and RDP.

Re:This will kill X in the long term.

[DrXym]

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

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

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

Re:This will kill X in the long term.

[Goth Biker Babe]

That's one of the stupidest things I've ever heard. It's a retrograde step. The reason that X has been around for so long is because it's a design that works. Hell, even NT, 2K and XP have client server graphics at the core, just not as good as X.

The problem with Linux is not the X design but the implementation. XFree is rather boaty and slow. What we need is a new version of X rather than to throw away the protocol. There are plenty of established extensions to support graphics, overlays and the like when you need them.

You must also remember that Linux != UNIX. X wouldn't die even if the kiddies stopped using it on their Lienucks boxes. I have Solaris and IRIX machines at home which use X. Your NVidia graphics card was probably designed with the help of engineers who developed IRIX's X implementation.

If someone wants to do a framebuffer implementation than fine. The whole point of open source is that it allows choice. If someone wants something and they are willing to develop it for the community, that's great. Open source also exhibits evolution, survival of the fittest. Those which are are found wanting fall by the wayside.

X is still here because it works, plain and simple. Throwing it away would be madness.

Re:This will kill X in the long term.

[Christianfreak]

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

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

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

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

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

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

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

Re:This will kill X in the long term.

[CrosseyedPainless]

All good questions. I'm not knowledgeable about the internal workings of Qt/Embedded, but I know my Sharp Zaurus runs a version of Qt without running X at all.

Re:This will kill X in the long term.

[tjansen]

But, in case you didnt notice, you always see one app at a time and everything runs as root.

Re:This will kill X in the long term.

[BrookHarty]

Some people need X11 and some don't. If local desktop performance and modern windowing behaviour can be achieved by completely bypassing XFree86 and its associated window manager and other processes then it should be done.

I was wondering the same reason. Why cant DirectFB be the driver/interface for the Display, and let Xfree just port the Xserver to the OS. Xfree doesnt need Driver support anymore, All drivers are for DirectFB now.

Xfree for cygwin doesnt care what GFX card I use, and I can use it in rootless mode. Only thing I wonder is if Xfree can support all the hardware features in DirectFB. (And widget support doesnt rely on the gfx card, just the xserver, so no problem with X network transperancy)

Sounds like a great Idea to me, let xfree be a straight xserver, and let DirectFB handle the gfx drivers. (Then we dont have to wait for Xfree to put the driver fixes that has been shelved for months, example ATI's submissions, and the reason for the Xfree spinoff.)

Re:This will kill X in the long term.

[naelurec]

I have to second this notion. I've always looked at Unix/Linux as the ultimate pick-and-choose OS .. I can build in what functionaility I need and get rid of functionaility that I don't need. Unlike Windows where lots of apps are bundled (IE, Outlook Express, etc..etc..), Linux gives me the freedom to customize virtually every aspect of my system... well except one --> X11.. It might be great for a network / sysadmin configuration, but for a desktop, it blows. With so much activity happening at the desktop, it is imperitive that X11 be REMOVED! We need to back something like DirectFB that will allow for a much more responsive interface, an interface that can meet the needs of desktop users and provide for the needs of the desktop Linux user. Like Apple, if X11 is needed, it should be provided in-addition-to the core fast desktop. It would be pretty cool... :) Not quite sure of the likelihood or feesibility of such an undertaking, but definitely something to think about.

Re:This will kill X in the long term.

[FooBarWidget]

Heck, even if it IS a KDE developer, then he STILL doesn't have any right to complain about other people not working on the project he wants them to work on.

Re:This will kill X in the long term.

[drinkypoo]

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

I'm sorry, how does remote desktop fail to do the things we really want from X? Admittedly it does not allow you to run single applications on your existing desktop, but what we really want it for is for logging into systems remotely and doing maintenance. It also does things which X doesn't do without addons, such as audio redirection. (I know you can use network audio daemons but now you have another network connection to make. It's fairly trivial to add it if you're already using ssh tunneling but otherwise it can be a network annoyance.)

Re:This will kill X in the long term.

[Anonymous Coward]

Havin streamed an entire desktop with less bandwidh than a single modern x app with a compressed protocol is something I would hardly call a failure :-)

Re:This will kill X in the long term.

[transient]

Then why is it that Microsoft keeps trying to copy it (failing miserable) ala Remote Desktop etc.?

Other people have said it, but you are so wrong I have to say it again. Remote Desktop and Terminal Services are not failures. They're the only way we can serve database-intensive applications to remote sites on slow connections.

Microsoft has got some things right. Deal with it.

Re:This will kill X in the long term.

[GlassHeart]

Open Source development isn't about what everyone wants, its about what the developer wants

Really? The Linux kernel (the Linus tree, in particular) contains lots of driver code for hardware I'm sure Linus doesn't personally own. A lot of risky changes are meant for architectures that Linus doesn't have, or may not even have seen. In fact, it may be interesting to see what percentage of Linux (in terms of lines of code or whatever) Linus personally uses.

Yet Linus accommodates these changes, and adds them to his tree. They make Linux a better product for many other people, even though it does less than nothing (any feature you don't need is an unnecessary potential bug) for him. Do you think Linux would be nearly as successful if Linus refused patches for any hardware he didn't own?

Sure, the developer can do whatever he or she wants, but the successful projects keep their users in mind.

Re:This will kill X in the long term.

[usotsuki]

The parent to your article was IMHO a flamebait, as judged by the phrase "high-performance Windows XP". I don't think any serious /. reader thinks Windows any version is more "high-performance" than some version or clone of Unix. Prove me wrong!

YHBT. YHL. HAND.

-uso.
High performance?

C:\>_

Re:This will kill X in the long term.

[Anonymous Coward]

X has been doing this since it's inception. Infact X was made specifically BECAUSE of this reason.

You obviously haven't compared X to Microsoft's offerings or'd you know just like anyone else. X has got it right in this arena. Also a 20+ yr lead.

Re:This will kill X in the long term.

[Minna Kirai]

Not necessarily. In the default Sharp install, running Java programs (as one example) will create movable windows that partially obscure programs below them. There is a simple kind of "window manager" behavior going on.

Also, it is completely possible to rearrange file permissions so that Qt on the Zaurus can run as non-root. Why Sharp chose not to do this is difficult to imagine.

Re:This will kill X in the long term.

[jbolden]

100x a faat PC isn't really that much. I wouldn't be such a braggert.

Re:This will kill X in the long term.

[mr_goodwin]

Newer models (sl5600, slc700) run as a non-root user.

Re:This will kill X in the long term.

[Enahs]

Hi. I'm a KDE user, and I want app integration, consistent look-and-feel, etc. on an operating system that works. And GNOME just doesn't feel nearly as integrated to me. Sorry, but it doesn't.

Don't tell me to use Windows just because the GNOME project isn't capable of tight integration.

Re:This will kill X in the long term.

[Christianfreak]

This has nothing to do with Linus accepting or refusing patches. The issue would be if IBM came to Linus and said "Hey Linus we need Linux to work on our big mainframes, but we aren't going to help you or pay you to do that we just want it to work." Would Linus agree to that, probably not. That's what I'm talking about here. In Open Source the users should contribute, and if they don't they shouldn't complain about features lacking or not lacking.

It isn't about wheither or not developers should listen to users (they should) but its about wheither developers should take seriously one person who's screaming "Fundamentally change Linux because I said"

Re:This will kill X in the long term.

[Christianfreak]

I didn't say that people who like KDE should go to Windows. I told the parent poster to go use Windows if he wanted an OS where the graphical interface is (mostly) dictated to him.

If you like KDE, fine, use KDE, you have that choice. I like a combination of Blackbox with GNOME and KDE apps better, I don't want to be forced to use KDE which was what the parent was suggesting.

Re:This will kill X in the long term.

[transient]

I'm well aware of what X has to offer. I was responding to the assertion that Microsoft had somehow failed to deliver with Remote Desktop and Terminal Services. And not only do I not give a shit who did it first, but the software we need to serve doesn't run on Linux, making any comparison academic at best.

Re:This will kill X in the long term.

[treke]

This isnt true, using the QPE libraries you only see one app at a time, but it is possible to create your apps in windowed mode ( try showing your application using QWidget::show() and not QWidget::showMaximized()). Most QPE applicaions specifically show the window as being maximized.

Also, it doesn't have to run everything as root, but it's the easiest way to do things. QT/e needs to be able to read and write to the device files for your mouse and framebuffer, but otherwise it is doable. What it does have problems with is having apps running as different users on the same display, although it is an easy enough hack to add support for running an app as root while logged in as a different user.

Re:This will kill X in the long term.

[Anonymous Coward]

"hardware accelerated OpenGL is fast enough on linux."

Yes, even when using Perl to drive it :-P

Re:This will kill X in the long term.

[Mooncaller]

First some background. Some former co-workers who were resently layed off, along with myself, and some who were not, but see no futur, are getting ready to start writing crossplatform internet based games. We will eventuly attempt producing a Linux based game consol. As I use to fill the roll of Software Architect, and am the most familiar with Linux and graphics issues, I have been tasked with doing a preliminary design. I was investigating DirectFB. My question is, how suitable is SDL for imbeded applications? I have more questions, but need to get back to working on my resume. Obviously, outside employment will be needed to bring in money untill this project becomes profitable ( looking at years here). So no more wasting time on /.!

Re:This will kill X in the long term.

[GlassHeart]

In Open Source the users should contribute, and if they don't they shouldn't complain about features lacking or not lacking.

You are entitled to your opinion of what should be in the open source world. I'm not trying to change your mind.

What I am pointing out is that successful projects do keep their "customers" in mind. If a security hole is discovered in Apache, by your logic, nobody can demand a patch, much less an immediate patch. That's fine, but Apache wouldn't be successful if things worked that way.

Also, it's easy to say "you should help", but the nature of software is that it is usually many times harder for anybody else to fix something than the original author. This is even more true with bigger projects. The fix from the original author is more likely to fit in well with the overall design, and be less buggy.

So I'm not arguing that you should listen to every random idiot with an opinion. However, your statement leans too far the other way, probably resulting in software that only developers will use. The freedom inherent in open source software permits higher quality software, but IMHO not if you ignore the end user too much.

One word:

[Anonymous Coward]

BORING!

next article, please....

Speak for yourself, buddy.

[Anonymous Coward]

Yeah, I've got a machine enough power to make a 70s era mainframe look as powerful as an NES. I also have a fiancee who lives with me. So, should I build yet *another* monster machine for milady to use? Or should I get a couple of refurb laptops, slap Debian on 'em, and use them for remote X sessions and make efficient use of my uber-powerful Athlon with a gig o' RAM?

After all, I can get a couple of secondhand Dell laptops for the price of another Athlon with all the trimmings and an LCD. I think I'll stick with X. If it isn't network transparent, it's crap.

The French do suck

[Anonymous Coward]

You fuck.

LP!

[Anonymous Coward]

Last P0st!!!

No fun for nVidia users.

[Jacek Poplawski]

Maybe now you realize why closed source drivers are worse.

Re:No fun for nVidia users.

[Paul Jakma]

Why is the parent modded as flamebait?

The post is 100% correct, this /. article demonstrates precisely the downsides of closed hardware (implied from closed source drivers), ie the open source community cant hack on them and do new things with them.

Re:No fun for nVidia users.

[Krach42]

I wrote the blitting function for the nvidia DirectFB driver. I had to take the code from the radeonfb driver. They didn't have a working blitter when I was into directfb awhile ago.

I still like DirectFB, and would like to see better support for hardware in it. Then I'd probably ditch my XFree86, and run DFBX exclusively.

BTW: the nvidia blitter is still probably hacked together, and hasn't ever supported transparency.

Re:No fun for nVidia users.

[Anonymous Coward]

Maybe now you realize why closed source drivers are worse.

As someone who uses an NVidia chipset for their main desktop/workstation's video card, I'd like to say: I had already realized why closed source drivers are worse =P. I really wish all hardware had fully open driver specifications...

Fresco

[p00ya]

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

That's why I'd love to see fresco enjoy some more support/activity/interest.

Sweet!

[IWantMoreSpamPlease]

Dirty Rotten Imbiciles are going to work on a free and open project...glad to see punk music making the "crossover" with computers.... ...oh wait

Re:Sweet!

[Overly Critical Guy]

Good thing you used your karma bonus modifier to post that.

Typically anything ending with "...oh wait" is junk.

Come on, I have to try...

[IamTheRealMike]

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

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

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

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

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

Re:Come on, I have to try...

[windex]

This is so funny that it made me laugh out loud at work. I'll be blaming you when I get fired. Hope you have an umbrella insurance policy that covers "Slashdot Trolling Collateral Damage".

You're 12 years old, aren't you.

[Moderation abuser]

Cos anyone with any real experience uses remote displays regularly.

We use it for engineers, for secretaries, for managers, for salesmen, for janitors even, but it seems that script kiddies like you don't use it.

BTW, You wanna know why xterminals are still used and why the X protocol is more important today than it's ever been before? Nothing to do with hardware costs these days. It's because 1 administrator can manage hundreds or thousands of desktops, with ease. Wanna know what the single largest set of costs in I.T. are? Support. Those dozens of wintel administrators needed to manage the big iron mainframes under every desk.

Face it, you're a moron.

So, what?

[cdemon6]

Let's fork XFree, merge it magically with DireectFB and produce a lightweight X-windows brother...

Then, let us call it DirectX. :)

oh the comedy

[gse]

Wow, another DRI reunion tour? Any original members on board this time?

Re:oh the comedy

[SomeOtherGuy]

Spike Maybe. I was thinking reuinion of the "4 Of A Kind" lineup....A little more mainstraim -- but still a punk edge.

Naive Question

[Godai]

I've noticed that a lot of the discussion on DirectFB is like all other X 'replacements' -- half the people talk about how great it will be because it will jettison the useless bloat in what they call outdated technology, while the other half rail about the loss of the network-transparency that they can't live without.

Well, this may seem naive, but maybe both sides are right? I mean, sure, network-transparency is wonderful but how many people are really using it? 1 in 20? Maybe? At the same time though, that one person is probably using it for somthing uber-useful, like eliminating 200 desktops in lieu of dummy terminals :)

So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular? Why can't you have a well-written, clean API (I've heard horror stories from people who've had to write code directly to X) that lets you plugin in modules like 'network-transparency' or 'anti-alisased fonts', or even everyone's favourite 'alpha-blended windows'?

I'm not saying this would be trivial, but surely it'd be worth the time and effort so that the 95% of users who don't want it can simply turn off network-transparency, and the 5% who do can plug it in without a lot of hassle.

As I said, surely this is naive. So flame away.

Re:Naive Question

[FooBarWidget]

"I mean, sure, network-transparency is wonderful but how many people are really using it? 1 in 20?"

Multiply that by 1 million and you'll get 1.000.000 in 20.000.000.
Don't mark something down as "useless" bloat just because only what seems to be a minority in percentages use it.
Even if only 1% use network transparency, if there are 500.000.000 computer users then there are still 5 million people who need network transparency!

Re:Naive Question

[Anonymous Coward]

Why you suggest would be a graphical system where you plug X on top of it, just like a delegator model in OO where you simply plug in listeners which you then can serve in a separate thread. Isn't that exactly what DirectFB targets in the long term.
And I agree 95% of the people shouldn't suffer because 5% need a feature which drags the whole thing down absymally.

Re:Naive Question

[IamTheRealMike]

So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular?

Well, X is actually modular. It doesn't use the network subsystem when run locally.

Why can't you have a well-written, clean API (I've heard horror stories from people who've had to write code directly to X)

I've just been doing some Xlib programming (for wine). It's not that bad. Win32 is certainly a LOT harder and less intuitive. But very few people use Xlib directly anyway.

that lets you plugin in modules like 'network-transparency' or 'anti-alisased fonts', or even everyone's favourite 'alpha-blended windows'?

Yes, X provides exactly that, with the exception of alpha blended windows, but that's because more hacking is needed inside the XFree drivers architecture to make it work at acceptable speeds.

Re:Naive Question

[Anonymous Coward]

DirectFB has an X server for it, so you gain the benefits that DirectFB offers without losing X compatibility.

Not that I've gotten it to work yet on my computer :)

Re:Naive Question

[Paul Jakma]

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

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

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

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

Re:Naive Question

[usotsuki]

868K, w00t! Now if this could be ported to DOS and WatTCP, maybe we could have ourselves a real Desqview/X clone, and a real target for FreeDOS. *g*

-uso.

Re:Naive Question

[Jim Buzbee]

Also remember that when you look at the "size" of a running X server, that it usually includes mapped memory from your graphics card. So if you have a 1024x768x32 desktop, 3 Meg of the size shown in "top" will be memory from your graphics card.

Re:Naive Question

[Paul Jakma]

yes indeed it is. if you look at the figures i quoted they do not add up to the full 5.9MB figure i quoted for the size of the X server - the difference is mapped memory, the framebuffer being one of the mappings. However, the framebuffer on the ipaq is tiny - 320x240x16bpp -> 150KB, so its fairly insignificant.

Re:Naive Question

[Anonymous Coward]

It's more like 500-1000 people who need network transparency, to be honest. Everyone else has moved on.

Re:Naive Question

[MechaStreisand]

there are still 5 million people who need network transparency!

Why does everyone keep mentioning this like it matters? If people make a new X server without any network transparency at all, is that going to make the old X suddenly disappear?

Of course not. If people want to use network transparency, let them use the old X.

Re:Naive Question

[iabervon]

You need some form of IPC between applications and the shared display. There's no good reason to make this network-opaque, since you don't lose anything by providing the option of sending the calls over a network, if necessary.

As someone who's actually written a reasonable amount of code directly for Xlib, it's not that bad. There are a few annoying things, but you can mostly just ignore them these days (allocating colors is hopeless, but almost everybody these days has a 32 or 24-bit TrueColor visual, so you can just ignore all the stuff about colors and visuals and do the obvious thing for pixel values). It could use a new set of drawing primitives (like, perhaps, the set from SVG), but the API is otherwise not bad. The font stuff is a mess, since there were quite a number of attempts which got in before things settled down. Different character encodings can go away, since there's Unicode which handles everything. And so forth.

I think an X12 which cut out the obsolete stuff and provided a complete and consistent specification again (so each font has an XFont, no matter exactly what mechanism is used to render it, and XDrawText will draw it). The server would be the same as X11, except that it would be specified to always have a 32-bit color visual, which the server would simulate if it was running on something that actually didn't have 32-bit color for some reason.

Re:Naive Question

[Anonymous Coward]

868 kilobytes? 5.9MB of RAM? That's a lot of memory for a graphics library, even with networking. It is bloated. They're talking about making things more modular, so hopefully that will help.

[I]n all probability it is all your fancy graphical apps not cleaning up the pixmaps they create as they go along! Fix the apps!

A graphics library with an API that makes it easy to write crappy programs must share some of the blame for those crappy programs.

Re:Naive Question

[FooBarWidget]

It's already been done. Locally, XFree86 uses shared memory for transporting pixmaps, and Unix Domain Sockets for communication. No TCP/IP is involved.

Unix Domain Sockets on Linux are heavily optimized. They're just as fast as shared memory.

Aww bollocks

[IamTheRealMike]

The original post (which was itself quite amusing) is now at -1 Funny, so you won't see it, nor get the parent post.

Rather worryingly, it's at -1 Funny and yet no "Overrated" mods are shown in the box below - considering that overrated moderations are no longer shown and are not meta-moderated, this seems like a wide open hole for people who want to abuse the moderation system. What is the reason for this inconsistancy? Why is overrated/underrated special?

Usual discussion

[Anonymous Coward]

Crowd: X is bloated
X DefenderS: X is not bloated it is just everything else on top of X
Crowd: Network Transparency is a hog
X Defenders:No it isn't there is just not a single app which does it right, why do have apps use for instance something like fonts, pine doesn't need it either
Crowd: X is slow
X Defenders: No it isn't run two X servers side by side and see that they have comparable speed
Crowd: X is bloatware
X Defenders: No every single line of the 7 million lines of code is needed, even the code from the flight sim
Crowd: Look there is something better and faster
X Defenders: We don't need that we have network transparency (which implicietly is unusable over slower lines)

I guess there are another 100 points which can be added

Re:Usual discussion

[FooBarWidget]

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

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

GNOME and KDE are slow, X is not.

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

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

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

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

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

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

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

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

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

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

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

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

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

Re:Usual discussion

[Anonymous Coward]

Your answer is exactly the attitude of the X people/defenders I wanted to critizize. Basically the attidude X does everything right there are always others to blame.

But lets go back to the arguments. Your speed argument is exactly what I wanted to point out
(X is not slow I compared X to X), face it no matter what window manager, put an X box side to side to a MacOSX Jaguar box or WinXP box and you will see that both later ones outperform your fabolous X box by the factor two til three. That KDE is another drag on the whole performance is another issue. As for your network argument, you picked up pretty much the only app which you can tunnel via a modem connection, the fact that an entire RDP Desktop needs as much bandwidh as xterm alone should say a lot.

As for your compatiblity argument. 99.9% of the most important apps sit on top of toolkits, now if qt and gtk2 are ported (gtk already is) see people flock away from X left and right.
Again Xterm probably besides some other stone old apps will be one of the apps which won't be portable.

XV, nice argument, but you know were the DirectFB project developed from, there won't be too much need of XV then :-)

As for bloat. 7 millikn lines of code for a simple windowing system is bloat (as for m%$ windows it has around 10 million lines but only a fraction of that goes into GDI and other directly windowing related stuff) and basically unmaintainable, constant reports of bugfixes never worked in
in various forums pretty much resemble what I assume.

Just another question, now that you have given valid arguments, why do 99% of all X apps implement things wrong :-)

Re:Usual discussion

[FooBarWidget]

"Your answer is exactly the attitude of the X people/defenders I wanted to critizize."

I don't know if you are the same AC as the one I'm replying to, but this sentence imply you are.

"Basically the attidude X does everything right there are always others to blame."

X doesn't do everything right. But there are other things to blame.
And I critisize people like you because of your attitude: the attitude that all bad things in the world is because of X and that it must die off no matter what.

"But lets go back to the arguments. Your speed argument is exactly what I wanted to point out
(X is not slow I compared X to X)"

OK if absolute numbers from x11perf aren't enough I'll show you my results from a Windows ME - XFree86 comparison.
A year ago I wrote an app in SDL that blits 1000 640x480 surfaces and calculates the average frames per second.
On Linux, I compiled it with no optimizations (gcc 2.96). The SDL binaries are from RedHat: optimized for i386.
On Windows, I compiled SDL manually using Mingw (gcc 2.95) with Pentium optimization, and the testing app (no code modified) with no optimizations.

Then I ran the test app in both Linux and Windows. I expected the Linux version so show a slightly lower FPS because of the IPC/driver/whatever overhead. But surprisingly, the FPS in Linux is VERY close to FPS in Windows. The FPS in Windows is like 2 frames higher than the FPS in Linux. I repeated the test several times and sometimes the Linux FPS is slightly higher, sometimes equal and sometimes slightly lower.

Conclusion: on my system, XFree86 is just as fast as Windows ME in blitting. The differences are caused by other processes and other random stuff.

"face it no matter what window manager, put an X box side to side to a MacOSX Jaguar box or WinXP box and you will see that both later ones outperform your fabolous X box by the factor two til three."

Not on my machine. See above.

"the fact that an entire RDP Desktop needs as much bandwidh as xterm alone should say a lot."

I've never used RDP before so I'm not going to comment on this.

"As for your compatiblity argument. 99.9% of the most important apps sit on top of toolkits, now if qt and gtk2 are ported (gtk already is) see people flock away from X left and right."

Right, just take a look at the Nautilus/kde-libs/gnome-panel source code. You can find lots of references to xlib functions.

"As for bloat. 7 millikn lines of code for a simple windowing system is bloat (as for m%$ windows it has around 10 million lines but only a fraction of that goes into GDI and other directly windowing related stuff)"

How do you know how many lines code the GDI has? (*insert scary music here*)

Windows by default doesn't ship all drivers for all video cards. XFree86 on the other hand ships *all* drivers it has. I think it would be more fair to compare XFree86 minus drivers with Windows GDI minus drivers.

"and basically unmaintainable, constant reports of bugfixes never worked in in various forums pretty much resemble what I assume."

I think that has more to do with their organization than X's architecture. And that's exactly what Keith Packard is protesting against.

If there's something better than X, in all areas, then by all means go ahead and replace X. But there is no such thing. DirectFB is not a worthy full replacement for X and is not finished yet. Fresco is far from usable. GGI is stalled. What else is left?
Until somebody comes up with something significantly better, we should fix existing thins rather than complaining over and over that X is the root of all evil and that it must die.

Re:Usual discussion

[colin_n]

I am no expert on how every layer of a windowing system interacts. I do know however that on exactly the same hardware, if I use XFree86 with the Nvidia drivers, instead of Windows XP/2000/98, the screen takes longer to redraw, applications take longer to load up. XFree86 *FEELS* slower than windows. As long as this happens, average people (like me) will feel reluctant to use *nix as their desktop. Why not take a tip from Apple. It should be possible to have a version of XFree86 that takes full advantage of a modern graphics card. I believe that OS 10.2 uses OpenGL for the entire interface?

Re:Usual discussion

[Natalie's Hot Grits]

"Oh sure there's XDirectFB, but 1) doesn't that make the whole point of ditching X a joke and put us right where we started? 2) does it support important extensions like Xrender, Xshm and XVideo?"

No.

You are missing the point. The point is to directly render all local desktops. Why on earth would you indirectly render your local desktop just because you are too lazy to implement a direct rendered model? That is the objective of DirectFB:

To implement the X protocol OVER a direct rendered local model, rather than implementing local models over X's indirect model. (note, this is how X clients work in win32))

The problem with all you X zealots that think you are god and all knowing is that you actually don't know everything. And you have proven this in your post.

Re:Usual discussion

[be-fan]

I believe that OS 10.2 uses OpenGL for the entire interface?
>>>>>>>>>
This is probably the millionth time I've said this. I feel like "Celebrity Jeopardy" skit where Keanu Reeves keeps saying "whoa, I know kung-fu" and Alex Trebek keeps saying "for the last time Mr. Reeves, no you don't!"

Quartz "Extreme" does not use OpenGL for "the entire interface." It's right in Apple's Siggraph paper, with pretty pictures and everything. Quartz still uses the CPU to render graphics into memory buffers. The only time OpenGL gets used is when those buffers are composited together to get the final picture. This is a step up from the previous software compositor, but other windowing systems don't even have the extra compositing step, which exists only to support the transparency and genie effects.

Re:Usual discussion

[Anonymous Coward]

Thanx about the X11perf tip, very cool.

1 Ghz AMD Thunderbird, Nvidia Geforce 3 Ti 200, 512 MB RAM (about 128 MB used, the rest currently in use as filecache).

XMMS was playing in the background :)

x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40100000 on :0.0
from null
Fri May 2 00:24:53 2003

Sync time adjustment is 0.0594 msecs.

30000 reps @ 0.1755 msec ( 5700.0/sec): 500x500 rectangle
30000 reps @ 0.1751 msec ( 5710.0/sec): 500x500 rectangle
30000 reps @ 0.1745 msec ( 5730.0/sec): 500x500 rectangle
30000 reps @ 0.1746 msec ( 5730.0/sec): 500x500 rectangle
30000 reps @ 0.1742 msec ( 5740.0/sec): 500x500 rectangle
150000 trep @ 0.1748 msec ( 5720.0/sec): 500x500 rectangle

Woah!

x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40100000 on :0.0
from null
Fri May 2 00:26:51 2003

Sync time adjustment is 0.0620 msecs.

1200 reps @ 5.2156 msec ( 192.0/sec): ShmPutImage 500x500 square
1200 reps @ 5.2064 msec ( 192.0/sec): ShmPutImage 500x500 square
1200 reps @ 5.2098 msec ( 192.0/sec): ShmPutImage 500x500 square
3600 trep @ 5.2106 msec ( 192.0/sec): ShmPutImage 500x500 square

Wow!

Re:Usual discussion

[FooBarWidget]

No, it's you anti-X zealots who think you know everything and blame everything bad in the world on X. It's also called elitism: you think you're better just because you're against X. Well, you're not.

Re:Usual discussion

[FooBarWidget]

Tip: apply the desktop/interactivity patches for your kernel: http://members.optusnet.com.au/ckolivas/kernel/
Before I did this, my Linux desktop was indeed a bit slower and less responsive than Windows. After I applied the patches, it became just as fast as Windows, and in some areas even faster. Try it out, you will notice the difference.

As for applications taking longer to load, I don't know why that happens, but app loading time has got nothing to do with the windowing system.
But the main problems are in GNOME and KDE, because fvwm/twm/BlackBox/WindowMaker/Xfce are incredibly fast compared to them. GNOME and KDE are what need to be optimized further.

It's strange, I installed a RedHat 7.3 desktop for a friend and he said he can't notice any difference in speed compared to Windows 98 (even without the kernel patches).

Re:Usual discussion

[Natalie's Hot Grits]

I never said i was against X, idiot.

I use it every day for remote desktops. XFree86. I also use it locally on Linux. Every day.

I just happen to know (unlike you) that its not optimal for local display. There are better solutions out there that are faster, more efficient, and more suited for local desktop use. Sure, XFree86 does the job. But far from optimal. The competition has proven this. XFree86 was designed to display remotely. That is what the entire X protocol is used for. It just so happens that you can use the same principles to display locally

Until you realize that XFree86 is slower than most 2d desktop rendering systems when used locally, you will be blind of the facts. Its as simple as that.

Re:Usual discussion

[FooBarWidget]

Nope, YOU are blind of the facts. Everything you say is just theory. In theory, X is slower because it was designed for remote displays. But benchmarks do not lie! My benchmarks clearly proved that XFree86 is just as fast as Windows on my system. The numbers say so! If you mod down hard benchmark numbers then you are ignorant to the reality.

Re:Usual discussion

[Anonymous Coward]

...put an X box side to side to a MacOSX Jaguar box or WinXP box and you will see that both later ones outperform your fabolous X box by the factor two til three.

I know that this discussion has become too old for my post to really hit this conversation, but this is such a ridiculous claim that I can't let it slide. I have two machines here at home. One dual boots Debian and W2K. The other dual boots Debian and OSX (Jaguar). If there is any difference in GUI performance between X11 and W2K I can't detect it. On the Powerbook I find OSX to be so irritatingly slow in comparison to XFree86-Enlightenment-GNOME that I stopped booting into it. What makes this comparison even less favorable to OSX is that XFree86 is running on the framebuffer. If you want to advocate alternatives to X11 then do so. I'm already with you in spirit. If you think X11 has problems then state them. I'll listen. But claiming that XFree86 is slow compared to the Microsoft or Apple display systems flys in the face of my daily experience. In the case of OSX especially, I find your comparative claim so ludicrous that I don't believe that you believe it.

darn, I read this as a GEM2003 announcement...

[The Lynxpro]

...you know, a 21st Century version of the GUI by (Intergalactic) Digital Research, Inc. (DRI)... you know, the originators of DOS, when it was known as *cough* *cough* C/PM... I'll go find my Atari ST for comfort...

Re:darn, I read this as a GEM2003 announcement...

[usotsuki]

LOL

Current development of GEM
Open-source (GPL!) ROM replacement for Atari ST, featuring GEM/3

GEM isn't dead yet!

(BTW, neither is CP/M (link is to a work in progress on DOSPLUS, which is based on CP/M 4.1)

-uso.

ATI support

[Anonymous Coward]

If you are looking for native driver support for ATI in a laptop, you may be out of luck since ATI does not support these cards. They claim it is up to the OEM e.g. Dell to provide drivers.

Re:ATI support

[Jeffrey Baker]

There are open source drivers for Radeon Mobility chips in XFree86 4.3.0 and in the DRI. That covers 2D and 3D. What were you hoping for?

Re:ATI support

[Anonymous Coward]

It is up to the OEM to give out and support drivers for "powered by ATI" solutions. However, you can download and use the ATI reference drivers (catalyst).

Re:ATI support

[Anonymous Coward]

Support for power management.

Hooray!

[Anonymous Coward]

More stuff to hook into DRI! But wait...has anyone at all been working on actually STABILIZING DRI?!

DRI is a mess. What's the most stable card...the ancient Mach64? I can't recall DRI for the G400 ever working reliably. It would consistantly lock up my Voodoo3 based machine as well.

DRI is why I went with NVIDIA. Say what you want about the closed drivers but hell, they work and they work WELL, which is more than I can say for ANY DRI drivers.

X and networking

[ceswiedler]

To prevent uninformed comments about X:

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

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

Re:X and networking

[Anonymous Coward]

It doesn't change the fact that X still has the crappy, bloated and slow client/server split. -- it is this that slows everything up, including further development.

Re:X and networking

[kingkade]

First, i know nothing of X. But I have a question: doesn't X still use the protocol over UNIX-domain sockets, which would still have to travel up and down the network stack?

Re:X and networking

[Minna Kirai]

The link you mention claims

"As stated earlier, this FAQ deals only with AF_INET sockets."

So it's not the best source for Unix domain sockets. However, Unix sockets ARE NETWORKING, from a software perspective. The same socket.h function calls are invoked for TCP/IP, or unix sockets (or even ipx, x25, and other stuff).

are the most efficient form of IPC on Linux

That's the crux of the common complaint. IPC = "interprocess communication". Some other prominent GUI systems don't require interprocess communication to update the screen, and can provide quicker response with less overhead. IPC will always be slower than system calls with no context switching.

This is a possible reason why Microsoft Windows 98(tm) running on a 100mhz Pentium seems so much snappier for minor UI-interaction tasks (pulling down a menu) than a same-vintage Gnome on identical hardware.

Re:X and networking

[ceswiedler]

Yes, X uses a protocol over the local sockets. That's inter-process communication. The X server runs as its own process, and that's a Good Thing.

No, it does not ever touch the network stack. Really. I promise. You can run X locally on a kernel which doesn't even have networking compiled in. Unix sockets are like signals, shared memory, message queues, and other forms of inter-process communication. They simply use the same socket interface as TCP/IP sockets.

Re:X and networking

[Natalie's Hot Grits]

"X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER"

Actually, your wrong. If you knew anything at all about how X works, you would realize this.

The reason that X is slow locally is because 2D windowing isn't directly rendered like DRI 3D or DirectFB. In XFree86, all communication is done via UNIX sockets. This is essentially a network protocol, and is just as slow as far as overhead is considered. Until XFree86 uses direct rendering locally for everything, it will continue to be significantly slower than it could for everything except remote use.

So insted of making XFree86 use direct rendering for local use, people are making side projects that don't implement the X protocol. Why would they? They would have to be compatible with 30 years of legacy API, which would hold the project back technically considering there are limited developers.

The problem everyone has with X is that the people who control X do not care about local performance for 2D windowing. They consider that since local methods are just special cases of the remote methods, they will be at least the same speed, or faster than remote, and that's good enough for them. The answer to everything is to put an X layer over a direct rendered model. But this is either out of the scope of the XFree86 Project, or is something they do not want to deal with (since none of them really care much about local performance).

Re:X and networking

[Fnord]

A "direct rendering" method as you describe it is where the functionality to draw a specific graphic object is in the application (or in a library linked to the application) and all the system does is map video memory into the application's address space for that application to do bit by bit operations on. In a case like 3d rendering, where everything is a completely custom graphic, and the only predefined operation is transforming of a polygon description into a rastered image, which is done by a few very low level syscalls.

Windows doesn't use this method. Windows has the entire widget set in the kernel (or the hal or whereever they draw the line these days), and there is a syscall for each individual widget.

The idea behind X was to figure out just how high you need to make 2d primitives to have them be accelerated, and draw the line right there. So there is a call (in the form of an X protocol request) for each accelerated primitive like draw line and bitblt, and widgets are made up of these and stored in application side libraries.

And no, local X does not go over a "essentially a network protocol". Unix domain sockets are extremely simple and extremely fast. When an X application makes a request, it sends X protocol information over the socket by packing a request data structure and writing that structure to the socket. Since its a local socket, the kernel just memcpys that data structure into a buffer in the X server which is waiting on a read. No network stack, no network hardware, no processing. Just a memcpy. And as for the formatting of the data structure, a shared memory system would do that too. In a shared memory system, an app would pack a data structure into some piece of shared memory and then trigger a semaphore. The display server/framebuffer system/whatever would then memcpy that data structure out and interpret the request. There really is almost no difference.

Please stop bashing X until you've looked at how it actually works.

Re:X and networking

[moncyb]

You seem like the guy to ask. Does X Windows use networking for the local server? ;-)

They have nothing to do with networking and are the most efficient form of IPC on Linux.

What are these epics thingies everyone keeps talking about. This guy told me shared memory or mmap can be faster for transfers of thingies like huge pictures. He even uses shared memory with the X thingie.

AF_UNIX sockets still have nothing to do with networking.

My psychic wants me to ask: What about NFS? Why did you link to a page titled "Unix-socket-faq for network programming" which, while interesting, does not seem to have any information about Unix domain sockets? Why do I have to use -nolisten tcp to keep XFree86 off the internet? How is it possible to plug my lightbulb into a window? It's a socket isn't it?

Isn't the advantage of X over DirectFB security? DirectFB requires all programs be run as root. The DirectFB advantage is it seems much more lightweight. Good for those who can't use a bloated system. I doubt the speed differences between X and DFB will be noticed on today's systems. I thought X sucked, but that was when I had a 100MHz 486 with 8MB RAM and used virtual terminals / SVGAlib instead.

Re:X and networking

[Adnans]

The reason that X is slow locally is because 2D windowing isn't directly rendered

Actually there were some folks who implemented direct rendering for 2D in X and guess what, it didn't make any difference! The problem is not direct rendering, it's the inefficiency of Xlib (e.g. requiring replies when it's not needed, etc).

In XFree86, all communication is done via UNIX sockets. This is essentially a network protocol, and is just as slow as far as overhead is considered. Until XFree86 uses direct rendering locally for everything, it will continue to be significantly slower than it could for everything except remote use.

Looks like you know even less about X and sockets. There are problems with X/XFree86, but they're not what you're describing.

-adnans

Re:X and networking

[Alien Being]

It uses the top layers of the network stack, but switches between alternate lower layers based on AF_UNIX vs AF_INET.

"Unix sockets are like signals, shared memory, message queues"

Signals and semaphores can only send a few bits of meaningful info. Shared memory does nothing to notify the other party. Message queues are very similar to datagrams, but can't provide a stream.

There's a very good reason why both local and remote connections and bindings are reported by netstat.

Re:X and networking

[Virtex]

That's the crux of the common complaint. IPC = "interprocess communication". Some other prominent GUI systems don't require interprocess communication to update the screen, and can provide quicker response with less overhead. IPC will always be slower than system calls with no context switching.

But the IPC overhead consumes less than 1/100th of 1 percent of the time it takes to draw a window or widget when running locally. Removing it would make no noticable difference. Even a benchmark would be hard pressed to see any difference.

This is a possible reason why Microsoft Windows 98(tm) running on a 100mhz Pentium seems so much snappier for minor UI-interaction tasks (pulling down a menu) than a same-vintage Gnome on identical hardware.

Gnome does a lot of things that make it slow. But that doesn't mean X is slow by association. Back in the 100MHz Pentium days, I was running FVWM, which was very quick and snappy even on the machines of the day. And it was running on X. If you want to complain about the slowness of Gnome, then blame it on Gnome, not X.

Now consider the following: Because X is network transparent and modular, someone could write a server-side toolkit for it. Let's say gtk+ is ported to X as a module, and the gtk+ libraries are modified to look for this. This means that running programs remotely no longer requires large amounts of network traffic, since drawing the widgets and basic interactions with them would be handled entirely on the display server. This would make running remotely nice and snappy. This type of extension would be relatively easy on X because of its flexibility, whereas on Windows it would be extremely difficult. I praise this type of flexibility. You bash it.

Re:X and networking

[ceswiedler]

OK, sorry, the FAQ wasn't the best link.

Whether or not Unix sockets are networking depends on your definition of networking. Yes, they use the same interface as INET sockets. However, they're completely 100% limited to local-host communication. How can something be a networking component if it can't talk to another host?

As I see it, Unix sockets are a form of inter-process communication which happens to act like inter-host communication. Which makes it easy to write code which communicates with either another process or another host, and does so efficiently in both cases. AFAIK, Unix sockets are the fastest form of IPC. Do you know why the shared-memory extension for X is mostly unused? Because it turns out that it's not any faster than Unix sockets, once you add synchronization.

Unix sockets are NOT the same as for example accessing a local drive through an NFS mount on the local server. That does indeed go through networking to the 127.0.0.1 address (which is fast, but not NEARLY as fast as AF_UNIX sockets).

Re:X and networking

[moncyb]

Some other prominent GUI systems don't require interprocess communication to update the screen, and can provide quicker response with less overhead.

Yeah, with either no security, or the kernel does all the work. Both often cause problems. Direct kernel calls for graphics primitives may not be a bad thing (in a way DRI allows this), but I think a separate process should manage windows, security and higher level functions. DRI also seems to break security. I have to block permissions of /dev/dri/ for any untrusted user, which means the user can't access it for 3D programs.

IPC will always be slower than system calls with no context switching.

Yeah, but you'll probably only notice it on an 1MHz computer. X also uses shared memory for IPC. Not everything has to go through sockets.

This is a possible reason why Microsoft Windows 98(tm) running on a 100mhz Pentium seems so much snappier for minor UI-interaction tasks (pulling down a menu) than a same-vintage Gnome on identical hardware.

You seem to be confused as to why your "X Windows" system is slow. I ran a 100MHz 486, and X was just as fast as win98. Try removing the Gnome crap, and you'll realize your mistake.

Re:X and networking

[Arandir]

This is a possible reason why Microsoft Windows 98(tm) running on a 100mhz Pentium seems so much snappier for minor UI-interaction tasks (pulling down a menu) than a same-vintage Gnome on identical hardware.

I'm running KDE on a P4 1.4Ghz machine. My boss runs Win2k on a P4 1.5Ghz machine. I'm assuming that KDE performance is roughly comparable to Gnome performance.

Anyway, my boss comes by and asks for some information. I bring it up by opening a Konqueror file manager window to an NFS mount, then opening the file in OpenOffice. He thanked me, then remarked how much snappier my desktop was than his. Huh? That was NFS plus OpenOffice, in case you didn't notice. Everyone on Slashdot tells me that X/KDE is slower than M$/Windows. They tell me so often that I was starting to believe it.

So I started paying more attention to the speed issue between KDE and Win2k. I've come to two conclusions. One is that the X11 process doesn't have a high priority by default. The other is that KDE doesn't have application resources (icons) embedded into the executable. I only notice "sluggishness" when I'm doing CPU or filesystem intensive stuff in the background, like a compile. Funny thing, I notice an even worse sluggishness under the same conditions in Win2k.

I've also noticed that Win2k doesn't do nearly a half the things that KDE does. In terms of just the graphics, all Windows does is draw some primitives on the screen. For a draw versus draw comparison, Win2k is going to beat X11/Qt every day of the week. But for real work, KDE beats Win2k hands down. I click on an mp3 file in Konqueror and kaboodle opens up almost immediately. The same thing under Win2k takes about three to five seconds for an embedded MediaPlayer to appear in the explorer sidebar. Running fifty different applications under KDE imposes no performance hit. But the same under Win2k makes a significant hit. Copying five thousand files from one directory to another (on the same partition) is almost instantaneous under KDE. Under Windows this can be almost painful to watch. This is really the filesystem (UFS2+S versus NTFS), but the user isn't going to care.

Why do people think that Windows is faster than KDE/Gnome? Because they've been told so hundreds of times. For minor UI interactions, they're right. But for the complete GUI as a whole, they're wrong.

Re:X and networking

[be-fan]

As someone who learned this painfully many years ago , you do need the networking stack compiled in. UNIX domain sockets depend on them.

Re:X and networking

[Minna Kirai]

AFAIK, Unix sockets are the fastest form of IPC.

On Linux, Doors IPC can be faster than Unix sockets (depending on how you benchmark). Sometimes even just pipes can be faster.

Unix sockets are NOT the same as for example accessing a local drive through an NFS mount on the local server. That does indeed go through networking to the 127.0.0.1 address

In that case, the majority of the slowdown comes not from the TCP/IP stack, but from overhead introduced by the nfs client and server processes (as they perform mappings and safety checks that are pointless for local files)

I have personally experienced applications (RealAudio player) on Microsoft Windows that load files more rapidly from HTTP to 127.0.0.1 than by disk access themselves. (This is attributed to poor application design)

Re:X and networking

[Minna Kirai]

But the IPC overhead consumes less than 1/100th of 1 percent of the time it takes to draw a window or widget when running locally.

It's not the overhead of IPC that makes a difference when you're reaching for extreme speeds- it's the fact that there's another process involved at all. If the data magically transferred between processes instantly (as shared memory does, and Unix sockets virtually do), the user still won't get a response until the OS gives the other process a timeslice.

The history of the WINE project shows many examples of this effect (here's an old one). They emulate Microsoft Windows(tm) features using two processes: wine (for the application itself) and wineserver (for the Windows(tm) OS features). They use very fast IPC between those processes- but the mere fact that wineserver is a separate process at all means they aren't able to approach the speed of executing in the real Windows(tm) environment, where system calls happen inside the same process.

(Naturally, X11 toolkits make many fewer calls needing server roundtrip than a Windows(tm) application does, as they weren't built under the assumption that those things are free. The example of WINE is just to illustrate that context-switch can be an appreciable overhead, regardless of IPC speed)

Back in the 100MHz Pentium days, I was running FVWM, which was very quick and snappy even on the machines of the day.

I have tried Microsoft Windows 95(tm) and fvwm95 on the same 100mhz Pentium computer with a 16 meg ATI Mach64 card. Opening a popup menu on the Microsoft product took an imperceptible time. The menu produced by clicking the desktop background in fvwm, however, produced a delay that was easily detectable to a human operator (which means it was at least 40 milliseconds)

Let's say gtk+ is ported to X as a module, and the gtk+ libraries are modified to look for this.

After such a drastic change, the entire character of the X11 display system would've been altered. Yes, X11 allows arbitrary extensions to be created (and negotiated between client and server, with the possibility of fallbacks). But just because a system is extensible, it doesn't mean speculation about far-out possible additions is at all relevant to the question of how the system works today.

You bash it.

Re-read my post, and you'll see that "bash" isn't nearly applicable.

I run X11 for hours each day, for work, web-browsing, DVDs (a crime), and even high-speed gaming. But I'm unable to evangelize it to my friends, because it feels to them as if there Mhz dropped 35% when running Xfree86.

Re:X and networking

[Minna Kirai]

Anyway, my boss comes by and asks for some information. I bring it up by opening a Konqueror file manager window to an NFS mount, then opening the file in OpenOffice. He thanked me, then remarked how much snappier my desktop was than his. Huh? That was NFS plus OpenOffice, in case you didn't notice. Everyone on Slashdot tells me that X/KDE is slower than M$/Windows. They tell me so often that I was starting to believe it.

That's really amazing. The complete opposite of my experience.

I have an AMD Athlon XP 1700 with 768 meg ram and a 64 meg Nvdia Geforce2 card at 1280x1204. OpenOffice is quite simply the most painfully slow applcation I've run.

Suppose I call up a spreadsheet in OpenOffice, maximize it so that 30X60 cells of numbers are displayed, and then switch to an alternate desktop. When I switch back, it takes 25 seconds to redraw the spreadsheet. I can watch each and every row appear individually.

This software was installed from a CD sold by Red Hat. Possibly they picked a bad version, or made configuration mistakes- possibly...

Other programs with similar graphics needs, like Kspread, and Gnumeric, are completely fine by comparison. At least, their redraw delays are too small to quantify with a wristwatch!

One is that the X11 process doesn't have a high priority by default.

To check this, just run "top" and check the "NI" value for XFree86. The Linux distributions that I've seen correctly give XFree86 a -10 priority, comfortably superior to user applications (which are typically 0 or higher).

Re:X and networking

[Arandir]

OpenOffice is slow, but not THAT slow. I suspect that you have a bad build or something.

Anyway, I suspect it was "fast enough" in my story, because I already had an instance running. But it's still slower than MSOffice, which is why I was surprised my boss thought my desktop was snappier.

I suspect that his impression came not from the speed of any individual action, but from the overall workflow.

Re:X and networking

[Anonymous Coward]

How fast do you really need things to draw? Well, yes, you want games to go fast which is why there are things like DRI. Images have their own set of shared memory extensions. For everything else, it hardly matters.

Re:X and networking

[spitzak]

You do not know what you are talking about. Windows does not use "direct rendering" either. It would be WAY too slow and would make it impossible to use hardware acceleration.

If this was a good idea we should also be writing files to disk by memory-mapping the disk into the application.

The problem with X is bad Xlib design and their paranoid refusal to jettison parts of it because it might break some obscure program. Oddly enough X does not dictate the communication protocol, since you call XOpenDisplay() and it can do whatever it wants, so they were able to improve this to use the best mechanisms available.

Re:X and networking

[be-fan]

Hmm, let's do a little survey:

BeOS --- Known for being blazingly fast, if anything. It was pretty much a microkernel for god's sake. Used IPC for everything, including sending data to the app_server (the equivilent of X in its architecture).

Windows --- All the NT kernel-based OSs use an IPC mechanism called LPC to communicate with the Win32 server and the GDI.

OS X --- Not known for having a fast GUI, but the fact that it runs the GUI in a server (lightweight window process in OSX-speak) isn't the reason.

The big thing is that IPC isn't that much of a performance hit. Graphics are easily batchable, so sending a whole bunch of drawing commands doesn't hurt anything. And you know what? You're going to be batching them anyway, since sending individual commands to the graphics card over the AGP bus is not exactly the way to get optimal performance. Now, there *are* some defficiencies in all existing architectures. The ideal method, for current hardware, is what is used by OpenGL ICD's on Linux and Windows. The actual graphics library is a hardware-specific module dynamically loaded into each application. The application calls the library to do drawing commands, and the library creates a hardware-digestible command buffer right in memory. Periodically, this buffer is DMA'ed to the hardware. Now in all current systems, there is an extra step --- the graphics server is the one that creates the command buffer, so you have one extra step converting a high-level window system command buffer to a low-level graphic's driver command buffer. To tell the truth, for 2D work, this really doesn't matter much. The *core* X protocol (no shared memory or anything) is fast enough on my machine to do x11perf -putimage500 at 80fps. That means copying about 80MB of images to the screen every second. Let's just say that no desktop application has graphics complex enough to need this kind of bandwidth. The bottleneck is clearly somewhere else.

Re:X and networking

[nathanh]

This is a possible reason why Microsoft Windows 98(tm) running on a 100mhz Pentium seems so much snappier for minor UI-interaction tasks (pulling down a menu) than a same-vintage Gnome on identical hardware.

Perhaps, but my current desktop is a Tektronix XP400 which has a 33Mhz CPU and 16MB RAM running over 10Mbps Ethernet. It is just the X server and it is perfectly acceptable for running GNOME. That's because GNOME itself runs on a Celeron-II 900 with 512MB RAM and high-speed RAID arrays in the other room.

X isn't bloated, GNOME is. The X requirements for GNOME are satisfied by my 10 year old X-terminal with less RAM than a modern video card. XFree86 isn't consuming all your RAM and CPU. My Tektronix proves this to me. Profiling can prove it to you. Though you may need some programming experience to profile XFree86 and GNOME (not trivial).

Now, that said, I don't think GNOME is all that bloated. It's certainly on par with XP for RAM and CPU requirements (or at least it is in the same ballpark). I think by next year with Moore's Law in effect this is going to be one of those irrelevant arguments.

Re:X and networking

[demon]

Domain sockets are _not_ slow. They're in fact way, way faster than using TCP sockets. This is in no small part because the overhead of setting up and tearing down TCP sockets is avoided, plus pushing data into and pulling it out of the networking stack for stuff that's not going to the network anyway.

If you're going to talk like you know something about the subject, it'd be nice if you actually had some experience first.

Re:X and networking

[demon]

DRI also seems to break security. I have to block permissions of /dev/dri/ for any untrusted user, which means the user can't access it for 3D programs.

Well, if you block access to those devices, that is what will happen. You can setup a group of users, and control the owning group and mode of the /dev/dri/* devices, through XF86Config, which could help security some though...

Re:X and networking

[Minna Kirai]

It is just the X server and it is perfectly acceptable for running GNOME.

Unless you've also got much newer graphics card, I doubt that many people would enjoy the resolution you must be at.

XFree86 isn't consuming all your RAM and CPU.

I never claimed anything like that. A program can be placing a light load on system resources, and yet take excessive time to respond to user input. (It's analogous to bandwidth versus latency)

In my experience of the response time to draw a pulldown menu in various toolkits, from fastest to slowest they are

• XUL
• MS Windows
• Qt (with a minimalist theme)
• Motif
• GTK

The fact that Mozilla's XUL was quickest shows that X11 isn't hopeless- but it suggests that the effort to make it speedy is more than most toolkit (or application?) authors are willing to go through.

Though you may need some programming experience to profile XFree86 and GNOME (not trivial).

I do have a few decades of C/C++ experience on my resume... however, sorting through the CORBA-interlocking GNOME processes to profile it would be very time consuming. KDE's much more attractive anyway (at least it supplies a dialog box to select a filename).

Re:X and networking

[moncyb]

Well, I changed the permissions of /dev/dri/ as well as put the mode and group lines in XF86Config. I forgot about the last part when I wrote the post, and I suppose I wasn't clear, but that is what I meant by "block permissions." I made a special group for dri, the framebuffer, sound, and such devices.

My point was the dri device seems to give somewhat raw access to hardware, and therefore is a potential security exploit. Yet the running program needs permission to access the device, otherwise it won't be able to use accelerated rendering.

This is a problem if the user account is using a network connected program which may be attacked (such as Mozilla), then the attacker may execute arbitrary code which accesses the DRI device and disrupts the entire system...or might theoretically even get root. From what I've read on DRI, it sounds like these problems could happen. But even worse, some programs (such as Unreal Tournament) need both network access and 3D acceleration leading to a potential direct exploit.

For sound, a sgid executable solution should work fine. The worst an attacker can do is play farting sounds through the speaker. Manipulating /dev/dsp won't stop people from using the computer--in fact, if the device is already taken, they can't do anything with it. /dev/dsp can't lock up the system--assuming the drivers are stable. An attacker can't get root. DRI is another story.

I suppose it seems silly to harden security even for a home systems with UT, but I'm sure some companies use 3D networked programs too. I'd like both 3d acceleration and security. Maybe I'm just searching for a pipe dream.

Re:X and networking

[nathanh]

Unless you've also got much newer graphics card, I doubt that many people would enjoy the resolution you must be at.

It runs at 1280x1024 in 24bpp. As I said, this is a Tektronix XP400, a semi-professional X-terminal. It isn't a 486 and an EGA card running XFree86.

However my intention wasn't to discuss the age of the terminal. I wanted to demonstrate that a normal GNOME desktop doesn't require considerable resources from the X server. 33Mhz CPU and 16MB RAM suffices. If your GNOME desktop is slow on a P100 then that is the fault of GNOME, not of X.

I never claimed anything like that.

Well, to be blunt, it's not at all obvious what you did claim. You compared Windows 98 and GNOME running on a Pentium 100. If you weren't talking about CPU requirements then why mention the CPU at all?

Re:X and networking

[Minna Kirai]

I suspect that you have a bad build or something.

Maybe. But since my build came out of a shrinkwrapped box of what is probably the most popular Linux distribution, this could explain where all those complaints of OpenOffice's slowness come from.

*BSD support

[Anonymous Coward]

This will never replace X11 because it has support only for Linux. What about all the other unices out there?

Great Looking Website Templates

Re:*BSD support

[usotsuki]

I thought FreeBSD at least was binary-compatible with Linux. And isn't Solaris able to emulate Linux as well? :\

-uso.
(-1 Redundant, so go ahead and mod me down)

Re:*BSD support

[FooBarWidget]

Binary compatible != kernel module compatible.
A big part of DirectFB is implemented in kernel space.

Network transparency *already* is a "plug in"

[spitzak]

Yet more morons are posting this fallacy.

Think hard. Imagine how network transparency would be "added on" to an API that is designed to not be network transparent, for instance one that uses shared memory to read/write to the screen pixels.

Answer: it is not possible. Network transparency requires design considerations in the API. Fortunately these requirements are exactly the same as are needed for all security and stability reasons so that crashing programs or hostile programs cannot take down the window system.

X already bypasses network code when the system is local. This is the only way to make "network transparency" a "plugin", and it is already being done.

Why is X slow? It is because of the horrid design of the Xlib api so that lots of graphics are impossible without huge amounts of communication, and because of huge numbers of synchronous value-returning calls (a mistake done, interestingly enough, because the designers were using local servers with low latency, thinking about the network would have prevented this), and because of the seperate window manager that makes synchronous update impossible no matter how fast your hardware or communication is.

Re:Network transparency *already* is a "plug in"

[I_redwolf]

It's not even worth wasting time.. 75% of Slashdot is filled with people who can't understand the conceptual design of the stuff they speak about. So basically, they don't even understand what you're saying. They like to think abstractly about problems which they know nothing about, hence, the above. As for the the "X is so bloated" comments that never seem to die, they usually come from people like the previously mentioned. Sadly they don't realize that it's akin to the "BSD is finally dead" type of comment.

Re:Network transparency *already* is a "plug in"

[Minna Kirai]

This is the only way to make "network transparency" a "plugin"

Technically, "screen-scraper" systems like VNC also make transparency a plugin (as it's a feature that was considered by neither the designers of the GUI system, or individual applicatiosn).

But of course, they pay a high price in lowered responsiveness.

Re:Naive Question-Conspiracy theory #1428

[Anonymous Coward]

The more important question is why are so many people with so little actual knowledge, all calling for the same things? And even better if they all get what they ask for, and it doesn't solve their percieved problem, then what boogeyman do they blame next, thereby sending the community on another fools errand?

Big hint to everyone.
1-First make certain you actually have a problem. Lack of knowledge can be a handicap at this point.
2-Second make certain that you have a full understanding of the problem. Lack of knowledge can be a handicap at this point.
3-Profit!! No now you can actually solve the problem safe in the knowledge that you identified the correct one, and know exactly what's good and what's broken.

Poor little kitty-cat.

[Anonymous Coward]

I know it and you know it, but it won't stop the morons who think that X uses networking every-fucking-where, including the local host. Schmucks.

3dwho?

[Anonymous Coward]

And supporting open source served them well!

Someone already 0wned the one on the right.

[Anonymous Coward]

Look at that big white stain on her trousers.

Some guy musta walked by and...boing...wank...zoom!

Re:Now all we need is a better OS-Abbra, Kaddabbra

[Anonymous Coward]

"Somehow BeOS makes life seem so much easier. Just drag and drop. Things just work."

Why is it, every time I hear this? I expect the speaker to believe in magic?

There's nothing mysterious about what's happening. Someone else has done all the work for you.
If Linux, like Windows came with the drivers on a CD, would that be mysterious? Would it "somehow (shrug) just work"?

Big Hint:
1-A lot of manufacturers aren't supporting the community. Know what that means don't you?
2-You're exposed to the development model. While in a closed-source OS (BeOS), the process is hidden from you. For all you know the (former) BeOS developers could have been wrangling with the same issues as you, but since the majority are never exposed to that. They believe that something mysterious and magical is happening when they go to use their computers.

A solution

[jbolden]

I think the hardware manufacturers worry too much about information leakage due to drivers. Their worry being real however I think a good solution would be closed source drivers for say 3-5 years after a card is released followed by the release of all specs + driver source. This ensures that older technology can be supported on all systems and for many years to come while at the same time protecting the cutting edge stuff. I'd hate to have Linux have the same problems as windows versions with binary only drivers.

Re:Now all we need is a better OS-Abbra, Kaddabbra

[91degrees]

A lot of manufacturers aren't supporting the community. Know what that means don't you?

Which community?

You're exposed to the development model. While in a closed-source OS (BeOS), the process is hidden from you. For all you know the (former) BeOS developers could have been wrangling with the same issues as you, but since the majority are never exposed to that. They believe that something mysterious and magical is happening when they go to use their computers.

I don't give a damn. As long as it works.

it depends

[Anonymous Coward]

IT DEPENDS

IT DEPENDS

IT DEPENDS

Last I checked, if you set our server to unix:0 it didn't use networking. But if you set it to hostname:0 it did.

And besides, INET sockets aren't all that much slower than UNIX sockets. Both are incredibly slow next to no IPC (shared memory).

Some Xservers I thought used shared memory for large objects also. But the commands all go through local IPC for queuing and snychronization anyway.

If you look at Windows, they got an enormous speed boost by making as many APIs as possible run right in the user memory space and making the ones that couldn't do that run in the kernel space.

In other words, Windows has speed thing up to a level where they are going to direct code calls without so much as a context switch. That's where blinding speed comes from. And you get excited that X can be made to not use local return IP sockets?

Re:it depends

[FooBarWidget]

"And besides, INET sockets aren't all that much slower than UNIX sockets. Both are incredibly slow next to no IPC (shared memory)."

This is not true.
First, shared memory *is* a form is IPC. If it isn't IPC it wouldn't be called "shared".
Second, on Linux, Unix Domain Sockets are just as fast as shared memory. There has been an attempt to make XFree86 communicate entirely using shared memory. But it turned out that Linux's Unix Domain Socket implementation is just too efficient and that there is almost no performance gain.

"Some Xservers I thought used shared memory for large objects also."

Like XFree86...

"If you look at Windows, they got an enormous speed boost by making as many APIs as possible run right in the user memory space and making the ones that couldn't do that run in the kernel space."

See my other posts. I did a benchmark. On my machine, Windows is NOT faster than XFree86 when it comes to pure frames per second! My benchmark says they're both just as fast.
The main bottleneck is and remains to be drivers. The XFree86 driver for ATI Rage 128 is good, so I get the same performance as in Windows.

Re:it depends

[be-fan]

I second that. I have also done benchmarks. X is comparable to DirectDraw in terms of speed in blitting, and a good deal faster in primitive drawing (since DirectDraw doesn't accelerate that :). Now that finals are over, maybe it's time to properly write up some of these and post them.

Correction on supported hardware

[SlashdotTroll]

DRI and DirectFB and DirectFBGL are three COMPLETLY DIFFERENT BEASTS

DRI is the 3D driver that is working with libGL.so
DirectFB is the 2D layer.
DirectFBGL is a concoction of DirectFB for openGL interface; this simply points at the openGL service.

In no way does having a peice of hardware not supported by DirectFB mean you are without hardware-accelerated 3d graphics. Remember, people, each package has a purpose. If you don't have a supported 2D framebuffer driver, yet your hardware has support for VESA, then DirectFB will work just fine and slower on your hardware by using its VESA drivers. If you have a hardware supported by DRI, yet it doesn't have support for 2D framebuffer, you are not stuck because you can use DirectFB's VESA drivers and still have hardware-accelerated openGL (via DRI) that is limited by the performance of your hardware's VESA support.

If anyone wants to try an alternative Framebuffer + DRI driver, independent from DirectFB, run over to http://fbdri.sourceforge.net; only Radeon users need apply. FBDRI supports Radeon's 2D framebuffer AND makes use of Radeon's DRI support, with windowed-rendering; whilst DirectFB can only support VESA on the Radeon.

C'mon, moderators, please redeem the great SlashdotTroll with some positive karma. ;D

Re:A solution-2 forward, 3 back.

[Anonymous Coward]

"I'd hate to have Linux have the same problems as windows versions with binary only drivers."[1]

Hehe. The problem didn't stop with a graphics card, but continues on with a chipset (nForce). The only thing keeping that aspect relatively clean is all the other (open) chipsets out there.

[1] Which simply reenforces my argument that most of the arguments for binary drivers are coming from former windows users. Think about it.

Re:NVIDIA not supported...Bogus argument.

[Anonymous Coward]

Yours would have been a fine rant, except...

1-Guess what the day jobs are of some of the X writers are? Uh..hu that's right. You make the same mistake as people do with the kernel people.

2-Your forgetting as one person mentioned in another post, that manufacturers are working against open source writers. When the team at your company of choice is similarly handicapped, then you can talk about superiority.

X memory usage

[Ender Ryan]

The memory usage you see in X is actually the memory of your video card + X, often allocated in different ways causing `top' to display a huge amount of memory incorrectly.

Re:X memory usage

[Paul Jakma]

indeed, i'm well aware of that, but you're missing something - X clients can ask the X server to create 'objects' usually pixmaps which persist for the lifetime of that X client connection. There are bad apps out there that forget to free objects, and just keep creating new ones, causing the X RAM usage to balloon. The app needs fixing.

Shutting down the X client will cause the X server to free any objects it had. However, you probably will not see your RAM usage go down - as glibc /never/ shrinks the heap (difficult thing to do). The solution perhaps might be for the X server to use private mapped memory for some allocations.

Note that because glibc never shrinks the heap that RAM usage is a /maximum/. If you see X with 80MB of data, it just means that at some point in the lifetime of the process glibc had to allocate 80MB of heap to fulfill requirements. A lot of that heap though might well be marked "free" (ie allocated by OS, but marked free by glibc and available for use by malloc()) - so future malloc requests by X may very well be allocated from the existing heap without any need for glibc to increase amount of RAM used.

This is a general problem with glibc, or rather heap based memory management. You could add heap defragmentation and shrinking to glibc, but that might well cause long pauses in applications while glibc defrags - which application would have little control over. Heaps will become fragmented, they are hard to shrink without paying a cost. (though glibc will switch to private mappings if requests are beyond a certain size, and private mappings are easily freed once the app calls free()).

Moron

[Anonymous Coward]

Anyone who says they're trying to "prevent uninformed comments about X" and then goes on to say X WINDOWS three times in a row (bold face theirs) should NOT get modded up. It's X, or a windowing system called X, not X Windows.

Thank you.

another myth

[Ender Ryan]

another myth that poeple need cleared up every fucking time is thus:

THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT

THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT

THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT

Got it? Good! Stop the nonsense regarding X! Stop trying to throw out the baby with the bathwater.

Network transparency is used by a lot of people. Network transparency does not slow down X locally. Network transparency does not add considerable bloat.

Blah blah blah. Stop the insanity!

Re:another myth

[nathanh]

Network transparency does not slow down X locally.

Yes, it does. Marshalling and unmarshalling of the X11 request still occurs even with UNIX domain sockets as the transport. That's an obvious and easily measurable performance hit.

It's not a big hit. It's certainly not enough to warrant the unbridled (and uninformed) hatred of X11. There are other problems to consider but they're not things I strongly understand myself.

quake disagrees

[DreadSpoon]

Heh. Of course, there's the whole issue where the high-end open source drivers don't perform nearly as well as the closed sourced ones. ;-)

This is isn't a problem with open-source, simply the fact that the closed source drivers are better, currently.

Granted, a better kernel interface for this kind of stuff would elminate the whole problem; it shouldn't need porting of a _driver_ between different user-space systems. :(

(Sure I'll receive flak for this opinion on the AP list now. ;-)

Personal experience

[Anonymous Coward]

Once again I'm glad to have a Matrox card. I had to set up a computer for molecular visualization once (requiring an OpenGL video card), and the NVIDIA cards just weren't working on the cheap OEM hardware. ATIs were pretty good, but the only thing that worked the first time, without a crash, was the Matrox. It's a little bit on the expensive side, but I can run nearly any OpenGL app with the knowledge that it's not going to crash or fill the screen with garbage.

So now that we have transparent windows and shadowed mouse cursors, are we satisfied that all the crucial elements of a desktop operating system are there? :)

Communicating Semaphores

[Ungrounded Lightning]

Signals and semaphores can only send a few bits of meaningful info.

Qualify that to "unix/linux semaphores" and you may be right. But not in general.

There is a variant of semaphores called "communicating semaphores" that explicitly manages queues - of messages waiting for processes, or processes waiting for messages. They can be impelmented to handle messages of arbitrary size, and yet still perform all the other primitive operations needed in an OS kernel.

With a single mechanism handling interprocess communication, interrupt handler/driver communication, producer/consumer data streaming, mutual exclusion, signaling, memory and other resource allocation and arbitration, you can build a real-time OS kernel with actor-based applications in a HYSTERICALLY tiny amount of code.

slight correction

[Paul Jakma]

X maps the entire video ram. So if you have an 8MB card, then 8MB of X's supposed memory usage is actually mapped video ram. X can use the remaining 5 MB (eg 3MB used for display from your example) of video ram to store pixmaps, etc.. (google for XAA - X acceleration architecture iirc). If you have a 32MB card, then X will be at least 32MB in size, if you have a super duper 128MB card, X will be at least 128MB in size - just because of the VRAM mapping.

Re:slight correction

[be-fan]

That's just the tip of the iceburg. Some drivers map the memory more than once. With my 64MB GeForce 4MX, X has a VM footprint of ~300MB. The actual memory footprint, though, is only about 30MB. These figures should be rather accurate, because I think they fixed some memory reporting issues in 2.5 (which I'm running).

Re:slight correction

[Arandir]

I've got a 32Meg video card, and top tells me that X is 38772K. So it's really ony 5.9Megs. Same as other people are saying...

not completely true for a long time...

[MenTaLguY]

Actually, modern glibc uses mmap() instead of sbrk() to allocate memory in many cases. mmap()ed segments get returned to the system at munmap() time.

Re:not completely true for a long time...

[Paul Jakma]

Yes, indeed, i think i referred to that in the last paragraph.

Note though that the threshold for glibc using mmap() is 128k, most allocations wont be anywhere near that large and will be allocated from heap. mmap() allocations have a performance overhead.

Re:not completely true for a long time...

[be-fan]

Actually, mmap() is also used to allocate the memory to back the heap. So if a given mmap()'ed chunk of the heap is empty, that memory can just be returned to the OS.

Re:not completely true for a long time...

[Paul Jakma]

that's what we're discussing :). heap backed by mmap(): that is only true if the allocations are above a certain size according to the glibc info pages.

What an incredible joke

[Overly Critical Guy]

You misread something as having "FBI" in it.

"DirectFeds." You're right. That is hilarious and warranted posting about it.

Re:NVIDIA not supported...Bogus argument.

[be-fan]

The main problem is that 3D is a whole different kettle of fish than 2D. The 'nv' 2D driver is 80kb compiled. The NVIDIA 3D driver is about 6MB of code, split up over a 400K X driver, a 5MB OpenGL library (libGL is vendor specific in the ICD architecture) and a 400K GLX driver. It's a whole lot more code, it's very hardware-specific, and it's a rather specialized field. The field of kernels is something else entirely. Kernel coding is a well understood field of computer science, and there are lots of OSS kernel developers who have a lot of experience in academia and the commercial industry. There is a reason why none of the DRI drivers are particularly competitive with the native Windows versions, while NVIDIA's Linux driver is pretty much equal between the two.

Re:NVIDIA not supported...Bogus argument.

[Anonymous Coward]

"There is a reason why none of the DRI drivers are particularly competitive with the native Windows versions, while NVIDIA's Linux driver is pretty much equal between the two."

Yes, and I will tell you the same thing I told him. Some of the people who practice video driver writing are some of the same people who do it professionally. Now why do you keep ignoring that point?

"There is a reason why none of the DRI drivers are particularly competitive with the native Windows versions, while NVIDIA's Linux driver is pretty much equal between the two."

And the point you ignored (just like last time) is that the people who are writing the drivers are working under an artificial barrier that their counterparts are not. Have you ever reverse engineered a large binary before? How about hardware?

Re: interactivity updates

[Anonymous Coward]

You can get the ck-patches against 2.4.20 if you want the interactivity updates for a stable kernel.

Are there plans for dual deisplays?

[Unregistered]

Are there plans to bring dual displays to DirectFB. I use it on all my systems except my main one since it's got dual displays.

Mod this up folks...

[waferhead]

I would gladly give you a +5 informative" if it was in my power.. Not today.

Re:NVIDIA not supported...Bogus argument.

[be-fan]

Yes, some of the people writing video drivers are some of the same people doing it professionally. I just learned on xwin.org today that one of those people is Mark J. who works on XAA (among other things) and also works at NVIDIA. However, I'll assert that the number of experienced 3D driver writers working on XFree are rather small compared to the number of dedicated driver guys at ATI and NVIDIA.

Also, AFAIK, none of the DRI drivers are reverse engineered. The specs of the ATI, Matrox, 3dfx, and i8xx chips are publically available. Heck, I've read the Matrox and 3Dfx docs myself.

Information leakage is probably a flood

[leonbrooks]

I think the hardware manufacturers worry too much about information leakage due to drivers.

I look at it this way: who has the resources and expertise to best disassemble, interpret and live-hardware-debug your video card? Is it your competitors or the OSS developer-in-the-street? How many OSS freaks do you know carry digital scopes and logic analysers able to resolve and capture into the gigahertz range?

So by hiding the driver source and card details they're taking away advantages from their customers, not their competitors.

Your plan is a vast improvement on what we have now, but really the paranoid lawyers controlling the chipmakers need a heavy dose of reality.

Exposing details of their chips (especially for something like VIA's Savage4-derived horrors but this applies to ATI and nVidia just as well) isn't going to help their competitors very much at all, but it will help their customers lots, and a helped customer is a happy, loyal customer.

Are you listening, nVidia?

Re:Information leakage is probably a flood

[jbolden]

True but you ain't gonna be able to hide an operation where you have dozens of people reverse engineering the card at the hardware level. You might be able to have a few analysts read the source of the comp's driver and write a report.

Re:Information leakage is probably a flood

[leonbrooks]

True but you ain't gonna be able to hide an operation where you have dozens of people reverse engineering the card at the hardware level.

They'd be more interested in rev-enging the chip, for starters, and in Australia, at least, reverse-engineering is legally protected (producing and/or selling hardware using a proprietary idea is not). All they'd need to do would be contract the actual rev-eng out and clean-room the data they got back enough that showing it to their engineers wouldn't put them at risk of patent violation.

So the short answer is: you shouldn't need to hide anything; and the longer answer is: you have the expensive machinery anyway (to see what's really going on with your own chips), and reason to be using it - so slipping a competitor's chip into the analysis stream would be dead easy to hide. Only one or two people need ever know.

Done.

[leonbrooks]

So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular?

At what level? SDL? GGI? GTK? Qt? wxWindows? KPart? Six of one, half a dozen of the other, perhaps you're spoilt for choice?

Answer to Naive Question

[tyrione]

QUARTZ FOR MAC OS X

http://developer.apple.com/techpubs/macosx/CoreT ec hnologies/graphics/Quartz2D/quartz2d.html

Re:NVIDIA not supported...Bogus argument.

[Anonymous Coward]

" Yes, some of the people writing video drivers are some of the same people doing it professionally. "

He finally admits it. I swear it's like pulling teeth with you some days.

"However, I'll assert that the number of experienced 3D driver writers working on XFree are rather small compared to the number of dedicated driver guys at ATI and NVIDIA."

Two things. One neither one of us knows exactly how many people either have on their driver teams, so quanitative corparisons are going to be a bit meaningless. Two the XFree team has a bigger target than the focused team of either Nvidia or ATI. I rather doubt that "Team Nvidia" or "Team ATI" would do much better if they had to support as many cards as the XFree team does, at the pace that they do.

"Also, AFAIK, none of the DRI drivers are reverse engineered. The specs of the ATI, Matrox, 3dfx, and i8xx chips are publically available. Heck, I've read the Matrox and 3Dfx docs myself."

That's true in the majority, but as another poster pointed out, a lot of the hard work that went into opening up is being undermined by people who simply accept a binary status quo, and take a whole blaise attitude to the situation.

Even for those that are open, they're not so open that there isn't an aspect that doesn't have to be figured out the hard way (i.e TV out, Macrovision bypass fears).

AF_UNIX sockets are JUST LIKE AF_INET sockets!!

[aphor]

AF_UNIX sockets work just like AF_INET sockets once you bind(2) that file handle! That's not "nothing to do"! That's PLENTY to do with AF_INET! What I'm talking about is a facility meaning it makes something easier. It's not just a bonus, it's the whole point! If you do dumb things like program AF_UNIX sockets without thinking about network transparency, some day you will be cursed by the guy who has to hack in all the missing network-byte-order stuff, etc..in order to get it to work over future-speed networks that are faster than the memory bus on your computer.

One thing you have to tackle when you get into the Unix world is the concept that users and programmers are discrete sets. In Unix, the greater the union of those two sets, the better! If you're a programmer, you should "think user." If you're a user, you should "think programmer."

Oh, and BTW your spam (in the original Usenet sense of repetition)

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

does not contribute to the reasoning of your argument.

Information leakage is probably a flood-Peek a boo

[Anonymous Coward]

Bingo! Finally someone who gets what I've been saying for the past month. There's a little secret to the business world. Companies watch competitors, and no I'm not just talking what Wall Street puts out. This is why the whole "Got secrets?" argument falls apart. And no, one doesn't have to slip it into the stream. There are sublabs if you will that keep tabs. Hell there's entire companies that do this kind of work. The "/." crowd never ceases to amaze me with their ignorance (ugly it may sometimes be) about the underbelly of the world.

The ugly ignorance of SlashDotters

[leonbrooks]

The "/." crowd never ceases to amaze me with their ignorance (ugly it may sometimes be) about the underbelly of the world.

Live with this: /. is probably not very different from Joe Public. (-:

Re:NVIDIA not supported...Bogus argument.

[Anonymous Coward]

I thought ATI only released specs under NDA to DRI programmers.

Re:NVIDIA not supported...Bogus argument.

[be-fan]

Pardon me, but I don't think I was the original poster you were so mad at. I never denied there were professionals working on 3D.

"Impossible" network transparency

[Anonymous Coward]

What could stop one from writting an application that mediates between an API and a network protocol? Is NFS limited to those operating systems designed with "network transparent" filesystem APIs? If your beliefs on what is technically possible and what isn't are true, then how does OSX's remote GUI work? I'm "thinking hard" right now, but still can't figure out why your post needed anything other than the third paragraph. I guess I must be one of those "morons".

Re:"Impossible" network transparency

[spitzak]

If there is shared memory (which is actually the only plausable reason for getting rid of network-transparency) then unless you use hardware traps you cannot send the image over the network. Even with hardware traps the best you can do is something like VNC where it sends enormously larger amounts of data than necessary because it does not have the slightest idea what was done to update the display. Slight changes by adding calls like "I am done updating the screen now" would make the network work better, but as soon as you add such calls you are desiging a system for networked use.

As you said, any kind of interface where there are "calls" or any other trappable operation could be made network-transparent. The biggest problem is that for any reasonable speed the calls must be designed so that they either return no result, or the result can be calculated locally. If you do this then you are again designing for networked use.

My big complaint is with people who say "network transparency should be an option". This is a total nonsense position to take. The only logical positions are "network transparency will not be supported", or to design for network transparency. Any plausable design where network transparency is an "option" is exactly the same criteria as supporting network transparency, as small considerations in the design can make enormous benifits for the network performance while having no effect on local performance. And in fact this is exactly the way X is designed right now. Therefore anybody saying "make network transparency an option and X will be fast" is wrong, because X is already this way and it is slow.

DirectFB

[msh104]

Directfb is a great api. it can even be usefull because SDL supports it. so it should not be a to big problem to have a game SDL-only game like tuxracer ( if i recall right then ut2003 was SDL-only to) by SDL only i mean the program is not using any X-server api's. running a game directly from the console has the same big adventage as running a game on a "gaming console" ( ala gamecube ). the less progs like kde, gnome with lots and lots of processes running that might trigger a crash the better. console only gaming could definitly rule for the serious hardcore gamers.