XFree 4.1.0 Out 171
A reader writes "After some release candidates, final XFree86 4.1.0 is out. Check it from XFree86 FTP server. Their website isn't updated yet." Check the README for more information.
This discussion has been archived.
No new comments can be posted.
XFree 4.1.0 Out
Related Links Top of the: day, week, month.
"If I do not want others to quote me, I do not speak." -- Phil Wayne
No XF86 for you! (Score:1)
:)
Re:alternative to nvidia linux only drivers? (Score:1)
Go do something useful instead of post such crap.
Re:Movies (Score:1)
Re:alternative to nvidia linux only drivers? (Score:1)
Re:not totally out yet (Score:1)
Re:Woohoo (Score:1)
Re:not totally out yet (Score:1)
Re:*BSD is dead (Score:1)
yes, you can (Score:1)
Wait. (Score:2)
Re:alternative to nvidia linux only drivers? (Score:1)
ok, i think i'm getting trolled here, but the whole world accepts the misunderstanding of freedom meaning being able to do whatever you want.
effects of creation (Score:1)
free software licensing is done to allow the copyright holder control of how the software is used, to maximise use and adoption many people use the BSD or MIT licenses or simply release the code into the public domain.
re incorporation in proprietary crap: would you rather them sell a worse product or have higher development costs? neither is productive but are wasteful of human resource.
Re:alternative to nvidia linux only drivers? (Score:1)
Re:not totally out yet (Score:2)
It didn't really say how 4.1.0 was better, besides "bugfixes" and new hardware support.
Well, hopefully it will fix the occasional system lockup I've experienced with my G400 under 4.0.3
---
Re:not totally out yet (Score:2)
If so, I'll wait for Red Hat's release.
---
Any Potato debs? (Score:2)
--
Forget Napster. Why not really break the law?
Re:Windows 2000 Server Family Myths and Legends (Score:1)
Re:alternative to nvidia linux only drivers? (Score:1)
Re:Mach 64 Render? (Score:1)
XFree86 4.0.3 does not include Mach64 render code, so there is no anti-aliasing or anything.
While XFree86 4.0.3 does not have RENDER for Mach64, CVS does. I am running right now on this laptop. Used the antialias howto on dot.kde.org [kde.org] -- everything under 8 and above 12 is antialiased, it is sweet. And since I'm on an LCD subpixel antialiasing makes small text MUCH clearer than standard greylevel antialias.
I would love to know how to turn on antialiasing for any italics regardless of size; I tried a few variations of the configuration outlined on dot.kde.org but nothing seems to work. If anyone has any success here, please let me know.
Re:Gods you fiends! Here's your changelog... (Score:1)
EEK! Mike Harris is the premier of Ontario, Canada. And also I guy I hate. Now he's working on Free Software?!?! What is the world coming to....
If memory serves there used to be a Mike Harris hanging around either FidoNet or DragoNet in the 519 area code. His .sig was always "No I am NOT the premier of Ontario".
FidoNet... Christ... 1:221/[something].77 was my point.. I forget how the addressing works now. That was YEARS ago.
Re:Where does it end? (Score:1)
n hour? That's nothing - KDE2.2alpha2 takes about 16 hours to build! (no kidding - I started it building at 12 hours ago, and it's about 3/4 done)
What the hell are you doing? KDE2.2 compiles for me in about 2 hours. That includes manually un-tarring, ./configuring, and make/make installing. QT is by far the longest compile of the lot for KDE.
This is on a Cel300 with 256M of memory and running X. On my dual 450 it takes a little more than an hour.
Re:Where does it end? (Score:1)
I'm talking about ALL of KDE2.2, but just libs and base.
I understand that. How about this list?
(yes this is the 2.1 tree, and koffice wasn't included, that is a pig of a package)
Re:Where does it end? (Score:1)
Hmm... it could be because I'm using reiserfs - I'll try a build on my ext2 partition (I've got 5 GB free on there, so it's not prob).
The Dual466 system runs reiserfs on its data drive (actually 5 6.4G IDE drives in software RAID0 under LVM) -- I know that tail packing slows down reiserfs like winter does molasses; I have that (and atime updates) turned off.
Re:Games: XFree86 with DRI, or Linux FBDev? (Score:2)
don't think there's anything wrong with including a video driver in the kernel. Tying the kernel to a desktop is another story. The Linux framebuffer console is how video should have been all along. No need to be root in order to access the display. This is probably good for security as well as stability.
I'm mixed on the issue. Drivers are drivers, this much is true. Just because they are video drivers doesn't mean they don't belong in the kernel. (Hell my nVidia card has to have kernel drivers.)
At the same time, however, I think it hampers the rate of development for newer, faster and better drivers (video or otherwise). Video drivers especially change quickly as newer cards come out. It's not like SCSI or IDE or sound or network interfaces... they all seem fairly "standard" -- Video still seems to be a fast moving target.
Re:Secret is Out! (Score:1)
Re:alternative to nvidia linux only drivers? (Score:2)
Um, not quite right...the BSD license allows people to make non-public changes to source code, and release software binary-only.
If you, the software author, don't really care if someone ships your project binary-only, and further, makes whatever changes they desire without sharing with you, then yes, the BSD license is more free. Releasing under the BSD license certainly makes more sense than releasing under the GPL, then turning your project into abandonware. Or releasing under the GPL, then giving blanket permission to do with the source as you wish.
Re:Games: XFree86 with DRI, or Linux FBDev? (Score:1)
They do if you want them distributed with the kernel source tree.
OpenVerse Visual Chat: http://openverse.org [openverse.org]
Re:Woohoo (Score:2)
Please. Extensions rule! They allow you to incorporate new features while keeping backward compatibilty. Who would have though that X would be getting a Plan9 based 2D rendering system with hardware accelleration, alpha blending, AA text, and whatnot!! Extensions made this possible.
X11 lacks a standard toolkit
Blimy, that's a feature!!!
X11 lacks high performance
Mwuhahaha, that's bullshit! My NVIDIA card is as fast as in Windows (2D and 3D), muuuuuuuch faster than in BeOS (since BeOS lacks MTRR support for AMD CPU's/chipsets and is generally AMD optimization challenged). I don't know if I should take anything you say serious these days. I have the feeling it's simply a side effect of your bitterness and/or frustration with the Be situation, seeing you call yourself "be-fan". I feel for you.
low memory use, and low latency.
Dude, my X server eats a whopping 5MB at startup. Pixmap caching and other stuff lets the process grow, but hey that's what bloody RAM is for no? As to "low latency"? Huh? This isn't audio we're talking about. If you mean "responsiveness". If X is not responsive enough for you recompile your Linux kernel with HZ = 1000 (which gives you 1ms timeslices instead of 10). I can only speak from my own experience and that is that X is smooth as Silk these days. (BTW, Make sure your X server has "SilkenMouse" enabled)
I just recorded a full 2 hour of the NBA playoffs from my BT848 card, all while happily browsing and compiling away. Not a *single* audio/video frame was dropped. Converting the Nuppelvideo file to DIVX as I type this. Gotta love it! I smell a MediaOS in the making *grin*
-adnans
Re:Woohoo (Score:2)
Simply put an extra 0 on the HZ #define line. Make sure you recompile everything (including your modules). BTW, HZ is already at 1024 for Alpha architectures. Looking forward to that becoming standard on x86 as well with 1GHZ+ boxes becoming standard and all
As for the "SilkenMouse" option, it is on by default on XFree 4.x but you can enabled it with Option "SilkenMouse" "1" in your device section.
-adnans
here you go. (Score:1)
--
Re:Games: XFree86 with DRI, or Linux FBDev? (Score:4)
Sure, if the fbdev code was accelerated "enough" and supported all the primitives for 3D and whatever else they want, then it would be easier. If or course fbdev was on all the OSes they wanted XFree86 to work on. None of that appears to be true.
Now they could divert that effort in making and extending graphics drivers from X to fbdev itself, but that would limit the OS choice and be a whole lot harder. Writing kernel code is very painful compared to writing user land code. Actually it isn't the writing that is so hard, but the debugging. My relatively few kernel modifications have taken about 4 to 5 times longer then I had guessed to debug, and I had already bumped the number up because I thought I knew how hard it would be...
Plus XFree86 is used by a lot more then just Linux, and I believe many of the XFree86 commiters are not Linux-only users (in fact the only XF86 commiter I personally know is a rabid anti-Linux zealot). So I doubt they would want to abandon support for OSes that didn't have a usable fbdev.
One small point in this arguments favor is that they have a fbdev driver, and have continued work on non-fbdev drivers.
So it seems to be the lesser of N evils to essentially have a user land device driver of inordinate complexity.
Re:Games: XFree86 with DRI, or Linux FBDev? (Score:2)
Re:Woohoo (Score:2)
1. Add a new call to set the current font, with an intelligent interface. But both this and the "old" (xlfd) call update the same internal data structures, ie you don't need to know what call was used when drawing anything.
Antialiasing just works after that, as long as copy or replace pixel transfer mode is on. Setting xor mode, etc, turn off antialiasing. This is what the much-derided MicroSoft did with their calls (they did not always support antialiasing), I see no reason X cannot do at least that well!
To support Unicode, I would make the interface take UTF-8 encoding ALL THE TIME. However there are no "errors", instead illegal sequences of UTF-8 are printed as individual bytes. This would support ISO-8859-1 encoding just fine, there needs to be 3 accented characters in a row to make it accidentally think it is a UTF-8 character.
X11 lacking a standard toolkit is a feature, just like you said. One problem with a lot of this crap being added to Xlib is that everybody says "but Qt will be adding support really soon". This does not cut it, I don't want to be forced to use Qt anymore than I want to be forced to use MFC.
Re:alternative to nvidia linux only drivers? (Score:2)
Re:Gods you fiends! Here's your changelog... (Score:1)
X on demand (Score:3)
You can have multiple X servers running, one in each virtual terminal. I have a set of scripts that automatically launch a new X server with some minimal twm setting, so as to run applications full screen: view DVI/PS/PDF documents, JPG/GIF pictures, HTML documents with embedded pictures, play games, etc. Very handy when you're in a console switching period and your preferred window manager is the linux kernel's virtual terminal facility.
In case you don't want to roll your own from scratch, I can make my scripts available on request: they work very well for me, although it would require quite a lot of work to package them into a RPM, and you'll have to dig the CVS for versions that used to work with older X setups.
Unix sucks so much.
-- Faré @ TUNES [tunes.org].org
alternative to nvidia linux only drivers? (Score:2)
Re:alternative to nvidia linux only drivers? (Score:1)
BSD is content with giving up their liberty so as long as they get that feature supported. The Linux people would rather do without than to live with a half hearted buggy release.
This is the perfect example of the free software ethos.
Re:Abusing /. to get tech-support (Score:1)
Re:alternative to nvidia linux only drivers? (Score:1)
Re:Games: XFree86 with DRI, or Linux FBDev? (Score:2)
Re:Xvideo Stuff now working with tdfx ? (Score:2)
---
What is "SilkenMouse"? (Score:1)
Movies (Score:1)
Re:Movies (addition) (Score:1)
Re:Secret is Out! (Score:1)
Easy explanation: He's a Slahdot editor.
--
SGI Flat Panel Support (Score:2)
One notable new feature of XF 4.1 (for me at least) is that it is the first release to include Alan Hourihane's work on the glint driver that supports the SGI Flat Panel + 3dLabs Oxygen VX1 combo. I've been using my flat panel with CVS XFree86 for a while now and it rocks.
Re:Do I need v4.x if my video card uses XFree86 3? (Score:2)
XFree86 4.x is actually a pretty much totally new architecture, and is faster in both 2d and 3d. It also have some really nice new features. Like the render-extension for smooth fonts, DRI for smooth 3d, seperating drivers from the server (4.x uses one server for all cards, just with different drop-in drivers).
Re:Movies (addition) (Score:2)
Re:Games: XFree86 with DRI, or Linux FBDev? (Score:2)
Re:Xvideo Stuff now working with tdfx ? (Score:2)
xawtv (bttv driver) works as well as all sortsof media players that had problems before.
Re:Movies (Score:2)
- Intel i810/i815
- Matrox Gx00
- Voodoo Banshee/3/4/5
- ATI Mach64/Rage128/Radeon
- S3 Savage
- Anything by nVidia
More information about getting XVideo to work in the context of video playback can be found here [sourceforge.net], in Xtheater's [sourceforge.net] user guide for CVS. The CVS version works quite well with nice fullscreening of AVI/ASF/MPG/VCD stuff, using XVideo to scale to your display size if you set the options... Of course, I may be just a little biasedRe:Movies (Score:2)
Re:Movies (Score:3)
Re:No XF86 for you! (Score:2)
SourceForge [sourceforge.net] is responding to requests, at least.
What I'd really like to know is if 4.1.0 works any better with a Radeon on an AMD 761 northbridge. Ever since I upgraded from a 450-MHz K6-III on a VA-503+ to a 1.0-GHz Athlon on an M7MIA, X hasn't worked. I had a 32MB DDR Radeon working on the VA-503+, so it's not a problem with the card. Apparently there's some interaction with the Radeon and the 761 (751 too, FWIW) that keeps it from working. They say you can get it to work if you kill acceleration, but that would suck colon as far as performance goes. None of the READMEs say what's different between 4.1.0 and 4.0.x, and I'd rather not download the source tarballs unless I know I can get the new version to work with my hardware. (I run an LFS [sourceforge.net] system, so building from source is no big deal.)
Re:Gods you fiends! Here's your changelog... (Score:2)
Re:Woohoo (Score:2)
Re:oh goodie (Score:3)
>>>>>>>>>
Yuck. Ugly UNIX thinking at its worst. Faster computers should allow you to do more, not devote more resources to administrative overhead.
Unix thinking? Please. Windows has generally been much worse about hardware-hungry.
And really, the basic theory is sound. As you point out, as computers get faster you can use that speed to make old programs run faster or to make new programs possible at the same perceived speed. Sure, Excel's a pig, but 99 times out of 100 I'd rather use Excel than Visicalc.
But even if you're just going to make the old programs over again with absolutely no feature improvements, it often makes sense to burn processor time to save developer time and make the software cheaper. That's why you see the rise of languages like Perl, Python, C++, and Java and the near disappearance of significant assembly work.
CPU effciency is only one of many criteria you can optimize for. And since more than 90% of computers spend more than 90% of their time idle, other things (like usability and development cost) are often more important.
Re:Games: XFree86 with DRI, or Linux FBDev? (Score:2)
Re:not totally out yet (Score:2)
Re:Woohoo (Score:2)
>>>>>>>>>
99% of the world doesn't consider network transparency a "basic feature." 99% of the world doesn't consider portability a feature. Windows GDI is more well-documented than X11.
X11 lacks such basic features as totally integrated anti-aliasing (extensions, in general, suck). X11 lacks a standard toolkit. X11 lacks high performance, low memory use, and low latency. Most people consider these to be far more important feature than the server or scientifically oriented "features" you specify.
Re:Games: XFree86 with DRI, or Linux FBDev? (Score:2)
Re:alternative to nvidia linux only drivers? (Score:2)
Re:oh goodie (Score:2)
>>>>>>>>
I never said what was the case in practice. Theoretically, UNIX is much more abstracted than Windows. Stuff like DirectX is a good example. Again, I don't say that DirectX is good or bad (I personally love it) its just a lot closer to hardware than anything in UNIX.
But even if you're just going to make the old programs over again with absolutely no feature improvements, it often makes sense to burn processor time to save developer time and make the software cheaper. That's why you see the rise of languages like Perl, Python, C++, and Java and the near disappearance of significant assembly work.
>>>>>>>>>
First, features do not necessarily cause slower more bloated code. Take QNX Neutrino as an example. Secondly, lessening the work of the developer through abstraction is a decent idea at the application level (although too often the abstraction is overkill and the performance hit is large. Take CORBA for example.) However, this thinking doesn't make a lot of sense at the OS level. The OS is largely the limiting factor in most I/O or CPU limited applications, and abstracting at the OS level creates a least common denominator effect. I don't much mind if my ICQ program is a little hefty (as long as the gain through abstraction offsets the performance hit) but if the OS causes my well-tuned 3D renderer to perform poorly, no amount of abstraction in the OS can justify it. The very reason people still use C for OS kernels is that it is almost as fast as ASM, and provides a decent amount of abstraction. Thinking that more CPU power entitles one to create more administrative overhead in the OS simply keeps the user from taking full advantage of his (often expensive) hardware. In concrete terms, if upgrading my CPU from 300MHz to 1200MHz results in a theoretical halving of rendering times, then I don't want my OS cutting in on that gain.
CPU effciency is only one of many criteria you can optimize for. And since more than 90% of computers spend more than 90% of their time idle, other things (like usability and development cost) are often more important.
>>>>>>>>
If you're CPU is 90% idle, you're wasting the power of the computer. You're also not doing video or audio editing and 3D animation.
Secret is Out! (Score:3)
Re:not totally out yet (Score:2)
No, it isn't. You should first turn your source ionto an SRPM, then compile that. If you've got the knowledge to do the compile, you've got the knowledge to know how to create packages. Check out www.freshrpms.net for some good examples of spec file tutorials.
Otherwise, wait for someone else's packages.
Re:I LIKE these updates, so there. (Score:5)
WHAT?! You mean you didn't like this week's 4 dozen incarnations of MySQL enabled MP3 playlist maintaining programs? You must be crazy...
---
We need a Web site like FileFlash's Quick Load (Score:2)
I just want the title of the program with version numbers, date, time, and links.
Do I need v4.x if my video card uses XFree86 3? (Score:2)
Re:Do I need v4.x if my video card uses XFree86 3? (Score:2)
Re:It is you who is 'full of crap' (Score:2)
Re:I LIKE these updates, so there. (Score:2)
Hmm, very good point. I think far too many people who read slashdot are under the illusion that it is a community-controled environment. It is not, has never been, and was never claimed to be.
True, Malda accepts people's opinions and input, but when it comes right down to it, (and Malda has said this many times before) Slashdot is about what Mr. Rob Malda finds interesting. He has publicly stated too many times that those who don't like Slashdot's content should just go and find another website to first-post. Like Kiro5hin.
(Oh, and the new Freshmeat design has a way that you can "subscribe" to various projects and get sent an email each time there's a new release. It's extremely handy if you just want to watch a few projects.)
Re:Woohoo (Score:2)
(And at the API level, there were no major changes in X11R6.6 - it was mostly fixing bugs and adding donations of code from Sun & DEC to implement improved non-English language support and accessiblity support for handicapped users.)
Re:not totally out yet (Score:2)
XFree86 is produced by the XFree86 Project [xfree86.org], a separate organization with different goals. The XFree86 people do release both source code and binary releases.
(This is not to say X.org & XFree86 don't work closely together - the XFree86 Project is an honorary member of X.org, which means they get all the voting rights, without having to pay the membership fees charged to the other members.)
It is you who is 'full of crap' (Score:2)
Really?
I can look at FreeBSD source code all day long.
Apple computer, under Steve Jobs has allowed the closed NeXT code AND the FreeBSD (Plus open and netbsd) to be viewed.
2 examples disproving your claim.
The GPL ensures that you cannot change the original intent of sharing the code,
Lets see:
In the linux kernel 2.0 series, you can find part of the TCP/IP stack where the BSD copyright was removed and a GPL license was instead put on. The ORIGINAL intent of the BSD code was that the license be preserved, and in this case, the GPL takes that away.
How about the Virgin webplayer? The license that shipped with the box violated the GPL and they would not release the source code.
2 examples of how the GPL does not offer the 'protection' you claim.
If you argue that the BSD license is more free, you are mistaken.
As you seem to be confused, perhaps you can understand this:
Humans are a tool using species.
Software is a tool.
The BSD license puts the rights of the human to use the tool ahead of any rights the tool has. In fact, the rights attached to the tool are associated to having the human who made the tool be remembered.
The GPL license puts the rights of the tool and how it shall be used ahead of the humans desire on how they want to use it.
I have more faith in humanity than you must have.
I perfer the freedom to choose ones path over forced servitude.
Re:please let it work on my dear old mac (Score:2)
http://www.penguinppc.org/~puetzk, you want the xserver-xfree86 4.0.1-7puetzk package.
The rest you can getfun testing (it should work, even though testing is now on 4.0.3 - ymmv, I moved on and am running pre-4.1 cvs).
or, as I said, 4.1 oughta work out-of-box, I can't see any reason his mach64/ppc fixes wouldn't be in when all the other cards I have made it.
Re:Question on brightness/contrast (Score:2)
If the driver for your chip supports gamma (not all do), you could try various gamma settings. This is not really brightness controls but might accomplish what you need.
Mach 64 Render? (Score:2)
Some restrictions are necessary for freedom (Score:2)
What you speak of is called a restriction, which means that the freedom in restricted in one form or another.
If you lived in an area such as Afghanistan, with nothing restricting guerrillas from the other side from killing you, would you consider yourself free? In order to have freedom from, say, being murdered, people need restrictions on them such that they do not murder each other. Those in charge must balance freedom and security to create an optimal symbiosis.
(Insanely long copyright duration is not balance [pineight.com].)
"Windows XP: eXtremely Pathetic." -- Anonymous CowardRe:OSS Zealots Launch FUD Attack Against Windows 2 (Score:2)
And it's not like I sacrificed anything by doing so. Linux (Mandrake to be precise) works perfectly in the firewall/router/NAT role its in. Probably much better than W2K server would in fact considering the hardware I'm running it on.
Re:I LIKE these updates, so there. (Score:5)
Re:Secret is Out! (Score:4)
You'd think that, having been around for so long, he'd know better.
Re:Bastards! (Score:2)
Newest DRI (CVS) or...? (Score:3)
So my question is: How new are the DRI drivers included in 4.1.0? Should I assume they're the current CVS from the DRI project? Could someone please verify this before I destroy my current drivers?
Thanks!
Re:Newest DRI (CVS) or...? (Score:2)
If you back up...
/etc/X11
/usr/X11R6
You should be fine if the upgrade nukes X; just delete the directories and restore your backups. So far, official releases have worked well though awhile ago the DRI daily releases haven't.
FTP mirrors (Score:5)
ftp://carroll.cac.psu.edu/pub/XFree86
ftp://ftp.cs.umn.edu/pub/XFree86
ftp://download.sourceforge.net/pub/mirrors/XFree8
ftp://ftp.freesoftware.com/pub/XFree86
ftp://ftp.infomagic.com/pub/mirrors/XFree86
ftp://mirror.sftw.com/pub/XFree86
ftp://phyppro1.phy.bnl.gov/pub/XFree86
ftp://ftp.rge.com/pub/X/XFree86
ftp://ftp.valinux.com/pub/mirrors/xfree86
Not every release is news! (Score:2)
__
Question on brightness/contrast (Score:2)
I have gone through a number of docs and searched google, but nothing seems to be there. So if/when your answer is the usual RTFM, please let me know which FM.
--
I hit the karma cap, now do I gain enlightenment?
Re:alternative to nvidia linux only drivers? (Score:2)
Re:Mach 64 Render? (Score:2)
I LIKE these updates, so there. (Score:2)
"What is this, Freshmeat or Slashdot?"
"How is this news? This is just a point release."
"This isn't news, this is software."
"This is only for Linux users."
"Even Linux users don't care much about this."
Well, I for one THANK Slashdot for letting me know. I like to be informed when 2.4.next is out, and the same goes for XFree86 4.next. Some people may be bugged by it, but I think Slashdot strikes a nice (if tricky) balance between overcovering software releases and keeping a large portion of their readers (Linux users) up on the latest.
I don't like reading Freshmeat. Too much crap when all I care about is really Kernel and XFree86 most of the time. I check into Slashdot once a day or so, so I'm glad slashdot lets me know when new stuff is out. Saves me from having to wade through Freshmeat, monitor the kernel mailing list, continually check the XFree86 Web site, etc...
I also like the distribution release announcements that are here sometimes.
So nyaaaaaaaah!
Re:Movies (Score:2)
Re:Games: XFree86 with DRI, or Linux FBDev? (Score:2)
While I don't have much experience with other unices, I do believe that there is a concept of a framebuffer in most other variants. I heard somewhere that Linux was the one of the later OS's to get such a thing.
As for GPL issues, aren't there ways to load closed source kernel modules? They could be distributed "precompiled" for various kernel versions, or some sort of wrapper module could be compiled and linked against a closed source driver.
-Justin
Games: XFree86 with DRI, or Linux FBDev? (Score:4)
Currently, I feel the best way to play a full screen game is in a virtual terminal under fbdev rather than through X, so that I can keep my desktop and the game separated. Ctrl-Alt-F3 takes me to my game, and Alt-F7 takes me back to X. Plus, the high-resolution framebuffer console is very cool just for shell usage too.
Unfortunately for me though, the XFree86 driver for my card clashes with the framebuffer driver from the kernel. So in order to have my super-cool framebuffer console *and* X, I have to use the fbdev version of X. This works and all, but it is unnaccelerated which means I can't do much. Fortunately, most of the games I have are SDL based, so I can just flip to a console to play. But something like OpenGL? Not a chance.
Now can anyone explain to me why there are two video drivers on my system to clash in the first place? It seems logical to me that everyone should use a framebuffer driver (I have a Voodoo3, and it is supported in the kernel) and that X should ride on top. The kernel has every other driver, so why is the video driver so special that X has its own?
Wouldn't it be easier for the XFree folks if they didn't have to worry about making video drivers, and instead it was all taken care of by the kernel? IMO, the only driver they should develop is the fbdev version.
Anyone else have any insights to this? Any reason why DRI couldn't be applied to an fbdev Xserver?
-Justin
Re:Movies (Score:2)
Re:Gods you fiends! Here's your changelog... (Score:3)
570. Add euro locales and some other missing locales to locale.alias and locale.dir (#4662, 4665, 4667, Mike Harris). 569. Fix Romanian XKB map (#4664, Mike Harris). 568. Spell Portuguese correctly in XKB lst files (#4663, Mike Harris).
EEK! Mike Harris is the premier of Ontario, Canada. And also I guy I hate. Now he's working on Free Software?!?! What is the world coming to....
--Volrath50
Re:Secret is Out! (Score:2)
Gods you fiends! Here's your changelog... (Score:5)
Recent Changes to the XFree86 4.1 branch
Below is a recent extract from the XFree86 change log for the 4.1 branch. The full change log can be found in the XFree86 source tree (xc/programs/Xserver/hw/xfree86/CHANGELOG).
XFree86 development code can be accessed directly from the CVS repository. Information about this can be found on our CVS page.
XFree86 4.1.0 (2 June 2001)
619. Disable PCI resource conflict checking for Linux/Alpha (Jay Estabrook).
XFree86 4.0.99.902 (1 June 2001)
618. Fix Linux xf86GetPciSizeFromOS() parsing when the kernel is 64 bit
and any base or size is larger than 32 bits in magnitude (#4732,
David S. Miller).
617. Make XDarwin ddx pass up proper right and middle mouse button numbers
and fix mouse button 5 (Christoph Pfisterer and Torrey T. Lyons).
616. Restore backwards compatibility from 4.0.[2,3] to 4.1.0 for
the i810, r128 and radeon DRI drivers (Gareth Hughes).
615. Fix a problem when using patterns of horizontal lines with the mga
video overlay (#A.442, Ewald Snel).
614. Xinstall.sh updates and bug fixes (David Dawes).
613. Remove duplicate XineramaLibrary section in X11.tmpl (#4731,
Mike Harris).
612. Enable building DRI for Linux/ppc, and fix a drm-related bug
for Linux/ppc (#4728, 4730, Michel Dänzer).
611. Document Options for the r128 and fbdev drivers (#4727, 4729,
Michel Dänzer).
610. Add a BuildBindist switch which causes a file containing the XFree86
version number to be installed in ProjectRoot, include this in
the Xbin bindist tarballs, and turn on this switch in the bindist
host.def files. The purpose is to allow the installer script to
easily identify which version the bindist tarballs are (David Dawes).
609. Resync bindist and Xinstall.sh with changes made for 4.0.3 (David Dawes).
608. Fix the Shape extension's XShapeCombineMask to handle cases where
src_mask is None according to the spec. This reportedly fixes an
X server crash (#4715, Huver).
607. Make sure -UXF86DRI is after -DXF86DRI when compiling vfb/miinitext.c
(#4714, Frederic Lepied).
606. Fix ATI Radeon driver on Alpha. Seems as though the BIOS doesn't
like Re-POSTing and memory setup gets confused. (Jay Estabrook, Jeff
Weidemeier)
605. Fix build for Cygwin/XFree86 (#4711,#4713 Harold Hunt).
604. Fix problem with Xinstall.sh on Darwin 1.3.x (#A.431, Stefan Pantos).
603. Update Xinstall.sh and Darwin bindist directories to optionally
install Quartz support and to add an x86 distribution (Torrey T. Lyons).
XFree86 4.0.99.901 (29 May 2001)
602. Add missing return value for miSetPixmapDepths() (#4708,
ISHIKAWA Mutsumi).
601. Fill in the v4l man page template with some useful information (#4707,
Gerd Knorr).
600. Fix FFB OpenGL SwapBuffers (#4705, David S. Miller).
599. Work around a problem building the rstart specs doc with a symlinked
build tree (David Dawes).
598. Remove SPARC-specific byte-swapping code that would not work on older
SPARC CPUs (part of #4653, David S. Miller).
597. NULLify mapVidMem() and remove DEV_MEM #define for Linux/SPARC
(#4651, David S. Miller).
596. Fix Glint 300SX+Delta support. Add faster 500TX text acceleration
based on other code (Alan Hourihane).
595. Fixing MTRR split code (hopefully) (Egbert Eich).
594. Fixing coredump when doing vbeFree() twice: S3 Virge and C&T
(Egbert Eich).
593. Fixing HWCursor for mga driver in fbdev mode (Egbert Eich).
592. Fix xmh's use of XtNewString() with getenv (#4694, Tim Waugh).
591. Xdm/PAM fixes: leave it to PAM to observe whether or not an account
is locked, and reinitialize credentials after calling initgroups(),
because sometimes the credentials pam_setcred() gives are in the
form of group membership (#4693, Mike Harris).
590. Add an encodings file for standard box drawing characters for
VT100-compatible terminals (#4691, Juliusz Chroboczek).
589. Fix warnings when building mieq.c (#4689, Adam Sulmicki).
588. Fix some bugs in the cz and sk entried in XKB's keymap/xfree86 file
(#4692, Ivan Pascal).
587. Add 'hr' entries to XKB's keymap/xfree86 and rules/xfree86.lst files
(#4687, Nerijus Baliunas).
586. Include in shape.h to get Region typedef (#4686,
Adam Sulmicki).
585. Acceleration fixes for GLINT Permedia1 (Alan Hourihane).
584. Ensure glint driver chips don't exceed the specified virtual sizes.
(Alan Hourihane).
583. Remove all VGA'isms from the glint driver, it doesn't need them
(Alan Hourihane).
582. Support the Delta in the glint driver, needed for boards that have
the Delta connected to the rasterizer, as it acts as an arbiter for
the bus. Resolves acceleration troubles. (Alan Hourihane).
581. Add an lv entry to XKB's keymap/xfree86 file (#4685, Nerijus Baliunas).
580. Fix some typos in XKB's xfree86.lst file (#4684, Nerijus Baliunas).
579. Add DDXOSVERRORF ifdefs to the XFree86 ddx code that make use of the
OsVendorVErrorFProc feature (#4678, Michel Dänzer).
578. Convert the r128 driver's "UseBIOSDisplay" option into a more general
"Display" option (#4678, Michel Dänzer).
577. Treat GL_POINT like GL_POINTS and GL_LINE like GL_LINES in the sunffb
DRI driver (#4677, David S. Miller)
576. Fix bsdLib.rules and bsdLib.tmpl problems that show up when
X11ProjectRoot is defined (#4676, Johnny C. Lam).
575. Fix Trident XVideo colorkey at depth 15, 24 (Alan Hourihane).
574. Fix a typo in the lv XKB description, and fix things so that it gets
installed (#4675, 4679, Andris Pavenis).
573. Fix some apm driver bugs, including one that prevented acceleration
from working (#4674, Loïc Grenié).
572. Fix 555 (depth 15) palette handling in the i810 driver (#4673,
Andrew C. Aitchison).
571. [SECURITY] Fix authentication issues with mmap() on drm devices
(Jeff Hartmann).
570. Add euro locales and some other missing locales to locale.alias and
locale.dir (#4662, 4665, 4667, Mike Harris).
569. Fix Romanian XKB map (#4664, Mike Harris).
568. Spell Portuguese correctly in XKB lst files (#4663, Mike Harris).
567. Fix new ioperm calls in lnx_video.c for Alpha that are not needed
(Jay Estabrook).
566. Fix problems with assembler file dependencies when using gccmakedep
with the build (Frederic Lepied).
565. Finish DRI resync, including tdfx driver updates for textured video
support (VA Linux Systems).
564. Fix formatting of max clock reported by DDC (Marc La France).
563. Update Japanese localization of XDarwin help file (Toshimitsu Tanaka).
562. Update XDarwin man pages, help files, and version info. Add option to
build XDarwin.app bundle for deployment (Torrey Lyons).
XFree86 4.0.99.900 (18 May 2001)
561. Add an XKB description for Latvian (lv) keyboards (#A.411, Ilya Ketris).
560. Resync with DRI CVS trunk (VA Linux Systems).
559. Savage driver updates, including compiler warning fixes, document
the "ShadowStatus" option in the man page, and fix an argument
mismatch between ShadowWait and SavageWaitQueue (#4661, Tim Roberts).
558. Update the wacom driver to add a "ScreenNo" option to allow a tablet
to be attached to a screen in a multi-head setup, and to add auto-
detection of USB line and max parameters of USB tablets (#4640,
Frederic Lepied).
557. Add a README file that has information about enabling the extra buttons
on the IBM Rapid Access keyboard (#4639, Dennis Bjorklund).
556. Fix some Slovene/Slovak confusion in locale.dir/locale.alias files
(#4638, Kamil Toman).
555. New XKB keymaps for cz and sk (#4634, 4637, Kamil Toman).
554. Updates for the iso8859-2 Compose file (#4634, Kamil Toman).
553. Check V_CSYNC in the r128 driver, and fix building with R128_DEBUG
enabled (#4631, Michel Dänzer).
552. Mesa 3.4.2 (and later) import.
551. More build & warning fixes (Marc La France).
550. Fix bug that caused hardware cursors to be temporarily moved during mode
switches (Marc La France).
549. Optimise HARDWARE_CURSOR_AND_SOURCE_WITH_MASK case (Marc La France).
548. Move xf86CursorScreenRec definition into xf86CursorPriv.h
(Marc La France).
547. Fix BIOS retrievals in MGA driver (Marc La France).
546. Fix ATIProbe() for newer Rage128 and Radeon chips (Marc La France).
545. Add temporary workaround in ATI driver for interrupts that occur on
PowerPC's upon PCI master-aborts (Marc La France).
544. Update XDarwin to use fb and support Render (Torrey Lyons).
543. Back out sunleo conversion to fb. This driver is too heavily dependent
on cfb32 for a simple fb conversion (Marc La France).
542. Miscellaneous build/warning fixes (Marc La France).
541. More prep work for SunOS (Marc La France).
540. Fix libXft build on SunOS (Marc La France).
539. Another makedepend bug fix (Marc La France).
538. Fix use of xftcache utility during !UseInstalled builds (Marc La France).
feast and enjoy.
-bacchusrx.
Xvideo Stuff now working with tdfx ? (Score:2)
Re:Any Potato debs? (Score:3)