Slashdot Mirror
XFree86 4.0.1 Released
Alphix writes: "The first update to XFree86 4.0 has been released, a ton of bug fixes etc and a merge of new DRI code along with SPARC fixes should be enough to warrant an upgrade =). patches are here, source is here. Sourceforge and other mirrors should have it soon."
However, Branden in May did announce that he would be releasing the binary packages for XFree86 4.0.1 during this month. If you're a Debian user who's hoping for the Debian packages for XFree86 4.x, then I'd advise you to read the plans Branden has for XFree86 4.0 packaging.
-- "I can't tell the future, I just work there." -- The Doctor
>that i'm not too happy with the state of XFree86
>4.0. Primarily because there's a lot of support
>that was left out.
The alternative being not releasing it so that people who DO have supported chipsets can use it?
>Particularly on most 3dfx chipsets. Sure, it says
>all 3dfx chips are supported, but that's
>laughable.
The DRI drivers are being done by 3DFX, so they're the ones that you have an issue with, not the XFree86 team.
It is also worth noting that the drivers are specifically mentioned in the FAQ to be beta quality at this time.
>Perhaps 4.0 was build up quite a bit more than
>it should have been - but it comes down to the
>fact that this wasn't really a next-gen release.
Ummm, a new codebase (X11R6.4), more protocol extensions (can we say Xinerama?), a re-enginnered direct rendering interface, integration of a font server and OpenGL software renderer, a binary loader that can load drivers on any operating system under the same architechture...
This smells of major next generation release to me.
>For some people it was worth while to upgrade,
>while for others it was not.
And for almost all people it *will* be worthwhile to upgrade, once the driver base is brought up to snuff and the distributions start packaging it.
>I would have been much happier to see the folks
>at XFree86 wait a little longer to release a much
>better product.
What objections do you have to the current implementation, aside from whining that it the driver for your video card isn't finished?
Unfortunately its difficult for an unreleased product to gain a wide base of drivers, a signifigant amount of polish, and full bug testing.
>Something that everyone could upgrade to. I
>know at least 3dfx and some ATI chips got
>screwed.
Ummm, screwed? You can continue using 3.3.6 as you did before. The only people who need be affected are those that BENEFIT from the release.
And again, I must reiterate - waiting for all drivers to mature before release buys nothing. The only effect is to keep it out of the hands of the people who CAN upgrade and CAN benefit immediately.
> Unfortunately, the Xfree 4.0.1 version does not
:)
> work with our drivers. We hope to have out a
> new release for that version out shortly.
They're working so hard on the new version that they have no time for grammar!
Note: flaming nvidia won't get the drivers fixed quicker. This is just a note so that other people don't waste time trying to get the nvidia drivers to work.
Binaries and complete source tar balls comming later.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
And should be applied from the xc directory with the -p1 -E options to patch.
:)
Not the -p0 -E options as specified in the patch files.
Doesn't everyone keep the 400+ MBtyes of X source around to rebuild X when a new patch comes out ?
I've been running XFree4 for several months. On Debian. Hasn't crashed yet. Either there is no problem, or nVidia's drivers are just that much better than all the other ones. :)
The only real problem I've noticed is that copy/paste ops sometimes lock the system for a second or two, and sometimes KDevelop gets screwy (menus get slow and text gets messed up). The first problem is only a minor annoyance, and the second can be fixed by restarting the program. I don't have 4.0.1 yet, so maybe these problems are fixed. Anyone know?
For Debian users who want X4 NOW: Just use the binary installer provided by the XFree86 people. It is a completely painless process. It just asks a few questions ("do you want XYZ fonts?", etc.) and does its thing, and everything works. (at least, it worked for me)
Be careful, though. Recently, potato had an update for X3. dpkg though the thing was still on my computer, so it automagically downgraded me, which completely destroyed my whole setup. I had to re-run the X4 installer from a VC, but then everything worked again.
------
Although I do appreaciate announcements of LARGE updates to POPULAR software packages (E: Linux 2.4.0, FreeBSD 4.0, XFree86 4.0.0), I feel that posting a story everytime a tiny release of some popular package is lame. Perhaps we could have a new "software" section akin to the BSD section for discussing mildly momentous updates like this.
S3 hardware is not being dropped. It is simply a lower priority than getting DRI finished. As for people who "play" with their computers, define "play." Is it playing to develop OpenGL apps. Is it playing to do 3D animation. Is it playing to do desktop publishing. (Oh I forgot, on /. anything not related to server or database programming is "playing!") I don't buy a new graphics card every 3 months, but at least I have something more modern than an S3 (virge, etc) card. X4 is meant to imporve graphics performance. If you are a sysadmin, or a programmer that simply uses Vi or Emacs, then guess what, you probably don't need improved graphics performance!
A deep unwavering belief is a sure sign you're missing something...
Let me correct a few facts that have shown up in this thread. First, all the 3dfx boards that do 2D are supported under XFree 4.0. That means that the Voodoo Graphics and Voodoo2 are not, but since they don't use the X server at all they don't need any special support to run under X.
2D performance of the 3dfx boards is much better under 4.0 than it was under 3.3. The new architecture of 4.0 and the release of 3dfx specs allows the server to run much better.
3D performance is a more complicated matter. I suspect this is where people are complaining. The DRI is a new architecture and it has somewhat different goals than the hack I put together for doing 3D under 3.3. It is designed to run multiple applications, in a window, reliably, and securely. Those extra features do take a toll on performance. Our goal for 4.0 was always to make it work correctly before worrying about the performance. We've just gotten to that point and are now putting some attention on performance. I've made some substantial improvements in the last week, that will be showing up in 4.0 soon.
Finally, Precision Insight and now VA Linux Systems is doing he 2D and 3D work for 3dfx. That work is being done primarily by me. I also did most of the 2D and 3D work under XFree 3.3. (I did have some good contributions by few other developers) So mostly the same people are doing the 3.3 work and 4.0 work. It both cases it was done mostly by a very small group (less than 3) contributors.
The XFree 4.0 support for 3dfx boards is far from laughable. It's one of the best boards supported under 4.0. XFree 4.0 had ambitious goals and we've done a remarkable job pulling them all together. Is the job complete? No. It is running nicely for a lot of people? Absoltely. If you'd like to see it improve then quit complaining and contribute code or bug reports.
- |Daryll
4.0.1 is more significant than a "tiny release". 4.0 was a long-awaited release, but many users have not upgraded because of stability concerns. 4.0.1 is, for most people, more significant than 4.0 was, because it's finally ready for them to use. Once 4.x is stable, I'd agree with you that tiny releases aren't newsworthy.
From the diff:
+2. Summary of new features in 4.0.1.
+2.1 X server
+
+ o New DRI drivers for Intel i810, Matrox G400 and G200 (AGP only) and the
+ ATI Rage 128, and updates to the 3Dfx DRI driver, including Voodoo5 sup-
+ port.
+
+ o The X server now runs on Linux/Sparc including drivers for many video
+ cards used on SUN hardware.
+
+ o DRI support for the Linux/Sparc implementation that allows 3D direct
+ rendering with Creator3D cards.
+
+ o Fixed recently publicized security issues.
+
+ o Update Mesa to the latest version.
+
+ o Xinerama updates and fixes.
+
+ o Xv updates and fixes.
+
+ o Mouse support in DGA 1.0 compatibility mode should now work correctly
+ for most games that make use of it.
+
+ o Some bugs with 8+24 overlay support have been fixed.
+
+ o Some XKEYBOARD extension problems have been fixed, including improve-
+ ments to the MouseKeys support.
+
+ o Add generic DGA support to the sis, neomagic and i810 drivers.
+
+ o xf86cfg, a new graphical configuration tool.
+
+2.2 X libraries and clients.
+
+ o Thread safety issues have been resolved in a few places in the
+ libraries. Upgrading to the latest libraries is essential for multi-
+ threaded X applications.
+
+ o Some fatal bugs in the big font support have been fixed. Upgrading to
+ the latest libraries will fix this too.
+
+ o Fixed recently publicized security issues in some of the X libraries.
+
+ o Updates and bug fixes for some clients, including xedit, xman, xcalc,
+ fstobdf, xdm.
+
+ o Fix some xfs problems.
+
+ o XTerm updates. These include:
+
+ o Improve logfile security.
+
+ o Workaround for fixed fonts which are generated from Unicode fonts:
+ they omit glyphs for some xterm's less-used line-drawing charac-
+ ters, which caused xterm to set a flag telling it to use only its
+ internal line-drawing characters.
+
+ o Limit numeric parameters of control sequences to 65535 to simplify
+ checks for numeric overflow.
+
+ o Change index into UDK list to unsigned to guard against numeric
+ overflow making the index negative.
+
+ o Add limit checks to ClearInLine(), ScrnInsertChar(), Scrn-
+ DeleteChar() to correct potential out-of-bounds indexing.
+
+ o Add a resource (limitResize) limiting resizing via the CSI 4 t and
+ CSI 8 t sequences.
+
+ o Ignore out-of-bounds resize requests, i.e., where sign-extension or
+ truncation of the parameters would occur.
+
+ o Change Sun function-keys resource name to sunFunctionKeys to work
+ around redefinition of the token sun by xrdb on Solaris. Simi-
+ larly, renamed resource sun keyboard to sunKeyboard. Change simi-
+ lar resource names for HP and SCO to avoid potential conflict with
+ xrdb symbols on other systems, as well as for consistency.
+
+ o Change line speed from 9600bd to 38400bd to accommodate users who
+ mistakenly use $TERM set to vt100, to reduce the effect of padding
+ associated with this terminal type.
+
+ o Fix a problem that caused the right scrollbar to be positioned
+ incorrectly when re-enabling it.
+
+ o Fix a problem with color support that showed up on some platforms.
+
+ o Modify logic for deleteIsDEL resource so it has internally 3
+ states: unspecified, true and false. If unspecified, the keyboard
+ type determines whether the Delete key transmits <esc>[3~ or \177,
+ and the popup menu entry reflects the internal state. Otherwise,
+ the popup menu entry overrides the keyboard type.
+
+ o Portability fixes for os390, AIX 4.2, Digital Unix 4.0 and IRIX
+ 6.5.
+
+2.3 Fonts and Internationalisation
+
+ o Many of the "misc" bdf fonts have been updated and extended, and a wider
+ range of ISO-8859 subsets have been added. Oblique/italic versions of
+ some of them have also been added.
+
+ o The converters in Xlib have been improved and reworked. UTF-8 support
+ has been added.
+
+ o Support for ISO-8859-13 has been added to Xlib and to the UTF-8 convert-+ ers.
+
+ o XKB keyboard definitions have been added and updated for some countries.
+
+ o Locale support for Celtic languages has been updated, and a Compose file
+ for ISO-8859-14 added.
+
+2.4 Miscellaneous
+
+ o Preliminary support for Linux/mips (no X servers yet).
+
+ o Update support for BSD/OS.
+
+ o Update Linux/IA64 support.
+
+ o Support for LynxOS 3.1.0.
+
I used to get the mystical black screen of video card lockup on this ATI chip.
It's now working (seemingly) properly under 4.0.1, which is great because Xfree86 4.x is pretty slick. I'll have to do some more testing to make sure it's stable though.
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot