Slashdot Mirror
XFree86 4.1.0 Reviewed
Patrick Mullen writes "The Duke of URL has just posted their review of XFree86 4.1.0. The review covers its new features, the fixes since 4.0.3, performance (2D and 3D) and even takes a look at what ground has been made in ATI, NVIDIA, 3dfx, and Matrox's drivers." Compares performance to windows where applicable and to X403. Looks like the speed gains are real. Hope it gets put into sid soon for us apt junkies.
for whatever reasons, the debian packages for installing 4.1.0 have paradoxical dependancies. The packages require certain other packages that if you attempt to install them, will break your system due to the very NON-failsafe method of *.deb's. Please keep this in mind, and use on the several utilities to back up your existing system. (Yes I know that is rather large and general). Specifically, back up 'ldconfig' and all the libc# related packages, or just the libs themselves. (libc6, glibc, (the ++ versions too), as well as all those that depend on these here) But also it would be wise to go through and run the download only command for every package, then run the command to print out the dependancies first, in order to allow you to properly back the rest up.
Now, for the bitching. The reason for this is not any of the code or libs. It is the deb packages. For some reason (probably overworked and understaffed) the maintainers are not acurately checking the packages. Many have complained about the 'Catch 22' type of situation that arises from attempting to install all of the needed libs and such for upgrading (or initially getting) to the new XFree86. (although this was mainly with 4.0.2,3 and 4) Please if you are a maintainer, remember the whole point to the packages. If they require such a long list of upgrades based on a very sub micro-minor version update, then redo it. Furthermore, allow for proper roll back and only overright ANY portion of the libs AFTER the new one is completely installed AND CONFIGURED!
Right now, it is not only easier but healthier (both to your system and mental health) to install binaries or compile. As for you coders, don't just include stuff because it is there and you think it is 'cool'. Otherwise, you force everyone to upgrade from 13.5.97.3.21 to 13.5.97.3.22 for no real reason.
You mysogenic bastard. So all "real" linux users are men? Those "silly little girls" wouldn't be able to figure out the Mighty Command Line? Yes, Be A Man, Taco! Do something that will create pain for yourself instead of waiting for the easy way!
Sexist shit.
I demand you eat my bait. Suck it down boy, and lick that hook clean.
Lately we've seen a new mature version of KDE (2.1), and new version of GNOME (1.4), a new kernel (2.4), and now Xfree86. With all this, I'm getting really temped to upgrade. The wise will wait for GCC 3.0 though. The new C++ ABI is going to break stuff everywhere, so a clean install will be recommended. It's getting very hard to wait though.
Maybe you should try debian? (joke, joke...)
--
Forget Napster. Why not really break the law?
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
--
Forget Napster. Why not really break the law?
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Just FYI. From the mailing list, I believe it could happen.
And it is the first GCC (maybe the first released compiler) to do so, so I'd say GCC 3.0 has a lot to do with it.
Someone mentioned on the dri-devel list that the modules that ship with XFree 4.1 are newer than any that ship with any kernel.
UT runs fine for me.
Once I got it working that is. DRI gave me a lot a grief but I finally got 3D working properly and can snipe in CTF-Face all day if I want. And sometimes do, although last-man-standing is my fave at the moment.
BP6 w/ 2x533 and a G400Max. I never need to create a dedicated login or stop any processes except the obvious ones like xine or oggenc.
Did the dedicated login back when I had a Cyrix166 trying to run CivCTP at 1280x1024.
Before you dismiss my answer, read this comment through.
Answer: Frame Buffer.
Why is that the answer?
The Linux kernel frame buffer currently will do not only standard graphic mapping, but will also do accelerated function on certain cards, for example, Matrox cards.
At my last check, not all accelerated functions were implimented, and there was a push for a _common_ set of kernel functions so that accelerated features for all video cards would work in a common fassion, which, for example, XFree would use. This is why XFree still works better with a card driver, rather than the fbdev driver.
And, if your not satisfied with XFree still, qt embed uses the linux fb, or, you could learn c and/or c++, and be able to form a better opinion on what needs to be done, and maybe even help out.
VK3TST
-- "People aren't stupid. Usually." -- jd
It may not be in Sid yet, but there are packages out there for Woody.
deb http://people.debian.org/%7Ebranden/ woody/i386/
deb-src http://people.debian.org/%7Ebranden/ woody/source/
My Slashdot account is old enough to drink...
Yes. When I first upgraded one of my machines to an S3 accelerated card, the non-accelerated ones seemed unbearably slow. However, even today, an opaque move of a large window can cause the machine to become less responsive. If the X server can help minimize this, so much the better.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
I don't think so. The length of a jiffy (the timer interrupt) in Linux is 10ms. However, the quantum is 50ms. Most processes are not preempted within the 10ms jiffy.
If there is no other process to run (with a higher priority) of course the kernel will let the current process run its full timeslice. However, any process that needs attention and has a higher priority than the current running one preempts it and gets to run (within 10-20ms). Scheduling quantum doesn't matter at this point. If you push up the HZ counter to 1000 (1ms timer interrupt) you can pretty much guarantee a soft-realtime process that needs attention every few ms to run correctly , assuming you make sure it has a higher priority than normal. You will notice that properly written apps do exactly this.
That's my point. QNX and BeOS both run in userspace, just like X, and run a good deal faster.
"run a good deal faster", and what runs a good deal faster? The BeOS UI is certainly much slower on my box these days, but I suspect that has something to do with the AMD-challenged optimizations in the Be kernel. Haven't tried QNX recently. Point is that with properly prioritized processes you can make Linux just as responsive as for example BeOS. The advantage BeOS has is that it does this automatically for you, it's a single user OS, with no security. (I'll take multi-user Linux over it anyday though!)
t they are not transparent to applications
What do you mean, not transparent?
Umm, the BeOS messaging system can shunt 90,000 messages per second around the system (on a PII 300). Nothing on UNIX is anywhere *near* that number. Even QNX can't do above 40K.
Where are you getting these numbers from? And what constitutes sending a message?
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
1) X runs on UNIX. Unicies are almost always server-oriented systems, and tend to have very short thread quantums. For example, the quantum on Linux 2.4 is 50ms (down from 100+ on 2.2).
/usr/src/linux/include/asm/param.h and setting the HZ define at 1000. Yes, the timeslice is mostly dependant on this single define. You will notice that for x86 it is at 100 by default. To get the timeslice you simple divide 1000ms by the HZ value. So for 2.2 and 2.4 you get 1000 / 100 = 10ms. I have a standard patch that's applied to all fresh kernels that put HZ at 1000 on my boxes. It's kind of ludicrous to have 10ms timeslices on a 1.4GHZ Thunderbird *g*. Oh, and if you need smaller timeslices, witout having to modify your kernel lookup the manpage of sched_setscheduler
...when GUIs like Photon (on QNX) implement all the features of X plus more in less than a meg, one has to fault elements of X's design
This is simply not true. Both your 2.2 and 2.4 numbers are dead wrong. Linux on x86 has always had a timeslice of 10ms. It has always been 1ms on 64-bit Linux platforms (Alpha). BTW, you can modify the timeslice very easily by editting
show much improved access times, even when the GUI is in a userspace server (as in BeOS or QNX)
X is in userpace.
2) It's badly designed
The design is about 20 years old, and still going strong. The developer didn't have the hindsight of what hardware would be developed over the years. Luckily enough they tought of X extensions. Oh wait, X extensions are bad right? Don't tell that to the Xv and RENDER extension that are taking full advantage of my cutting edge NVidia GPU!!
X uses the much more general (and much slower) UNIX domain sockets
Local sockets are really fast (and very low latency). For large transfers X uses shared memory anyway. And thanks to XAA the amount of communication is kept to a minimum.
Try TinyX. Your arguments, while true to some extend, are really not convincing enough to call X "badly designed". You are using outdated facts to draw conclusions. X is here to stay. Whining about it is not going to make it less useful. You could spend your time better by helping out Be and BeOS, be-fan. A 3ms timeslice doesn't do me any good if it doesn't boot on my box. Too bad the juicy parts are closed source no??!
Oh, I finally decided to put my BeBox in long term storage. Perhaps in 20 years it will fetch a nice price. I'm betting it'll bootup witout too much trouble, assuming I can still find a CMOS battery that fits.
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
Anyone have a summary of how easy it is to use this feature?
Get the more or less official debian sid packages here:
http://people.debian.org/~branden/woody/
xer.xes -- 4181
Sorry for off topic post, but does anyone know what's the deal with Debian releases these days? When do you think woody would be released?
Also, can anyone share their experience running woody? I'm currently using potato on my firewall. Is it safe to upgrade? How about using it on a workstation?
tia
___
___
If you think big enough, you'll never have to do it.
Are you accusing this bastard of resembling a Japanese soup, or do you mean "misogynistic?"
--
#19845
Yeah, but we may never get hardware OpenGL in BeOS.
- chrish
Quake3 does. Quake 3 runs GREAT on my linux box. In fact, it's pretty much the whole reason why I bought this box.
I figure I'll just wait until X 4.1.0 gets put into sid (unstable). Kinda funny how unstable doesn't mean unstable. :) The big packages like X always go through decent testing before hand. I think someone posted the pre-release packages above. Not 4.1.0 is gonna help my nvidia card out any. But I haven't really had a complaint about the 4.x tree of XFree86 yet.
And no, you obviously don't need such a beastly box as my main game machine to run quake3, my p3-600 v3 runs it respectably (samn distro setup). I'm really looking forward to seeing the XFree86 4.1.0 v3 improvements with this box. :) I currently have to turn off some of the bells and whistles, running it in 800x600 in 16 bit color with vertex lighting to get what I feel a playable frame rate out of it.
I'm kinda pick when it comes to frame rate though. But not nearly as bad as some people I know. :)
---
It's not, unfortunately - I've got the same problem with my Diamond Monster Fusion AGP (as does the reporter of the bug in DRI's sourceforge buglist, though he's got the PCI version). The Banshee Bug has been in the DRI since at least early April's CVS.
I'm hoping they get it fixed soon - I've been itching for XVideo support, which HAS been fixed (but I can't use because of the banshee bug corrupting everything...). The bug was assigned a while back now - my guess is it'll be fixed soon (the fix may be delayed because the DRI team is evidently busy moving to Mesa 3.5...)
Or, spend the 30$ and get a voodoo3...If I can manage to find a Voodoo3 AGP locally for only about $30, I may just do that...
---
Hacker Public Radio is our Friend
For what it's worth, this bug has been in DRI's sourceforge bug database for about a month and a half now (I went to report it myself a couple of weeks ago and found someone else already had, so I just added what little extra info I had about it to the discussion...)
Oh, and if you go to look it up, I'm not the one who reported it as "WTF ARE YOU GUYS THINKING?!?!", so no flames, please...the bug report can be found here.
---
Hacker Public Radio is our Friend
Moving certain critical _parts_ of XFree into the kernel might be a win, like the graphics drivers. After all, why the heck should a user space application like XFree be doing PCI management?
The X Window system is not a Linux-only application. For portability's sake alone, putting X components in the kernel is "A Bad Idea". Sure, there's os-specific code in X, but you shouldn't need a particular version of a kernel to run a particular version of X. Don't even get me started about DRI. ARGH!!!!
I agree with the rest of your post though... I personally think we need LESS stuff in the kernel. Anyone who wants to write device drivers should be made to chant over and over: "If it doesn't need to be put in the kernel, don't put it in the kernel!"
well, there was that time in between when I sold the cheap piece of junk s3 PCI card that came with my (then) new Pentium 133 to my dad who had just upgraded from a 386 to a p133 and hadn't yet recieved the matrox card I ordered... I was forced to use the ISA card form the old 386 and realized that it wasn't the 386 processor that was slowing me down back then after all...
I recently upgraded to 4.1.0, and now I get "snow" on my screen whenever I scroll. It goes away when I stop scrolling. 4.0.3 was fine. Does anyone else have this problem?
Why wait? Do it like the rest of the world! It's easy and fun! Like so:
> sh Xinstall.sh
Then you don't have to be at the mecry of package maintainers. You'll have control over your own system, and in no time you'll be livin' la vida Libertarian.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
In my experience XF86 v4.0.x does not like Voodoo cards. I've tried it with a Diamond Monster Fusion and a 3dfx Voodoo 4 and both had stability issues and leaked memory all over the place. It would crash when playing video, loading a large Star Office file, reading /. in threaded mode, etc. Not only that, but it was overwriting virtual console buffers: Corrupted character maps, inverted video when I hit Ctrl+Alt+F1. Touching the keyboard when in console mode also tended to crash X.
I finally gave up and bought a GeForce 2.
Maybe the 4.1 driver is better. Good luck!
Thanks for the tip. If I resurrerct that config for a spare box I'll add an exhaust fan.
I just installed 4.1 on my G400 (yes, yes... but it's close, and I'm curious if you had the same problem)...
I had never been able to enable antialiasing on both heads; the primary looked okay, but the second was screwed up. Now, with 4.1, both are "sort of there"... large rectangular blocks of text are simply missing, but if I highlight them in Konqueror, they reappear, and stay there when I remove the highlighting. A Control-A in each web page seems to fix it.
It's a shame - it's just so darn *pretty* to use these antialiased fonts, but I just can't get aa (or GL) to work if I'm using dual-heads (GL *does* work just fine if I drop it to using just a single head, but as soon as I reference that second head in XF86Config, GL dies).
Bah... I wish I had the time to scroll slowly through logfiles... Grrrr... I didn't have time to fix it then, and I won't have time now, dammit.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
*sigh* Tdfx is br0ken, I have to stay with 4.0.3 for OpenGL on FreeBSD.
There are a couple major problems with letting X do all the graphics driver management, instead of placing minimal graphics support in the kernel.
The first issue is functionality. There is no standard way to write a graphics program under Linux currently that doesn't have to have X under it. This is a big problem for me and other graphics happy programmers. It turns out that X11 has a terrible interface for high speed graphics. Yes, there are a couple drivers here and there that can use the FBDev, but thats not accelerated. I want FAST 2D alpha BLTS under Linux. And I dont want to have X in my way.
The other problem is stability. I dont care how good X is, it still crashes, and when it does it takes the rest of the system down with it. Sure, if you have another computer handy you can telnet in and fix the problem, but thats hardly something to expect your mom to do. The basic problem is that a kernel should manage resources. Thats its only job. And the video card is a pretty big resource for a desktop computer. The idea that the kernel has no way of returning a video card to a usable state when a program tanks and leavs you in graphics mode is just dumb.
Now, dont get me wrong. I dont want to see X11 linked into the kernel. Thats just as stupid as having no drivers in the kernel. It is totaly possible to write device drivers where most of the device specific code is in User Space. And only a small portion of the device driver runs in the kernel. Just enough to make it SAFE. This is the direction that the GGI is/was heading. I say was there because I dont know if they are still with us. Its a real shame, they were doing some awsome work. I know I probably lost points with a bunch of readers by mentioning the GGI, but please think about what I have said, you might find that it makes sense.
You are correct that FBDev consists of graphics drivers in the kernel. However, there is no accelerated interface to be found for FBDev. Its as slow as a snail, unless you happen to have a matrox card. When I say fast 2D alpha blts, I mean hardware assisted. Not software read/modify/write style blts. I don't think there are any interfaces in Linux that can do that (other than X in some cases). And your assertion that more card will be supported in the future might not be true. I would LOVE for that to be the case, but Linus really doesn't seem to like the idea, and as long as everyone views X as good enough, there wont be any pressure to add support.
:)
Your also right about the GGI. What I said was actualy about the KGI, which is "almost" a different project now. I use the GGI in about half my graphics code, the other half uses the SDL. I havn't picked a favorite yet though.
Thanks for the good response.
Ask Slashdot: Where can I find pictures of huge, gaping assholes?
http://cmdrtaco.net/rob.shtml
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Try using Java apps with a gui. But that's not what you meant, right?
----------------------------------------------
the pun is mightier than the sword
The 'paradoxical dependencies' is right on because in several instances, as an example: libstdc++#### depends on libc6####, yet libc6#### depends on libstdc++####
Not on my system. apt-cache showpkg reveals that libstdc++ is dependent on libc6, but the reverse is not true. I'm not entirely sure what that has to do with XFree, anyway, since AFAICT there aren't any dependencies between X and libstdc++. I'd love to show you the proof, but it's about 5100 lines long, and I don't think the lameness filter will let that pass.
Unless you have tried to upgrade the XFree86 >4 on your existing debian system and had none of these problems then fuck off.
What's ">4"? If you mean 4.1, then no, I haven't tried, but I am tracking unstable, which is currently at 4.0.3-4, and the last time I had a problem was, IIRC, during my initial move to 4.0, when there was a broken dependency deep in the system, though I can't remember if it was X-related (whoops, run-on sentence there). In any case, it was promptly fixed, though I'd worked around it by then, anyway. (Come to think of it, I may have been in worse shape then you, screwed libs and all, but I, having used Debian for a whole two weeks, managed to rebuld everything by stripping the system out and replacing everything by hand in one night.)
And yes, many others have had the same problems whether using the apt-get route, dselect, etc.
True, and usually they don't what the fsck they're doing, but have decided that since the package system won't conform to their declued view of the world that it must be "broken", and its their job inform everyone of this fact. Some of them are just trolls, too.
sorry for the 'hot' persuit. Thought you had problems running g450 at all / were thinking about bying one.
But, asking detailed questions makes giving insightful answers easier. Lets leave it at that...
nosig today
yes, the fact that you are clueless... if you want support (I'm looking at dualhead, dualrefreshrates, dual resolutions under 4.03 so there are drivers) go to www.matrox.com or especially:l /2 001/linux_powerdesk.cfm
http://www.matrox.com/mga/media_center/press_re
install a few files and run this powerdesk for linux and your xfree works like a charm. (ps, you have to cut and paste this link, you can't click).
nosig today
khttpd, like almost everything in the kernel, is a module. It's under 'experimental', and, as such, is not normally compiled, let alone loaded. Linus himself, undisputed king of "No! Too bloaty! Take those four instructions out of my kernel!", has said that it's good as a technology demonstrator and benchmark whore. So stop knocking khttpd! It's not a production webserver or anything like that!
And besides, having optional khttpd is *not* like having the GUI in-kernel with windows. *You* try unloading the GUI from your kernel32.dll.
-grendel drago
Laws do not persuade just because they threaten. --Seneca
Compile time, nothing! What about insmod and rmmod?
Any module *cannot* bloat the kernel. Unless you count higher make-modules time and longer tarball fetches.
-grendel drago
Laws do not persuade just because they threaten. --Seneca
/sbin/rmmod bloatydriver
There's your choice. Schmuck.
-grendel drago
Laws do not persuade just because they threaten. --Seneca
I currently run a SuSE 6.3 system with a 2.2.14 patched kernel (from standard 6.3 2.2.13 kernel). I have whatever version of X was included (3 something, probably), and use KDE 1.3.
I have thought about going to X 4.x, and KDE 2.x - but as I am still shakey about breaking my system (it was a bitch doing the kernel patch - just to get the ZIP drive working, only then breaking the sound, having to install and configure ALSA, etc) - everything runs OK on it right now. I just would like to get some of the extra features.
Has anybody done anything like this, and what was your experiences? How difficult would such a major upgrade be? Would I have to patch the kernel again (one thing I have wondered is if I could just grab the latest patch for the kernel and apply it against my source, or if you have to do the patches incrementally - or if I would just have to grab the whole source, etc)?
Or, should I do what I am thinking of doing - scrap it all, get a reasonably late distro, install that and move my data over?
Any recommendations?
Worldcom - Generation Duh!
Reason is the Path to God - Anon
HW accellerated 3D in Linux and the BSDs is handled by ether the Direct Rendering Infrastructure or Nvidia's proprietary equivilant if using their drivers. The textures, polygon info, etc. are NOT handled by the X protocol. If you're going to slam Linux then at least do it CLUEFULLY. There are bad things that can be credibly said about DRM but then you would have to actually KNOW something now wouldn't you?
Nice to see the Radeon support is upgraded, and that the chip is recommended, since I have the All-In-Wonder Pro Radeon. Now I just need to get Gatos working with it.
Best Slashdot Co
Yeah, 80X50 text, and it sped up scrolling wonderfully.
Best Slashdot Co
Yes. In about 91 or so. That's when I decided to upgrade from VGA to an accelerated SVGA with, IIRC, 512K of on board memory AND a WordPerfect driver.
Best Slashdot Co
While it is true that graphics is not the job of the kernel, especially when running a server (WinNT's stability issues are a shining example of why this is bad), it is a nice option to have for Linux systems used as graphics workstations or for gaming, applications where you want to be able to squeeze as much performance as possible out of your video adapter. And for server class systems, where you don't need or want advanced graphics support in your kernel, it is a simple matter not to include those extensions at compile time.
X itself it quite small and fast (something like 1-2 MB, IIRC).
------
but then again, quake 3 isnt everything.
:)
i want to play those other nice games aswell, and i dont really feel that lokis effort are worth its money anyway ( because they port games that i played 1 year ago.. )..
and i dont consider p3-600 as a low-end machine..
framerate isnt the thing im really concerned about, i dont feel that i get less framerate in q1 in linux than in windows anyway. its just the fact that the games are mostly unsupported AND has a tendency to crash far more often.
i agree, x sucks at gaming, its the truth, i had the same problem with QUAKE damnit, both quake 1 and 2 ( yes i know it not x ) .
on several machines, just please, let go of your dreams on linux as a gaming machine. i say - dualboot if you need linux for something else than your server needs.
Actually, KDE being slow has less to do with X and more to do with linking, loading, and C++ virtual function use.
Check out:
http://www.suse.de/~bastian/Export/linking.txt
Besides, moving XFree into the kernel would be of dubious value at best. Moving certain critical _parts_ of XFree into the kernel might be a win, like the graphics drivers. After all, why the heck should a user space application like XFree be doing PCI management?
--
"I'm too old to use Emacs." -- Rod MacDonald
Try running XF4.0.1 on LinuxPPC with the Rage Pro driver that ships in the stable build.
Its a pig.
I imagine with the driver work and the inclusion of DRI, that 4.1.0 will be a massive improvement for Linux/PPC users.
I gots ta ding a ding dang my dang a long ling long
Obviously not (in the past 5 years or so) because in that case most people turn off features until everything runs fast enough. But i bet even nowadays there are people sitting in front of their PC saying: "Wow, look at all the stuff i can do now and the cool GUI, two years ago i wouldn't have thought it possible without enduring agonizing responsetimes".
Yup, i admit it, i think transparent window moves look nice, i would live without them, if they were slow or jerky, but now that i can have em i switch those features on. So one could say that most of the speedgain goes to (maybe unnecessary) eyecandy, but i don't think that is a bad thing.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
I know you're joking, but I have to point out some flaws in our information. First, DirectX isn't in the kernel. Just like most of Windows, it is contained in a userspace library. The only thing in the kernel is a channel through the HAL (on Win2K) that allows the DirectX libraries access to the hardware.
A deep unwavering belief is a sure sign you're missing something...
1) X runs on UNIX. Unicies are almost always server-oriented systems, and tend to have very short thread quantums. For example, the quantum on Linux 2.4 is 50ms (down from 100+ on 2.2). That means that if a process sends out a request near the beginning of its timeslice, it will be a minimum of 50ms before X is sheduled again. This is why renicing X has such a good effect, because it allows X to be sheduled ahead of other processes. OSs that use shorter timeslices (10ms on NT, 3ms on BeOS, 4ms on QNX) show much improved access times, even when the GUI is in a userspace server (as in BeOS or QNX)
2) It's badly designed. To tell the truth, I can't rationalize X's design. Wheras other OSes like BeOS use special-purpose messaging channels to communicate with the window server, X uses the much more general (and much slower) UNIX domain sockets. Secondly, when GUIs like Photon (on QNX) implement all the features of X plus more in less than a meg, one has to fault elements of X's design, elements that have nothing to do with either the versatility of transparent networking, nor the stability of a usermode server.
A deep unwavering belief is a sure sign you're missing something...
Actually, even games are moving farther and farther from the hardware. The main reason is because today's hardware is so complex, they have to hide behind libraries and drivers (OpenGL, DirectX, OpenAL, etc) anyway, so properly protecting everything isn't a problem at all. For example, there is much talk that new graphics cards will not export straight framebuffers without a performance hit, since it messes with their internal workings. Again, its not that X is in userspace that's the problem (sometimes I don't think some /. understand the actual differences between userspace and kernel space...) but that it is poorly designed.
A deep unwavering belief is a sure sign you're missing something...
To tell the truth, I don't want to pay for stuff I don't use. Where's the famed UNIX "choice?"
A deep unwavering belief is a sure sign you're missing something...
Oh god. He pointed out X sucked! Blasphemer! Keep it coming, baby, got plenty of karma to spare ;)
A deep unwavering belief is a sure sign you're missing something...
Don't forget the XVideo/Render/RandR code that the developers are working on. New releases often contain substantial upgrades for video drivers which can improve both speed and stability.
You can obtain the bleeding edge kernel modules from the ati project at linuxvideo.org.
http://www.linuxvideo.org/gatos/
Paranoid tinfoil hat crowd say Y here, everyone else say N.
One of the major problems I had running XFree86 on a laptop was having to switch between a port replicator (aka docking station) and using the laptop's display. For those of you that don't know, a port replicator lets you use a standard monitor, keyboard, mouse, etc. Switching between various XF86Config files got to be a royal pain in the arse.
So... those with laptops give this option a try in XF86Config:
Option "UseBIOSDisplay"
It lets you switch between monitors without changing the config file. Haven't had a problem yet.
Thanks. I checked the websites out and noticed a beta version for download. Check out the news section here: http://nvidia.netexplorer.org/
I am staying on XFree86 v3.3.6 + UTAH until either nVidia opens their drivers or I get another card. Unless nVidia changes their stance I will NOT be purchasing an nVidia card in my next machine.
:(
BTW, I run FreeBSD so not even the closed source drivers are an option.
Does anyone know if the XFree86 drivers support minimal hardware-accelerated 3D graphics on a TNT2 Ultra? Maybe close to the UTAH drivers?
I upgraded to 4.0.3 from the offficial binary distribution, thus breaking all rpm dependencies in my whole system, showing how little I know about rpm.
That was the day before they released 4.1.0.
Sometimes after an electrical storm I can see in five dimensions. --Cornfed, Duckman
It's kernel, not kernal.
Hello, my name is Robert Lerner, and I pronounce Lernux as "99% cpu"
I had a 3dfx Voodoo 3 3000 a while back, and had pretty much the same problems you mentioned with blender. Not only blender, but also AC3D and - here's the kicker - the problems were present on the Windows versions as well.
That in mind, it might be a card issue more than a driver issue.
As far as new cards, I have a Nvidia Geforce MX that's fully supported. The drivers are binary, and once I got the newest ones from NVidia, I had no problems with them.
If you want open-source only drivers, I believe that ATI's are - though I don't know how well they're supported.
-Denor
I was getting 30fps on ssytem -bench with my Matrox G450 and k6-2 500 from the 4.0.3 deb
Upgraded it myself from the binaries now i only get 10 fps.....
Piece of @#@#$.... my dvd-rom is a bookend.
It's weird it doesn't hit all banshee's though. Mine was able to run a sourceforge DRI snapshot from about a month ago just fine (with the modified slower ram timings). and my roomate's PCI OEM Banshee works just fine right out of the box with 4.1.0. very very weird.
;) pricewatch.com, sure.
voodoo3 for $30 locally, probably not
Good luck.
pm.
- --
- --
"I Hate Quotes" -- Samuel L. Clemens
I tried compiling myself, but gcc, f77, kylix, and every other compiler I could find said I had syntax errors. Do you know what language people are written in?
Just a few things I want to counter/correct.
/does/ have video drivers in the kernel. Have you heard of Linux's framebuffer support?? FBDev isn't XFree86's server that uses Linux's framebuffer... FBDev doesn't use a graphics card at all. FBDev is a headless, "dumb" X Server used for X development, it's just a fake framebuffer that doesn't display anywhere.
First, Linux
If you want "FAST 2D alpha BLTS" in Linux, then program with a library that is capable of writing to the kernel's framebuffer. GTK+ can do this now, without X in your way. As can GGI, as well as several other libraries.
True, not too many cards are supported by Linux's framebuffer. But that can only change with time (or time plus programmers, rather).
Btw, GGI is a cross-platform display-type independent graphics library... You say GGI is/was heading in the direction of integrating with the kernel on some primary level... The only way this is true is that GGI can use the framebuffer (which is built into the kernel). Since GGI is display independent, it can also translate it's graphics to display on a text-mode terminal (with aalib) or display using SVGAlib or whatever else. Tying GGI to a specific platform or architecture or display library or OS would actually be counter to its mission.
-=/\- Jizzbug -/\=-
Much of what DirectX does like blitting and 3Drendering already is in the kernel as part of your driver and since X seems to be the most instable thing in a Linux system today smallest amount possible should be in the kernel. As we see windows and Linux has similar performence in OpenGL(Linux) and Direct3D(windows) so it should be one big accomplishment to double those numbers by putting X in the kernel.
X can not also be directly compared to winGUI the way you do. X is biger, have network and multiple platforms and the price is performance.
To sum this up. The slow in X mostly comes from other libraries than X itself such as Gnome/KDE.
Download source, compile yourself.
Are all so lazy?
--
--
I like to watch.
Did you stop reading after the first sentence? Perhaps if you read all of it you'd see that it, in fact, wasn't a troll.
---
Slagborr
Some of us have to use the FB Xserver. Since framebuffer support is already less than fast, any speed improvments are quite welcome.
Good to see that Q3A speed is within a frame of the Windows results on the GeForce. Its a pity that he didn't test Unreal Tournament as well however; one of the main reasons for me getting a Linux partition up and running was that on my config UT is actually better than under Windows.
"I Know You Are But What Am I?"
hehe. +4, Funny and deservedly so.
In case anyone is taking this seriously though, remember that Linux does a million and one things, many of which do not involve sitting on a desktop displaying an X console. Its precisely this kind of kernel bloat that is letting Win2k lose to Linux in server tests, so unless the kernel undergoes a split its a bad idea.
"I Know You Are But What Am I?"
This is something thats measured in hundredths of seconds for Pete's sake...
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
looks like they're already slashdotted... dammit
The real reason I think is historical, the argument was that Linux was more stable than WinNT because its video drivers weren't built in the kernel. I don't believe this is true, it has only happened to me once that my computer froze up to a point that I couldn't do Ctrl+Alt+Fx anymore, I'm not even sure it was X (no network to telnet from here at that time). Another reason might be that X is maintained well and there is no point in moving the drivers, especially since the drivers would have to built into X for other Unices anyway.
I'm interested in the opinions from people that know a bit more about this than I do.
Monkey sense
But now that I think about it.. that would probably mean inserting OpenGL (or something like that) in the kernel which doesn't seem like a good idea :-).
Monkey sense
Odd... at Xfree.org the release notes say the Matrox G450 card is supported... but then in the man section there's no mention of the G450... am I missing something here?
____
Skivvy Niner? Email me!
HEY! Look left just ONE MORE TIME!
Maybe I'm picking nits here, but on page 3 of the article (the "Test Configuration"), the system's NIC is listed as "Intel EtherExpress PRO 10/100 - Realtek 8139b, PCI". That's just wrong.
This is the major point for me. Especially since I sometimes throw together frankenboxen with a wide variety of obscure parts. [I obviously need the education]
Still looks very promising. Tbe proverbial step in the right direction.
Check out the Vinny the Vampire comic strip
"It is a greater offense to steal men's labor, than their clothes"
in www.linuxvideo.org/gatos/
> I've just installed 4.1 on My Powerbook 3400 (Scratch installation, based on Debian Potato,
:)
> kernel 2.2.19). The 3400 has a nasty little Chips & Technologies 65550, and performance has
> always been so-so. With 4.1 (using the fb driver) it *smokes* (well.... for a pb3400).
The boost comes from Keith Packard's new mishadow layer that I updated the fbdev driver to. Glad to hear it's noticable.
And I hope you also enjoy its new RENDER and DGA support...
--
--
Free Software enthusiast; Debian GNU/Linux (powerpc) developer
I'd like to point out that I was able to fix this in the last minute. Donation account number available on demand. *grin*
--
--
Free Software enthusiast; Debian GNU/Linux (powerpc) developer
I am Voodoo3 owner. New XFree86 works faster, and more stable. 4.0.3 was bad - no Xv support, troubles with console and framebuffer. However - OpenGL in current CVS (and 4.1.0) is still broken. In all tests or benchmarks you just write about Quake or UT, never about less popular stuff. There are serious problems with Blender for example (but works much better than before!). When I use software renderer - everytihing is OK, but slow. When I turn on hardware accelerated 3D - some object are not drawed, blinking, etc... you won't notice it in pure OpenGL apps, but try gtkglarea, SDL/paragui or anything else with 2D widgets...
Should I change video card? But what should I choose? Nvidia has binary only drivers, tdfx dirvers are buggy... is it any other way?
I'd be happy if someone got it to compile for Solaris and packaged it up. It seems that a key part, an include file if I remember correctly - prevents it from compiling the server itself. It's under the sun stuff. I don't have the information handy offhand, but I could reproduce it with differing versions of XFree86 as well as the X.org version(s). I know it's possible... I just want Xinerama and Render support for Solaris! Is that so wrong? :)
I can't say how stoked I am to try the render, xinerama and truetype support finally, under Solaris...
Props to the XFree team!
1) First, this is great news for Radeon users. IIRC, though, when I tried the Radeon DRI from Sourceforge, I had to recompile my kernel without its DRI modules and use their modified X's. I already know that I'm going to have to download the source tarball to use the DRI in XFree86 4.1.0. Do I have to recompile my kernel too? (Not that it's hard - just wondering.)
2) There was a bug in DRI that would freeze up the entire system. I could always reproduce it by playing a few minutes of Quake III. Does anybody know the status of this?
3) (Stupid luser question) Where can I find info on how to do AA fonts on XFree86?
Thanks in advance for any good answers.
I got my Linux laptop at System76.
I've just installed 4.1 on My Powerbook 3400 (Scratch installation, based on Debian Potato, kernel 2.2.19). The 3400 has a nasty little Chips & Technologies 65550, and performance has always been so-so. :-(
With 4.1 (using the fb driver) it *smokes* (well.... for a pb3400).
Apart from some minor (self induced) stupidities with the new Xfree input layer, everything looks pretty good.
Was going to try it on my AMD workstation, but *still* no GLX for Riva 128
Ahh.. I guess time for a new graphics card..
Right. The DRM modules are only available with the source distribution. Too bad you have to download a 25meg tgz for 150k kernel code...
Dunno .. mmm 8mhz + 4mb ram and a gui capable of running dtp+paint+games.
RiscOs + acorns had a nice 32 bit gui + anti-aliased fonts in 1991
Yeah and so did apple IIRC
- "kernal"
- Implication that Alan runs the "kernal"
- "Breathtaking performance" of DirectX
- Command line programs not "real"
"HTML programmer" was a little too far, but OTOH a lot of people bit.
--
324006
I think Taco's losing it. First he was going on about how much things 'costed', now he's harping on about not being able to type 2 words at a prompt... dear oh dear. :)