XFree86 4.0 Now Available 428
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.
Ya but... (Score:1)
Mirrors (Score:2)
http://canadia.geecs.org/~mp3/xfre e86-4.0.tar.gz [geecs.org]
What kind of 3D support? (Score:2)
-Davidu
Re:Ya but... (Score:2)
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.
Small makedepend problem with Debian/woody (Score:5)
Running it now. Mozilla actually looks right, the menu fonts are the correct size. Woohoo!!!
Mmmm... (Score:1)
Congrats! (Score:2)
"If ignorance is bliss, may I never be happy.
Re:Ya but... (Score:1)
Anyway, I spoke to Head engineer from Nvidia, Nick, and he said that they'll be out very shortly (if they're not out already), and that they'll "kick the snot out of anything out there"..
i can't believe finally i will have 3d support! This better be for real! Thank you! Ok i'm gonna go get crazy somewhere
Mike Roberto
- roberto@apk.net
-- AOL IM: MicroBerto
Release Notes (Score:5)
http://www.au.xfree86.org/4.0/RELNOTES. html [xfree86.org]
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?
Re:Ya but... (Score:2)
Looks like it's pretty much just 3dfx cards now...
Fast Mirror at SourceForge (Score:5)
ftp://download.sourceforge.net/ pub/mirrors/XFree86/ [sourceforge.net]
---
SourceForge Programmer Type - http://sourceforge.net
Support for multiple displays (Score:1)
SGI 1600SW (Score:1)
Has anyone used any of the pre-4.0 snapshots on an SGI 1600SW w/ the Number Nine TTR IV? Im considering buying one, and was wondering if anyone had had any problems with it?
RPM? the common question.. (Score:2)
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
wahoo! (Score:1)
rbf aka pulsar
AHHHH! (Score:2)
I'm setting a low limit on apache, so my appologies if you have trouble connecting.
thanks!
Re:RPM? the common question.. (Score:1)
while you're at soul.apk.net, you can check out my wakeup program! its an mp3 alarm scheduler, with some cool new options. http://soul.apk.net/wakeup/ [apk.net]
Mike Roberto
- roberto@apk.net
-- AOL IM: MicroBerto
We have been tricked! (Score:3)
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.
Re:Ya but... (Score:2)
-- BLarg!
Our mirror: soul.apk.net (Score:5)
enjoy until we get slashdotted!
Mike Roberto
- roberto@apk.net
-- AOL IM: MicroBerto
Re:SGI 1600SW (Score:1)
On a side note, now that you mention it, I am eagerly awaiting the time to set up 4.0 on the 320 and see if it works for me!
cool! (Score:3)
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
but you can kiss your Freedom goodbye. (Score:1)
The nvidia drivers are going to be binary only. In fact, new 3.9.x drivers are coming out of ATI and 3DFX as binary only too. I'm sure matrox won't be far behind.
It won't be long until the day we are wishing back to the breif time we could completely debug, support, and repair the complete software systems of our personal computers, while still using cheap main-stream hardware.
Oh well.
This is Great !!! (Score:2)
RH6.2? (Score:1)
Will it break anything requireing Xlib & Xt? (Score:2)
i'll bet... (Score:1)
Re:but you can kiss your Freedom goodbye. (Score:1)
Why video card manufacturers don't like people doing free work for them, I don't know.
Alpha Transperancy (Score:5)
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?
Re:RPM? the common question.. (Score:2)
--
canadia.geecs.org dies of xf86-4.0 effect (Score:2)
Re:Support for multiple displays (Score:3)
treke
It does look damn cool.. BlueHeart! (Score:3)
FTP client/server timezone skew (Score:5)
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.
Re:Will it break anything requireing Xlib & Xt? (Score:2)
The error in Netscape was something to do with locale's in Xlib. Hopefully these errors have been sorted out by now.
Re:Support for multiple displays (Score:2)
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.
Re:RPM? the common question.. (Score:2)
>RPM's!
Just check the SuSE or RedHat mirrors of their ftp sites. They they should be poping up in a couple of days.
Stop hitting ftp.xfree86.org! (Score:5)
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 [xfree86.org]
SlashMirror (Score:3)
just replace 'source' directory with 'dasource'
SlashMirror: Where to put files for fellow /.'ers
The begining of the end for Linux. (Score:4)
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.
Re:but you can kiss your Freedom goodbye. (Score:2)
Matrox dosn't make its own drivers, they just put out the specs.
[ c h a d o k e r e ] [dhs.org]
Re:Alpha Transperancy (Score:2)
-- Thrakkerzog
Re: Kernel driver (Score:2)
Netscape fonts (Score:5)
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 [mit.edu]
(go to the bottom of the page)
Re:Screen Shots of Cool Features? (Score:2)
-- Thrakkerzog
Re:Screen Shots of Cool Features? (Score:2)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:Alpha Transperancy (Score:2)
Evans and Sutherland has a graphics card that supports overlays in openGL, and that they seem to indicate that they now have Linux support (nice to see Tux on their web site). But their card costs about $500. Additionally, xig also has indicated that they have openGL overlay support for some selected graphic cards.
I can't remember the guy's name, but in the opengl/X book their is code to check if transparency/overlays is supported. IIRC, one program is call sovinfo (X) while the glut example is dino(something). Overlays are not supported for all the graphic cards that I have tried.
I also want an answer to your question.
Re:I'll be kissing Nvidia goodbye telling them to (Score:3)
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
Fast EDU Mirror (Score:3)
ftp://inept.rh.rit.edu/pub/XFree86-4.0/
Re:SGI 1600SW (Score:2)
Unlikely, given that the Number Nine section of the driver status document [xfree86.org] says:
The release notes [xfree86.org] 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.
I don't follow this argument (Score:5)
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
Re:Alpha Transperancy (Score:2)
What this means is that you can somehow specify an image, get it drawn, and some of the pixels contain a mixture of what the pixel contained before and the values from the image. Usually this is controlled by the "alpha" channel of the image.
This alpha from the image can (and usually is) thrown away. You can also do useful things by storing it, much like a Z buffer, but the only one I know is a hack so that anti-aliased polygons may be drawn and they cover the pixels 100% where they join.
"Overlay" hardware is, IMHO, not very useful on modern fast computer systems. Only limited graphics can be drawn in it (or if the graphics are unlimited, all that memory would be better used for Z or accumulation or alpha buffers!).
Re:To my knowledge (Score:2)
Re:I'll be kissing Nvidia goodbye telling them to (Score:2)
There is an article on Tom's Hardware Guide [tomshardware.com] that does a bechmark [tomshardware.com] 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 [tomshardware.com] pretty well sum it up. The GeForce is about 25%-30% faster than the other cards.
How soon till RPM? (Score:3)
NH
So... (Score:2)
Hey, you can always stick with 2 revisions back + updates. I'll take my chances with the fun stuff.
---
(ot) ((and slightly inebriated)) (Score:5)
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)
--
Re:but you can kiss your Freedom goodbye. (Score:2)
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.
Re:So when will we see DRI NVIDIA drivers? (Score:3)
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
Re:Screen Shots of Cool Features? (Score:2)
XFree86 Mirrors (Score:3)
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
Re:The begining of the end for Linux. (Score:2)
I am as concerned as you about the ever-advancing march of closed-source graphics drivers. I currently make my living writing graphics drivers for BeOS [be.com] and, even with a signed NDA, a lot of times it is like pulling the eye teeth of a moose on PCP to get any kind of documentation out of these guys (assuming they'll talk to you at all (HEY! NeoMagic!! You trying to get left out of the Internet Appliance market? Answer your email!! )).
However, I think this is a prime opportunity for the community to establish a guideline concerning hardware purchases: If there aren't Open Source drivers for it, don't buy it.
I'm currently parts shopping for a firewall. I've already decided that the motherboard is going to be based on the Intel 810 chipset. I could probably get a board based on a different chipset for cheaper. My decision was based not on price, but on the fact that Intel released complete programming docs for the I810 [intel.com]. And they're good docs, not just a list of registers with terse descriptions. This made my job writing a BeOS driver for it a lot easier.
I wish to support this behavior with my dollars, so I'm getting an I810-based board. I would encourage others to consider such a philosophy. You may have to forego a few FPS in Quake[123], at least until the guilty vendors choose to see things differently. But by that time, the card will be cheaper, anyway, so you'll save a few bucks in the bargain :-).
Schwab
Is this too early? (Score:2)
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...
Look at Creative (Score:5)
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.
Re:Alpha Transperancy (Score:2)
I think there are two related things here:
- blitting images with an alpha channel onto a drawable. This is easily enough done on the client side (albeit likely slower, since it would be a 2-step process: blending the images on the client side, then displaying on the server. Even with shared images. If you had direct access to the framebuffer, that's different, but that sort of defeats the purpose of a windowing system, right?)
libart (used by gnome) does alpha blending of images on the client side, then renders to the display. Among other neat things.
- having the server automatically manage translucent windows. This would really *have* to be in the server. Windows 2000 does exactly this: you provide an image with an alpha channel, "apply" it to the window, and the window manager (server, in X-terminology) does all the compositing seamlessly. And video drivers can provide optimizations for it (at least they will eventually).
This is a good solution for the task at hand (having translucent objects on the display that can overlap other windows without the other window knowing about it), but it's hardly a general purpose compositing/rendering model like MacOS X has (via DPS). Translucent windows would be cool, but I want drop shadows on my windows! I want to be able to hook in arbitrary effects to the rendering pipeline! And other neat stuff! Simple (or not-so-simple) server side alpha "layer" management would be cool, but wouldn't quite cut it, imo.
You're right, but... (Score:5)
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.
No OpenSource 3D for NVidia (Score:3)
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.
The death of Linux has been greatly exaggerated... (Score:5)
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!
berlin has transperancy, +other cool shit! (Score:2)
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!
Re:3D acceleration for ATI chipsets? (Score:2)
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 [sourceforge.net] for more info.
Re:I don't follow this argument (Score:2)
G400 dualhead soon (Score:2)
http://www. matrox.com/mga/press_room/lat_press_rel/matroxg400 _linux.htm [matrox.com]
Dualhead is announced for soon, although their site isn't very informative.What about anti-aliased fonts (Score:3)
--
Re:RPM? the common question.. (Score:2)
It'll be interesting to see which of the major distros/vendors is first out the door with usable rpms. Given that this is such a major release of such a major piece of software, I would of thought that it would be in the interests of the vendors to get some good PR within the community by being first to market.
Still, best to get it right, I guess.
I am still suprised no one is putting effort in to getting rpms out of the mozilla milestones.
Tangent: Been a good few days for major releases, no? I'm enjoying Helixcode (and just wait 'til other people start creating other interesting "mini distros" with helix-update) at the moment, beta Crypto Moz has hit the streets, and now xf4. Woo!
...j
Re:The begining of the end for Linux. (Score:2)
Letting this new breed of proprietary drivers out of the bag is not the same as havering the old proprietary drives. The old drivers were just engendering tools to get what we wanted to the screen. The new drivers are Content and access control devices, intended to give companies power over what we can create and program as well as what we can speak and write.
XFree please join us in supporting freedom and protecting our rights under copyright law. Please join the good fight for the long term instead of taking a victory that is hollow.
In Service
Charles Puffer
Re:No OpenSource 3D for NVidia (Score:4)
1. GL_SWAP_BYTES fails when loading textures. This has forced me to either:
a) make a copy of the texture, perform the endian conversion, load the texture and then free the texture-a significant speed hit
b) Load the texture as GL_AGBR_ext, which is not cleanly supported across all implementations of OpenGL
2. Reads from the framebuffer fail. I've tested this several times, under multiple applications including glQuake and my own engine.
3. The driver reports that SGIS_multitexture is supported in the extensions string. All calls to the SGIS functions result in a segfault. This has been tested in multiple applications, including glQuake and my own engine.
In summary, the commitment by NVidia to Linux has been nothing more than lipservice. I specifically purchased a TNT2 because it was supported under Linux. Had I known that the GLX support was so incomplete, I would not have purchased that card. I have emailed NVidia about these issues, but I have neither received a response, nor have the issues been addressed.
Re:FreeBSD 3D acceleration (Score:2)
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.
Welcome to Moderator Wars! (Score:2)
---
Re:I'll be kissing Nvidia goodbye telling them to (Score:2)
Re:but you can kiss your Freedom goodbye. (Score:2)
Re:(ot) ((and slightly inebriated)) (Score:2)
Re:Absolutely not :) (Score:2)
If you have the hardware that is supported, then 4.0 would probably be an improvement over the 3.3.x versions.
Re:The begining of the end for Linux. (Score:2)
Re:So when will we see DRI NVIDIA drivers? (Score:2)
Where do these stupid and immature suggestions come from?
First error output (Score:2)
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
Bollocks (Score:2)
Re:What about anti-aliased fonts (Score:4)
But that's not the real problem with Windows and font smoothing (even MS don't have the gall to call it "anti-aliasing").
The problem is that Windows doesn't smooth the fonts that really need smoothing - those at 10pt and below. Smoothing 72pt fonts, while it makes your PowerPoint slides look nice, isn't really all that important. To reap the real benefits of anti-aliasing (deceive the eyes that there's more spatial information than there really is) you need to anti-alias the small fonts. But smoothing looks very sucky at small point sizes, but it's relatively quick, which I guess is why most fonts on Windows don't smooth below about 10pt.
There's only one OS that I'm personally aware of that has ever done The Right Thing in anti-aliasing, and that was RISC OS on the Acorn Archimedes series of computers. That knew about proper sub-pixel antialiasing, and you could tune it quite precisely.
ClearType is more like "real" antialiasing, and I can't for the life of me work out why they didn't put it into Windows 2000.
But that's by the by. You asked about Linux. I don't think antialiasing fonts should be too much of an issue, at least at first. I think that having well hinted fonts, so that all three legs of a 12pt lowercase m only have one pixel each with 1 pixel spacing *every time*, for example, makes for better display. Poorly hinted fonts don't anti-alias well, either. (Although it has to be said that if you don't have any well-hinted fonts on the page, then the badly hinted ones tend to look OK when anti-aliased, at least until a decent font turns up:)
An example of badly hinted fonts is the URW-Fonts collection. They print fine, but they render grim.
The problem with the X font rendering code (and I just *know* I'm gonna get corrected here) is that it can't deal with glyphs as anything but bitmaps; that is, black'n'white. I understand that it would be a considerable rewrite to provide AA support in X.
--
Re:Oh PULease.... (Score:3)
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's drivers will be out soon. (Score:2)
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.
Re:What about anti-aliased fonts (Score:2)
How is this "Funny"? (Score:2)
Chris Hagar
Run, DO NOT WALK, and upgrade!! (Score:2)
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 don't think that was his meaning (Score:2)
Chris Hagar
Bad releasing (Score:2)
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
Re:Ya but... (Score:2)
Re:First error output (Score:2)
The fonts look a lot better in netscape anyway!
And Solaris (Score:2)
As it turns out, there isn't that much support for it.
Re:Bollocks (Score:2)
gnome-canvas is the correct place to do it. The only reason people want to have xserver alpha, is so fancy effects like win2k's fading menus, or Aqua's see-through dialogs can be done.
The way to do alpha is to work out what is below the place where you want to draw the png, and combine the two. Mozilla knows what is below the png, it knows the png, it can trivally(*&**) put the 2 things together for alpha.
Depending on X for alpha support seems more platform dependant than Mozilla doing it itself.
(*)Trivial if you know the Moz source, and c++
(**)"Anything I can't do must be simple" (PHB in Dilbert)
Re:(ot) ((and slightly inebriated)) (Score:2)
Thanks
(Posted at 2 to annoy whiners)
--
Re:Bollocks (Score:2)
(I did read the link, I got bored of it half way through)