Slashdot Mirror
XFree86 4.0 Now Available
YAH00 writes: "The 4.0 release of xfree is now available!!! I'm downloading it from ftp.xfree86.org as I type!!! " I've played around with the preview releases, and 4.0 looks to be a much needed improvement over the 3.3.x tree, with xinerama [?] features and improved performance for many graphic chipsets.
http://garnix.unix-ag.u ni-hannover.de/~ingo/xf86-4.0.tar.gz
http://canadia.geecs.org/~mp3/xfre e86-4.0.tar.gz
Is there a CHANGELOG? Does it have better support for my VooDoo3 3000?
-Davidu
# Hack the planet, it's important.
Supposedly the GeForce is supported:
http://www.xfree86.org/4.0/Status21.html#21
That doesn't mean DRI support though, only 2-D
--
Aaron Gaudio
"The fool finds ignorance all around him.
"Every man is a mob, a chain gang of idiots." - Jonathan Nolan, Memento Mori
makedepend stalled at some point during make World. Killing the it off with ps was the answer, compiled without any probs.
Running it now. Mozilla actually looks right, the menu fonts are the correct size. Woohoo!!!
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
Let's give the XFree86 team a big round of applause for all the hard work they've put into this. Thanks a lot - your hard work makes life all the better for us.
"If ignorance is bliss, may I never be happy.
-- Veni, vidi, dormivi
http://www.au.xfree86.org/4.0/RELNOTES. html
Enjoy. Congrats and thanks to the XF86 team
Eric
(here's the introduction/installation instr. for those with mirror probs):
XFree86 4.0 is the first official release of the new XFree86 4. XFree86 4 represents a significant redesign of the XFree86 X server. It is very important to keep in mind that XFree86 4 is still very much in development, and it contains a lot of new work. That means two things: there is a lot of new exciting stuff to try, but being new code, it hasn't had nearly as much of a workout as the stable 3.3.x releases. If you're looking for a well-tested, stable release, and can't afford the inconveniences that new software can sometimes cause, then you are probably better off sticking with the 3.3.x releases for now. If you have the resources to try out the new version and investigate its features, or if you just like being on the bleeding edge, then please try 4.0!
This release isn't quite as complete as we would have liked. The main missing pieces are a nice configuration tool and support for some of the hardware that 3.3.x supports. The first point means that configuring the server might be more painful than usual. The second means that your hardware might not be supported by 4.0, or it might be supported at a lesser level (conversely, some hardware is better supported in 4.0). We've attempted to provide some information about the second point in our Driver Status document. Please check there first before trying 4.0. Unfortunately that document is still fairly basic, but it should at least give you an idea of whether you're likely to be able to use 4.0 at all or not.
On the subject of configuration, we have updated the basic text-based tool "xf86config" to generate config files in the format required by 4.0 (3.3.x config files won't really work with 4.0). We're also working on some other configuration tools, including one that is built-in to the X server. An early version of this is included in the release, and it works well for some hardware. To try it out, just run (as root) "XFree86 -configure". Both of these configuration options will at worst give you a reasonable starting point for a suitable configuration file. We've put some effort into documenting the 4.0 config file format, and you can find that information in the XF86Config manual page. Please check that and the driver manual pages and related documentation for further information about that.
Oh, another thing you might notice is that our documentation is rather patchy. Most of what is present should be in reasonable shape, but there are gaps. We thought it better to leave out docs that were very out of date rather than providing inaccurate and misleading information.
Finally, before you download and install the binary distributions for this release, please have a quick read through the Installation Document. It may save you some time. If those cautionary notes haven't turned you away (and we certainly hope not), please read on... The sections below describe some of the new features and changes between 3.3.x and 4.0. There is a lot of new stuff, and we definitely don't have enough space to cover it all here.
Want to work at Transmeta? Hedgefund.net? Priceline?
Can your IM do this?
Looks like it's pretty much just 3dfx cards now...
ftp://download.sourceforge.net/ pub/mirrors/XFree86/
---
SourceForge Programmer Type - http://sourceforge.net
---
Drew Streib, dtype.org
And of course, I'll be the first loser to ask someone to build me RPM's! :)
in the meantime, we're downloading it to our little p75 multi-t3 server at ftp://soul.apk.net/ and we can mirror if it all comes down. No guarantees.
but i do want some rpms!
Mike Roberto
- roberto@apk.net
-- AOL IM: MicroBerto
Berto
Please resist using the canadia.geecs.org mirror unless you are on a reallly slow modem connection :) - that's my computer and its not exactly ready to handle a slashdot load :P (not to mention my resnet admins will get pissy :))
I'm setting a low limit on apache, so my appologies if you have trouble connecting.
thanks!
OFTC: By the community, for the community
This was actually released a year ago!
;)
Xinstall.sh 20 Kb Tue Mar 9 23:18:00 1999 Bourne Shell Program
Oh no! How did we miss it? It was exactly a year ago today!
Maybe this is Y2K related.
I didn't know anyone from APK, or even Cleveland, knew what Linux was. =)
-- BLarg!
ftp://soul.apk.net/pub/xf4/
;-)
enjoy until we get slashdotted!
Mike Roberto
- roberto@apk.net
-- AOL IM: MicroBerto
Berto
Hooray!!!!! Only True Geeks Revel In This Software....
:P*
and i don't know about you guys, but im proud to be one. Congrats to the xfree team, you guys did good.
*fires up the old k6-2 to give this a whirl..bah who needs to go to school tomorrow
How much does it cost?
Will/does XF86-4 break anything that requires the Xlib or Xt libraries?
Do the following really mean anything? SCSA MCP CCSA CCNA
--I'm not actually after an answer!
Does Xfree86 4 have support 2-d transperancy? Is such support necessary for pulling transperancy in X? One of the things I like about Mac OS X is that it can do slick things with tranparent windows and menus and such. I'd like to some wicked cool enlightenment theme with such trasperancies all over. Even more, I would like it to have some hardware support so that it will be fast.
So, does 4.0 do this? Does anyone even care? Or is this really in the domain of toolkits to handle?
Got HTML? Want LaTeX? Try html2latex
canadia.geecs.org is down 50 connections times 70 megabytes at any given time was too much. sorry!
OFTC: By the community, for the community
Unless something has changed, the G400 is specifically unsupported unless you have a second card. Precision Insight may be writing dual head enabled g400 drivers in the future though
treke
E and Xinerama do the occasional bickering match on my box, and it usually ends up that the server dies(if you run it as root) or Enlightenment stops responding(as user; sometimes 'restart' works sometimes not). This usually happens when you try to move a window across the boundary. Turning off 'transparent' almost eliminates it tho.. Blackbox behaves, as do fvwm, fvwm2, twm, and Afterstep.
.sig: Now legally binding!
This is basically a problem in your browser. The ls command used by ftp servers has a policy of giving a year if and only if the file is more than x months old. I believe x is 6 for most FTP servers.
Your client, trying to be helpful, attempts to reconstruct the year by assigning a year in the last 12 months if the year is not given. This works well. Most of the time.
The analomous case is when the timezones differ so that the file looks like it's in the future to the client.
Fixing this is not hard, and I did forward it to the Mozilla team.
Moral of the story? Getting times and dates right is hard.
LILO boot: linux init=/usr/bin/emacs
Matrox didn't release specifications for the G400 because it has a TV out for use with DVD cards, and thus Macrovision. (the thought being that if people knew the register used for Macrovision enable, they'd just turn it off when playing DVDs)
This didn't stop it from just getting reverse engineered anyway, and the latest Linux 2.3 kernel supports both outputs on the G400. (ironically, the reverse engineering didn't figure out where the Macrovision control was, so now it's impossible to turn it on at all)
The current XFree86 accelerated server won't work with a dualhead G400, however if you use Linux 2.3 and framebuffer consoles, you can run XFree86-FBDev on both framebuffers simultaneously.
You may be able to use the accelerated X server on the main output, and use the unaccelerated framebuffer for the second, although for all I know that might not work.
If everyone keeps hitting the main FTP site instead of one of the mirrors, the stuff'll never replicate.
Here's a hint: Mirror List
æeee!
just replace 'source' directory with 'dasource'
SlashMirror: Where to put files for fellow /.'ers
SlashMirror: Where to put files for fellow /.'ers
Welcome to the begining of the end for Linux.
:)
XFree86 4.0 represents the culmination of thousands of man-hours work. It is the peak of X windows development, and darn nifty software too.
It hosts a wide range of new and powerful features, and world class performance.
XFree86 4.0 means a lot of good things for a lot of people.
But, Xfree86 4.0 also means something bad, it means the end of the Linux system as we know it.
Not the Linux system as a piece of software, but as a powerful piece of Free Software.
Today, we enjoy the freedom of a completely free system. The linux system gives you freedom beyond what any complete server/desktop OS has ever brought you before. Not only the freedom to use, improve, and repair your system, but also the freedom to use it on common hardware.
A critical aspect of the freedom of the Linux System, that differentiated it from others before it is the ability to have freedom with all components of the system. As you can seldom completely diagnose, repair, or improve one part of a system without making changes to other parts. Thats part of what being a system means.
XFree has become a critical part of the Linux system.
Unfortunatly, many video card vendors wish to keep their source very closed. They feel that this gives them some competitive advantage, because often a smart driver can more then make up for dumber hardware. The fear that copyright is insufficent to protect their intrests, a fear well encouraged by the Microsoft enviroment most came from.
Keeping the source closed also helps them decieve the consumer. Closed drivers can help hide the real capabilities, bugs, and performance issues of their hardware. In the windows world, drivers often cheat to improve performance. Usually it doesn't effect quality very much, but people should have the right to know. In the low margin, highly competive video card market, the makers feel that every point counts.
In the past, Xdriver developers were effectivly prevented from producing binary only drivers because of the difficulity of tracking the codebase. This made them double-think the need for closed drivers. In almost every case, they decided that closed wasn't worth a little extra effort and freedom won out.
Now with XFree86 4.0, they no longer need to fear that. There is a VERY well written and modular API that should require little revision. When a revision happens, it will be VERY easy to track.
Several vendors are already working on binary only drivers for XFree86 4.0.
In the race to support every possible card at the highest speed, to compete with windows in certian markets (games, cad, etc), the XFree86 developers have decided to trade freedom and openness for a few more Xmarks or one more card with 3d support.
The XFree86 development has never been very open, it's developers could quite argueably be said to not understand the benifits of truely open development. In the future of binary only drivers, these gurus will probably have (NDAed) access to the code, they won't be affected personally.
Soon, most common hardware will not have open drivers. Linux developers will have to work harder to work around bugs in other peoples software. People on uncommon hardware, (alpha,ppc) or strange needs will usually be left out in the cold. You will no longer be the master of your computer, it's use will be contingent on your agreement to some Draconian UCTA enforced licence, your ability to improve, repair or hire someone else for that purpose will be signifantly reduced. A chain is only as strong as it's weakest link.
This is a terrible loss to ALL of us. In our race to compete with closed systems, we are giving up the one thing that makes Linux *better*.
Unfortunatly, most will never realize the loss. Years later, those same people who today revel in the 500fps brought out by their videoforce 1024's binary drivers will be wondering why Linux became what every closed system is today: Controlled, secretive, inflexible, restricted, and sometimes unstable.
Today, people are regulary ignored in bugreports on linux-kernel when they say they are running VMware. Privliged closed software makes it almost impossible to debug the kernel with any certanty.
Even Microsoft blames most of the windows crashes on buggy third party drivers, and I suspect MS would have much better luck at getting someones driver code then Alan Cox.
Please think twice before accepting a slightly superior closed solution. It's not really superior in the long term. While it may work for you today, someday *you* might be on the wrong end of the bargan. Please support your future needs, and tell the vendors that we wont take any more unnecessarily closed drivers.
Thanks for you time, sorry for the type-os (gotta post before I'm too far down to be read).
-greg@linuxpower.cx
BTW 4.0 finished patching for me right now, 3.9.18 works great, hope 4.0 is even better.
I'm sure matrox won't be far behind.
Matrox dosn't make its own drivers, they just put out the specs.
[ c h a d o k e r e ]
ReadThe ReflectionEngine, a cyberpunk style n
Yup, the /dev/tdfx driver is quite available for 2.2 kernels. I believe you can get it from the DRI folks (dri.sourceforge.net).
Bad fonts under Netscape is a solved problem };-)
While anti-aliasing isn't involved, I think you'll find these a significant improvement over X11's out-of-the-box look:
X: A Site for Sore Eyes
(go to the bottom of the page)
iSKUNK!
Here is a pic of the TT fonts in netscape (very crisp!), and the gears openGL demo.
-- Thrakkerzog
-----------
"You can't shake the Devil's hand and say you're only kidding."
Hi.
I am writing a 3D game engine, so I think I know what I'm talking about.
First of all, the only reason why your V3 is out-performing your TNT2 in Linux is because you are not using the DRI drivers for the TNT2. In Windoze, the TNT2 will kick the V3's ass any day.
Second, the V4 and V5 SUCK ASS compared to the GeForce. Why? Transformation and Lighting. The GeForce has on-board T&L, which means that it can pump out five times as many triangles per second as a V4/5, and use less CPU power doing it. High polygon counts are by far the best way to enhance image quality at the moment. It looks much better than AA. Trust me.
Now, if you are looking at benchmarks of current games, then YES, the V5 will be faster than the GeForce. This is because current games do not even attempt to draw high-detail geometry, which is what the GeForce is made for. That will change very soon, however, and I garentee you that the V5 will suck ass compared to the GeForce in games released a year from now.
There was a survey conducted of game developers a while back, asking if they thought T&L was more important than high fill rate. They unanamously said yes. It was at voodoo extreme, but I lost the exact link.
Anyhow, make sure you know what you are talking about before you call someone misinformed.
------
-Everything has a cause
-Nothing can cause itself
-You cannot have an infinite string of causes
If anyone wants it, it's located at:
ftp://inept.rh.rit.edu/pub/XFree86-4.0/
Unlikely, given that the Number Nine section of the driver status document says:
The release notes say:
which might (from the "as complete as we would have liked") indicate that support for the Number Nine cards, and other cards not supported in 4.0, may arrive in a later release.
a) The linux kernel isn't any more open a development environment than XFree is. There are a couple of gurus with commit rights. Everyone else sends patches. Most of those are rejected. It's not a formal process of approval like becoming a FreeBSD developer. But you're equally free to fork the code in any of those cases -- the unwashed public always has full access to everyone's latest stuff.
:)
b) Hiding behind cruft is not a way to fight closed source drivers. They've been offered before, many times. And the response has been increasingly negative. I think we'll continue to write our own, open drivers, and write better ones. I want code I can review running with priviledges on my machine. How about y'all?
c) A cleaner driver model will make it easier to write Free drivers too.
d) Let's keep things positive here, huh?
e) "uncommon hardware, (alpha,ppc)" will rise to crush puny pathetic PCs once and for all
I saw a prototype of the SGI / nVidia setup at the Sydney linux expo yesterday. Compared the the AMD / GeForce / Win32 setup the Intel / SGI box was half the speed :( The AMD was at 1Ghz and the Intel was 'an unspecified speed' but still, looks like some more work to be done. For the record a 1024x768x32 timedemo 1 in Quake3 on the AMD was 72+FPS, the SGI was 32 at same res & colour depth.
Perhaps you could direct us towards some benchmarks?
There is an article on Tom's Hardware Guide that does a bechmark of the GeForce256 against most other common 3D cards using a program that can take advantage of hardware transform & lighting. The graphs on page 5 pretty well sum it up. The GeForce is about 25%-30% faster than the other cards.
0 1 - just my two bits
How soon will it be before we can get XF4 in RPM form? I could just download the tarballs and roll it myself, but I'd like to try to keep everything all rpm kosher on one of my boxes.
NH
Hey, you can always stick with 2 revisions back + updates. I'll take my chances with the fun stuff.
---
Since you brought it up...
/. years. It holds no water. You, as an obvious repeat AC, know of something called the "Slashdot Effect", it's the strange phenomenon of 100,000 info-crazy quadrapeds stressing the laws of physics and the capabilities of silicon based counting machines. Sometimes this "effect" breaks stuff. Chains being only as strong as the weakest link and all that, bottlenecks and such.
/..(nitpick that punctuation)
I've seen this lament a number of times in recent
So to bring it to a point, sometimes it is, in fact, "informative" to cut and paste some electrons, as such action makes this information more available to all, utilizing the vast resources of a billion dollar corporation who's mouthpiece is affectionately known as
I await your inevitable retort.(and my Karma protects me from flames like Goku's many Dragonballz)
--
+&x
I have a Voodo3 and i have the source sitting on my drive for 4.0, as a matter of fact if you check the DRI support 3dfx is one of the only ones because they are open sourced already.
I am sure that nVidia will follow, SGI owns them and SGI is giveing the farm away to linux in source form. why would the nVidia be any different. they gave half of the gl subsystem to xfree.org. them holding out on nVidia makes absolutly no sence.
Please do not flood NVidia's email box with requests to hurry up; that won't help. They know. They're on it.
A very quick note politely wishing them well in maintaining their Open Source XFree releases might not be out of place...
Schwab
Editor, A1-AAA AmeriCaptions
I can't get truetype fonts to work. My XF86Config has the 'Load "freetype"' line, and the fonts/TrueType directory is loaded, but none of the fonts show up in the Gimp or anything else. On top of that, mkfontdir doesn't see any of the fonts. I have a ttfmkfdir from somewhere, but I still don't see any fonts. What should I try?
530- Australiasia
530- -----------
530-
530- Japan
530- ftp://ftp.netlab.is.tsukuba.ac.jp/pub/XFree86
530- ftp://ftp.iij.ad.jp/pub/X/XFree86
530-
530- Korea
530- ftp://ftp.kreonet.re.kr/pub/Linux/xfree86
530-
530- Australia
530- ftp://mirror.aarnet.edu.au/pub/XFree86
530- ftp://x.physics.usyd.edu.au/pub/XFree86
530-
530-
530- US
530- --
530-
530- ftp://phyppro1.phy.bnl.gov/pub/XFree86
530- ftp://ftp.rge.com/pub/X/XFree86
530- ftp://ftp.varesearch.com/pub/mirrors/xfree86
530- ftp://ftp.infomagic.com/pub/mirrors/XFree86
530- ftp://ftp.calderasystems.com/pub/mirrors/xfree86
530- ftp://ftp.cs.umn.edu/pub/XFree86
530- ftp://ftp.kernel.org/pub/mirrors/xfree86
530-
530-
530- Europe
530- ------
530-
530- Austria
530- ftp://gd.tuwien.ac.at/hci/X11/XFree86
530-
530- Finland
530- ftp://ftp.funet.fi/pub/X11/XFree86
530-
530- France
530- ftp://ftp.lip6.fr/pub/X11/XFree86
530-
530- Germany
530- ftp://ftp.gwdg.de/pub/xfree86/XFree86
530- ftp://ftp.cs.tu-berlin.de/pub/X/XFree86
530-
530- Italy
530- ftp://ftp.unina.it/pub/XFree86
530-
530- Norway
530- ftp://sunsite.uio.no/pub/XFree86
530-
530- United Kingdom
530- ftp://sunsite.doc.ic.ac.uk/packages/XFree86
I'm for one is amazed at how fast the 4.0 release came. I'd expect many more 3.9 pre-releases. I fear it probably hasn't been tested as well, and it is a fact that it doesn't support all the hardware that 3.3 does.
I do hope that 4.0 is usable, and if so, perhaps new distributions may pick it up. Linux projects (with a few exceptions) have traditions of releasing software "when it's ready", no matter how much delay that means. This has given Linux it's reputation as a solid OS. I hope xfree86 4.0 will be no exception...
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
Hopefully companies like Creative Labs will set a good example for others to follow. Creative released a closed-source driver for the soundblaster live. It worked (just) but MP3 playback was noticably worse than in Windows. They got a lot of flack from the Linux community over their refusal to open-source the driver and eventually gave in and released the source under the GPL. The soundblaster live driver suddenly improved beyond recognitions (thanks Alan & everyone else) and now plays MP3's better than the Windows driver on my PC.
If companies realise that there are real benefits to open-sourcing drivers, then they might just do so.
HH
Yellow tigers crouched in jungles in her dark eyes.
Yellow tigers crouched in jungles in her dark eyes.
She's just dressing, goodbye windows, tired starlings.
All this means is that we need to use a different means of keeping the pressure on. Personally, I'm *glad* I'll be able to have a little more flexibility in using binary drivers and at the same time I'm *sad* that this means of pressuring harware vendors to open their specs is now going to be weakened.
There are a few factors working in our favor:
The binary video driver api doesn't give hardware vendors cross-platform access - they wind up having to build and distribute drivers for every platform, multiplying their headaches and workload. This is work than can much more efficiently be done by the distributions and platform maintainers, including making necessary adaptations, for example, byte swapping - a much bigger issue than you'd think.
It doesn't give hardware vendors access to the power of open-source development, and the quality improvements resulting therefrom. Oh, and don't even *think* about trying to pass of a binary version of someone's open source driver as your own.
Closed-specs hardware vendors don't get the "coolness" bonus from, for example, us, the Slashdot community. Don't underestimate the effects of this: we've now become the "brand specifiers" for a huge part of the PC market, especially the games market. I'd say that we had a lot to do with 3Dfx's decline (because of closed-api concerns) and NVidia's rise (because they opened *part* of their specs).
The embedded market XFree is just too big and bloated for the embedded market - anybody care to argue this? Or for installing on old 486's and P90's. I know - I've tried it. We absolutely have to have an alternative, and there are already several projects underway on this. Let's not build in a binary driver api in these new video systems for at least 2 or 3 years, ok? That will keep the pressure on: if you want your card used in the embedded market (possibly much bigger than the desktop market) you'd better open the api. Do it sooner and get a bigger piece of the market. Do it later and become a historical footnote.
Life's a bitch but somebody's gotta do it.
2) -- Read the REALNOTES for XFree 4. Thay spoke about ATI, 3Dfx, Matrox, S3 and others BUT NOT OF NVIDIA for today and future releases of XFree. Why ? Have a look on recent news from Slashdot saying that NVidia dropped Mesa and want to develop their own implementation.
Today, NVidia is the only one that don't want to help OpenSource Developpers. They don't understand what means OpenSource and are proud to release scrappy drivers. If someone successed in using NVidia GLX with moonlight or others 3D software without having a crash, tell me ! I wonder if someone still tries to go to their OpenCloseSource site in order to have informations or to try to develop something for their card.
3) --A proof of Nvidia doesn't want to release their specs: ATI annonced to help programmers for developping drivers for their cards 6 months later than Nvidia. Today ATI has better support than NVidia. No comments ...
Usualy, I don't like to say that but ... NVIDIA YOU SUCK ONCE MORE.
To NVidia: your future is in the hands of consumers not in your cards' specications.
I think your extreme attitude helps marginalize Linux rather than support it. A future where open and closed software intertwine (for various values of closed) is not to be feared. Yes, some vendors will gain temporary advantages through concealment, but you show little faith in the power of open source if you believe that its advantages will vanish as soon as such hybrids appear. Other vendors will go the open-source route, and profit from its advantages.
You mention several advantages of open-source, such as better stability and intregration. These are real, solid advantages that potentially give one vendor a leg up over another. In the face of this, it would be unlikely that no vendor would take advantage of those things. Many won't--old habits from the MSWindows domain will die hard--but a few will, and from their success more will be encouraged to do so.
Look at it from another perspective: we're going to get vendors involved in Linux who otherwise wouldn't be involved. Then we'll convert 'em. Not all of them, but the fact remains that opening up a middle ground like this gives us more of a chance of pulling them into the open-source way of doing things than an all-or-nothing attitude will.
Tear down the walls!
it has been often bitched that linux, and open software in general, has jack shit for innovation in the user interface department. i say nuff o dat, and i hereby make a motion to go where no windowing system has gone before, etc etc etc... of course, it needs coders. get busy, ya lazy evercrackheads, and ye, in the corner, oh wretched ut whuppers of ass, arise! produce cool shit!
berlin owns ya. it has the potential to beat down os-x with jackie-chan-style grace. down with x! all hail the new windowing thingy, berlin!
-- sayke, v2.3.05
XFree86 site says that there is no hw acceleration for Rage Pro chipsets in 4.0.
However you can use Utah-GLX module for XFree 3.3.6, which supports DRI for Rage Pro cards. Go to http://utah-glx.sourceforge.net for more info.
http://www. matrox.com/mga/press_room/lat_press_rel/matroxg400 _linux.htm
Dualhead is announced for soon, although their site isn't very informative.--
Doug Rabson has the drm ready for XFree86 4.0 under FreeBSD. This gives you DRI with Voodoo3 under FreeBSD. I would suggest the freebsd-multimedia mailing list for more information. Ports will be available during the next days.
---
What I'd like to know is how fast really is the transformation engine on that card? Is it able to surpass the current generation of CPUs? Will it be able to out perform the boxes that come out in six months? Let's get real here. Transformation is only useful when it is substantially faster than the using the CPU. How many games can progress with non-rendering aspects of the gameplay without user input? So what good does it do to offload the job onto the vid card if the CPU still has to wait until the frame is displayed and the player has had a chance to provide feedback?
The drivers included in the current XF86 release are 2D accelerated drivers. They don't do 3D. However nVidia has released the sources to their glx module for XF86 3.3.x. The only problem is that it's very confusing, unexplained source code. You could conceivably study the code and figure out how it works. So far nobody has been interested in doing so since nVidia seems to have given the impression that they would be providing such drivers as the time grew near. We'll just have to wait a day or two.
Do you know that the code you choose to run has been looked at and audited by someone other than the authors? Or is that just something you believe?
If you have the hardware that is supported, then 4.0 would probably be an improvement over the 3.3.x versions.
Move quickly to do what? Take their driver developers away from programming drivers and put them to work on filtering email? Sounds like a good idea to me.
Where do these stupid and immature suggestions come from?
Ok, Here's (possibly) the first problem to be posted with output:
/usr/include/math.h:348, ../include/misc.h:181,
this is on make in the Xserver dir:
making all in programs/Xserver/include...
make[1]: Entering directory `/tmp/X/xc/programs/Xserver/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/X/xc/programs/Xserver/include'
making all in programs/Xserver/dix...
make[1]: Entering directory `/tmp/X/xc/programs/Xserver/dix'
rm -f atom.o
gcc -c -O2 -fno-strength-reduce -ansi -pedantic -Wall -Wpointer-arith -I../include -I../../../exports/include/X11 -I../../../include/fonts -I../../../include/extensions -I../../../programs/Xserver/Xext -I../../.. -I../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DSMART_SCHEDULE -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO atom.c
/usr/include/bits/mathinline.h: In function `__signbitf':
In file included from
from
from atom.c:49:
/usr/include/bits/mathinline.h:117: warning: ANSI C forbids specifying structure member to initialize
/usr/include/bits/mathinline.h:117: initializer element for `__u.__f' is not computable at load time
/usr/include/bits/mathinline.h: In function `__signbit':
/usr/include/bits/mathinline.h:122: warning: ANSI C forbids specifying structure member to initialize
/usr/include/bits/mathinline.h:122: initializer element for `__u.__d' is not computable at load time
/usr/include/bits/mathinline.h: In function `__signbitl':
/usr/include/bits/mathinline.h:127: warning: ANSI C forbids specifying structure member to initialize
/usr/include/bits/mathinline.h:127: initializer element for `__u.__l' is not computable at load time
make[1]: *** [atom.o] Error 1
make[1]: Leaving directory `/tmp/X/xc/programs/Xserver/dix'
make: *** [dix] Error 2
Mozilla's ability to do alpha PNG has nothing to do with X's ability, just like the gnome-canvas can do alpha pngs without X server support.
Well, I'm not a driver programmer. I'm a web developer.
I know very little about programming languages outside of a little C I've gleaned from working with PHP.
I know I would prefer an open-sourced driver for my graphics card (or hell, any piece of hardware I own that I want to have work in Linux).
Why?
Easy. Even though I'm not a driver programmer, I know there are people out there who are. If there's a problem with the drivers that VidCardCompany X releases, and I find it, I'm pretty sure I could find a way to pass that information on to someone who DOES know about driver programming, and CAN fix the problem.
This is the beauty of open-source. It doesn't matter whether YOU know how to fix it - there are others who do, and as long as you can communicate the problem to them effectively (read: detailed descriptions, possibly traces if you know how and it's appropriate), most are more than willing to delve into the code (providing they have time).
These little fixes can be distributed to the main vendor (or project coordinator or whatever) as patches to the source -- and thereby worked into the main version that most end-users would download.
As you said, the whole thing is quite slick. It requires that the end-users report problems to people who can fix them. It requires those people fix the problems and send patches to the main distributor. It requires the main distributor to add those patches to the distribution. Yes, this is a bit more work than the lemming-like attitude many end-users have, but it's worth it in the long run.
Probably doesn't require a heckuva lot of training to the end-users either. Just give them a checklist to follow if they spot a problem, and a nice little form to fill out. I've taught a number of end-users to submit meaningful bug/problem reports. Most ARE willing to help as long as it's not that tough for them to do.
As more people move to, or try out Linux and other open-source OSs, this step is CRITICAL. Teach the end-user HOW to be a productive member of the OSS community and they WILL.
Man, I'm rambling today...time to get back to work.
Nvidia is working on full DRI drivers for 4.0 for TNT2 and GeForce. Yes, they will be closed source and yes they will use a licensed SGI OpenGL implementation and not Mesa. That's fine with me, MESA is great but it is NOT a complete feature implementation of OpenGL and there are many known bugs with it.
Pesonally, I'm going to wait to see the performance and stability of their closed source drivers before I condemn them. Arguably, Nvidia has the best OpenGL drivers for Windows of any of the consumer boards. (By this I mean that the Nvidia cards work flawlessly with professional application like Maya and 3D Studio MAX even though they were not designed for that market) They also have a lot of ex SGI employees and know how to design a good opengl pipeline and then drive it hard.
IMHO, as long as their drivers are fast and reliable I don't care if they are open source or not. If any company can make a stable and fast linux driver without the help of the Open Source community it's Nvidia so I'm willing to give them a chance at least.
Several postings on the Utah-GLX dev list have hinted that Nvidia has an inhouse developed SGI OpenGL GLX driver for X Free 86 ready to go. They were waiting for the final release of XF86 4.0 so that the API for DRI would not change anymore. Now 4.0 is out I reckon there will be a Nvidia XF86 4.0 driver out within 2 weeks.
Now tell me, how is this "Funny" enough to be rated to a 5?
Chris Hagar
"The price of freedom is eternal vigilance." - Thomas Jefferson
I just did, on my 2x466 Celeron + V770/32MB system, and the 2D performance improvements are startling.. You'll probably have to regenerate your XF86Config but it's definitely worth it, unless you want to use glx (though utah-glx might work, I have yet to try)..
BTW, the DDC stuff is way cool, helped me put in the ideal modeline for 1920x1200 on my Sony W900 24" widescreen, and bring it up to 76Hz refresh!
That modeline, btw:
ModeLine "1920x1200" 245.500 1920 1984 2240 2584 1200 1203 1206 1250
Your Working Boy,
I believe that he meant that the "entire Linux system" is not as free or open-source with the inclusion of XFree86 4.0
Chris Hagar
"The price of freedom is eternal vigilance." - Thomas Jefferson
I first saw it when they said that 3.9.18 was going to be the last pre-4.0, they should say this. If the stable kernel development coordinator had said that 2.2.15pre13 was going to be the last 2.2.15pre, it would be the same thing. (For those of you that don't know, that was a relatively buggy pre). If something was needed to be fixed in XFree86 3.9.18, they should fix it, not just shove it out the door. Otherwise, they're not better than Microsoft.
Right on the XFree86 homepage, it says of the 4.0 release:
If you're looking for a stable version of XFree86, you might be better off with the latest 3.3.x release.
Now I ask you this: isn't this supposed to be a stable release?
Chris Hagar
"The price of freedom is eternal vigilance." - Thomas Jefferson
Genius moderation going on here. A factful answer to an erroneous statement posted at a default posting level get's a overrated moderation?
As it turns out, there isn't that much support for it.
-- Erich
Slashdot reader since 1997