ATI Radeon 9x00 2D support added, and 3D support added for the
Radeon 8500, 9000, 9100, and M9. The 3D support for the Radeon
now includes hardware TCL.

Support added to the i810 driver for Intel 845G, 852GM, 855GM
and 865G integrated graphics chipsets, including 2D, 3D (DRI)
and XVideo. Support for the 830M has been improved, and XVideo
support added.

National Semiconductor SC1x00, GX1, and GX2 chipset support added
with the "nsc" driver.

Support added for the NVIDIA nForce2 integrated graphics, GeForce 4,
and GeForce FX.

Major SiS driver updates for some of the latest chipsets. Unfortunately
the SiS 3D driver has had to be disabled because no one has yet
taken up the challenge to port it to Mesa 4.x.

The s3virge driver now has support for double scan modes on the DX
(with XVideo disabled).

Updates to the savage driver, including fixing problems with the
TwisterK, and problems with incorrect memory size detection.

2D acceleration added for the Trident CyberBladeXP/Ai1 chipsets.

Support for big endian architectures has been added to the C&T
driver.

Various updates and bug fixes have been made to most other drivers.

2.2. Input Driver Enhancements

The mouse driver now has automatic protocol detection for PS/2 mice.

Several new input drivers have been added, including tek4957,
jamstudio (js_x), fpit, palmax, and ur98 (Linux only).

2.3. X Server and Extension Updates

Support for the RandR extension has been partially integrated
into the XFree86 server, providing support for resizing the root
window at run-time.

The Mesa version used for OpenGL 1.3 and DRI
driver support has been updated to 4.0.4.

The XFree86 server's hot keys (including those for switching
modes and virtual terminals) can now be configured via XKB.
Previously they were hard coded. An X server configuration
option has been added to allow the VT switching hot keys to be
disabled.

2.4. Client and Library Updates

An Xcursor library providing support for alpha blended (ARGB)
and animated cursors. Two Xcursor themes are provided (redglass
and whiteglass), as well as the default "core" theme (the traditional
cursors).

Modify parser tables to improve detection of malformed
control sequences, making xterm behave more like a real
DEC terminal.

Fix a problem with the blinking cursor which occasionally caused
xterm to pause until a key was pressed.

Fix improper parsing of multiple items in the ttyModes resource.

and the following improvements:

Modify xterm to invoke luit.

Add simple session management client capabilities.

Add a modifyCursorKeys resource to control how the shift- and
similar modifiers are used to make a cursor escape sequence.

Check if the printerCommand resource string is empty,
and use this to allow the user to disable printer function.

Sort the options list which is displayed in help- and
syntax-messages at runtime to simplify maintenance.

2.5. I18N and Font Updates

FreeType2 updated to version 2.1.1.

The "freetype" X server font backend has undergone a partial rewrite.
The new version is based on FreeType 2, and handles TrueType
(including OpenType/TTF), OpenType/CFF and Type 1 fonts. The old
"type1" backend is now deprecated, and is only used for CIDFonts
by default.

A new utility called "mkfontscale", which builds fonts.scale files,
has been added.

The Xft library has undergone a major restructuring, and is now
split into fontconfig (which deals with font discovery and
configuration and is independent from X), and Xft itself (which
uses fontconfig and deals with font rasterisation and rendering.
The format of the Xft font configuration files has changed in
an incompatible manner.

Support has been added to the Xft library to do rendering with the
core X11 protocol. This allows clients using this library to
render to X servers that don't have support for the RENDER extension.

There has been a significant reworking of the XKB support to allow
multi-layout configurations. Multi-layout configurations provide
a flexible way of supporting multiple language layouts and switching
between them.

2.6. OS Support Updates

Updates for Darwin/Mac OS X, including:

Indirect GLX acceleration added.

Smaller memory footprint and faster 2-D drawing in rootless
mode.

Full screen mode now uses shadowfb for much faster 2-D drawing.

Native fonts can be used on MacOS X.

Various Cygwin support updates, including an experimental rootless
X server for Cygwin/XFree86.

AMD x86-64 support (primarily for Linux so far) has been added.

Support added for OpenBSD/sparc64.

Major OS/2 support updates.

Major SCO OpenServer updates.

Multi-head support has been added for 460GX-based Itanium systems,
and for ZX1-based Itanium2 systems.

Experimental support for SunOS/Solaris on UltraSPARC systems.

A more complete list of changes can be found in the CHANGELOG that is
part of the XFree86 source tree. It can also be viewed online at our
CVSweb server [xfree86.org].

Keep in mind that without the RENDER extension, antialiasing will really cause a lot more load and slower draw-in. But it isn't really much of a problem. 99% of cards out there have RENDER supported now. ATI/S3/nVidia/PowerVR/Intel/Matrox. It isn't too much of a problem for most.

You cannot be told what the cursors look like; you have to see them for yourself.

No... really, the cursor can't be captured with a screenshot.

So, just imagine a red mouse cursor with a white outline and a strange red shadow that makes it look like there is ghosting on your screen when you're over a black area. That's redglass.

whiteglass looks a little better.

Oh, and they're scaleable. So, if you change your resolution to something lower and then go back, your mouse cursor might look really tiny. Or, the other way around, and the cursor will look really large. Basically, X is attempting to keep the cursor the same size on the display across resolutions.

However, IMO, the shadows suck. They look like a really cheap ripoff of Windows 2K/XP's shadowed cursors. The alpha-blendedness is pretty, but not much else.

Occasionally, if you're watching a movie in fullscreen with the xv driver in mplayer (or maybe xine, too) and you move the cursor, it leaves behind a black square. Very annoying.

I'm only using a Radeon VE/7K, so maybe I'm not expected to see any amazing differences, but things have almost gotten worse with the TCL stuff in the radeon driver. The VE/7K doesn't have TCL support, so sometimes, some accelerated GL stuff locks up X, and you have to log in remotely and kill the offending app. Hopefully this will be fixed in 4.3.1, or the separate dri project's drivers.

However, IMO, the shadows suck. They look like a really cheap ripoff of Windows 2K/XP's shadowed cursors. The alpha-blendedness is pretty, but not much else.

You might want to have a look at these [musichall.cz] cursors - Jimmac doesn't seem to be working on them anymore, or at least the last update was last October and there's no package. But you can use any of the other cursor themes as a template and just copy the images from the web page (no scalability, though).

Personally I couldn't stand either the redglass or whiteglass themes; Jimmac's cursors, OTOH, are pretty close to perfect.

I made a new release today, 0.0.3 in which the shadows work a bit better (but not quite good). The shadows are generally too dark and can become clipped as the program does not extend the clipping size of the image to account for the shadow.

I've had several requests for a README, but I haven't done so yet. In addition, 0.0.4 will likely have an unzip feature to extract the curxptheme files.

In correct textbook English, you default to the masculine form. Way back in the mideval times, when English was Germanic, the Church came in and huge parts of Latin got folded in over the years (including defaulting to the masculine).

Byte-code interpretor is still the only way to go. It creates lovely fonts that are (in my opinion) on par with OS-X. And the level of control over antialiasing is exceptional. Freetype2's hacked autohinter has improved a bit, but I still prefer the byte-code interpreter for CRT displays. LCDs look pretty darn good without the byte-code interpreter, as long as you fire up subpixel rendering.

I haven't had the problems you have, but i must confess to seeing this version hog a few more megabytes than 4.2.1 and giving worse rendering on the quake games, and even crashing some of my xmms 3d plugins (everything all recompiled against the new X libs of course)

Nothing good to report from me on this new release... aaah, the price of staying up to date:-/

Yeah, my general policy with X is "if it ain't broke then don't fix it!"

This applies to major versions, like upgrading from 3.3.6 might be a good idea, but 4.1.x might not, especially if 4.1.x works good for you.

Sometimes you have to stick with an older version because your ancient card has been dropped. My laptop, a Compaq Contura 4/25c falls into this category. It has this weird _QVGA_ video which AFAIK is 3.3.6 only.

Somehow though, Debian has managed to port the 3.3.6 XF86_SVGA xserver to 4.1.x, so I could potentially install the latest version. I did this for my friend, he has Cirrus Laptop Mystery Video which worked with 3.3.6 but not 4.1.x, the Debian backport fixed him right up.

X is really a fantastically stable platform. It is great that the X team is working away, but don't feel like you _have_ to upgrade just because a new version is out. The new versions are mainly made to support new hardware. If your hardware works ok then you do not necessarily need to upgrade unless you just want to.

Heh, it's a point-oh. Give it time, they'll work out all the rougher spots. I'm gonna wait for the distro to pick it up, they'll make sure it's stable enough. Though I'm dying for the new i810 support... tuxracer is unbearably slow without it.

I'm gonna wait for the distro to pick it up, they'll make sure it's stable enough.

Depends which distros your talking about.. Some [mandrakesoft.com] seem to care more about buzzwords than stability. But there are a few exceptions. [debian.org]

Personally, I wouldn't touch it with a 10 foot pole.. I don't pretend that I can help debug it in a meaningfull way...and this new version doesn't make my current version work one bit less.

Stability issues aside though, I'm overjoyed to hear that Radeon support is still improving. I'll pass a brick when DRI + Xinerama works with the OS Radeon drivers. Improving support for built in 3D chipsets is also great news. Even minimal performance is a godsend. These guys are doing great work.

This may not be your issue, but the Xft configuration file syntax has changed in a non-backwards-compatible way as of 4.3.0. This will lead to broken font behavior if you're not careful. Is it seeing all of your fonts? Are you still getting antialiasing? If not on either of those, you probably need to tweak your Xft config.

I know that usually companies are on top of these updates to keep the best updates on the shelves, but how long does it really take a company to go from reproduction with the new updates to shelf life, if at all?

Or, if they are too lazy to even re-release it, how long until they decide it's compatable and post it on their website?

Red Hat 8.1 beta (Phoebe) has xfree86 4.2.99.3 packaged... since then, XFree86.org has released several more snapshots (.4,.901 and.902)... I've been running the snapshots (.3 and most recently.902) for awhile now....3 had a problem with the nvidia driver... once X came up, I couldn't Ctrl+Alt+F# to a terminal, but that was fixed fairly quickly.

Anyways, RH is likely waiting to test all these newfangled toys. GNOME 2.2 came out, and now that X4.3 is out, RH8.1 shouldn't be too far behind:). Be patient!;)

mkfontscaleA new utility, mkfontscale, is included with this version. This creates fonts.scale files. In the past, in order to install third party TTF fonts (such as MS corefonts), a utility called ttmkfontdir was often needed (except in distros like RedHat that took care in making everything "just work") to build the fonts.scale file. This program depended on Freetype 1.x libraries (which can't always coexist peacefully with freetype2), and was generally a PITA.

That's what transparency is. Transparency is normally implemented using alpha blending. An alpha value of 1.0 is a fully opaque surface. An alpha value of 0.0 is a fully transparent surface. This can easily be done on a per-pixel level either by using a separate alpha map or by using a alpha channel on the main image.

Normally a 32-bit, RGBA image is used. This gives you normal 24-bit color, with 8-bits per channel for Red, Green and Blue. The extra space is an 8-bit alpha channel giving you 256 different levels of translucency.

I guess I'm just confused as to how you can have alpha blending, but not "transparency," as they are the same.

Yes. XRender only supports one layer of trasparency - if you have a transparent XRendered object (such as a cursor), it'll show the object underneath. However, if the object underneath is also transparent, you won't be able to see through both layers to the third layer underneath. As a result of this, transparent windows don't work too well yet (though probably still better than the traditional hack of grabbing the X backdrop, shading it and pasting it in) - but since nobody is really using transparent windows, a transparent cursor is unlikely to highlight this issue.

transparent ?terms work by just displaying the background picture appropriately translated.

kde menus work by taking a picture of the desktop, and using that.

Transparent cursors, as far as I know, are 'the real thing'.As for the transparent cursor over a movie - my guess would be that it depends on how the movie is being drawn. If it is being drawn like every other window, then it should work fine - however xine and mplayer by default don't do this, as this is slow. Instead they more-or-less draw directly to the video card. This probably won't allow the shadowing to work.

Also things like TV cards draw directly to video, so I doubt shadow would work on them either.

Edit.Xdefaults (or.Xresources, whatever) to do:Xcursor.theme: where name is a subdir of/usr/X11R6/lib/X11/icons or ~/.icons

Then:xrdb ~/.Xdefaults

Then:Restart your window manager, not necessarily X, just the window manager. Probably another way to do it, but that seems to reinitialize cursors in most cases.

The sd2xc utility mentioned below seems to work well.

I imagine that before too long all this functionality will be in a trivial app. Aside from having Xcursor reinit, I could have a nice gui program to do this inside of 15 minutes, and I'm too lazy to figure out how to do the reinit from PyGTK;)

I'm probably not alone with this problem, but I've always had problems with trying to get XFree86 3.x or 4.x to work with PS/2 mice with a KVM in between. Either the mouse isn't detected, the mouse cursor reacts erratically or can't get anything behind two buttons to work. As a workaround, I've always had to get another PS/2 (or USB) mouse and plug it directly into the machine rather than go through a KVM.

I've got a LinkSys KVM (2 port) and have nary a problem with my mouse (Logitech TrackMan Marble FX). Could the problem be that you've got a dumber than usual KVM? The cheap ones don't do the ps/2 thing quite right from my experiance (and forget the old manual switches).

There is a workaround using XFree86 4.3 and a script I created. When combined the mouse fixes itself when switching machines for a second time. First you have to change the mouse type to auto from imps/2. Another workaround is to use ps/2 as the type, but then you lose your wheel. Then make this file, and make it excutable and setuid.

#!/usr/bin/perl

use strict;use warnings;

use Time::HiRes qw(sleep);

open(OUT,">/dev/psaux");print OUT "\xF5";sleep 0.5;print OUT "\xF3\xC8\xF3\x64\xF3\x50\xF2";sleep 0.5;print OUT "\xF4";close OUT;

The above requires the Time:HiRes perl module and perl-setuid installed. You can likely remove the Time:HiRes requirement and sleeps, but not sure . Then you bind the script to the scroll lock key. I do this via sawfish, my window manager. But there are probably a dozen different ways to bind it. If you are switching between two Linux boxes both need the script and XFree86. I currently am switching between RedHat 8.0(4.2) and RedHat 8.1 beta3(4.3, phoebe3). The beta works right and the non beta doesn't. 4.2 does hae auto detection, but when I tried it and someone else tried it it said in the logs it couldn't detect the type.

Hey anyone know if this version of X fixed the mouse problems for Quake 3? I know it's a long shot, but I have not been able to upgrade X in a long time, because everytime I do I can't play quake 3. The mouse simply binds to the upper left hand corner and doesn't move.

I've been rather surprised at how quickly packages have been getting into unstable recently, actually. When I first saw on Slashdot that GNOME 2.2 was released, I did an apt-get upgrade and it was already there. (And it upgraded cleanly, which has _never_ happened with other versions of GNOME. Woot!)

I've been using this for six months now (due to the latest gatos drivers eternally needing a version of X that wasn't in debian). The good news with doing this is it's relatively easy to unfsck if things don't work. It sounds as though they've changed the font server configs so you may have problems with this in the latest version (I haven't done this yet).

I'd recommend changing the link back to the.debian dir before doing a apt-get upgrade or things may get really pear shaped in a hurry.

Since this is a story about X, all of the pre-programmed Slashbots are going to trot out and declare that X is broken, old, badly designed, missing features, whatever.

Meanwhile, the XFree86 team continues, release after release, to pound out great code that addresses all of the shortcomings people tend to cite. Faster direct rendering? Check. Anti-aliased text? Check. Multi-head? Check. Video extensions? Check. 3-D? Check.

Do you see a pattern here? X is versatile. X is extensible. X is the industry standard -- all Unix GUI programs use it.

And as always, X's killer feature is its network transparency. No "desktop-within-a-desktop" nonsense like you have to do on other platforms. Today I had the windows of programs from no less than three different computers running on my desktop. Transparently. Lots of X users do this every day, usually without even thinking about it.

Perhaps someday the tired old "X is obsolete and must be replaced" will finally cease. But today is probably not that day. Let the flames begin. I will ignore them and continue to praise the XFree86 developers for another job well done.

Your own glowing testimonial is not exactly a balanced review of the real product.

But perhaps people like yourself, who are willing to give the X developers the accolades they so richly deserve, are necessary to counterbalance the people who only see the bad points of X.

There are good and bad things that can be said about X-windows, but I don't think anybody that is paying attention would have anything but praise for the people who have worked so hard to make it as useable as it is.

On the other hand, I can honestly say that Xwindows is the only piece of software that ever caused my monitor to literally catch on fire. Gave me a very strong incentive to RTFM, I must say.

Usually the replacement mentioned is Fresco, a.k.a Berlin. I think Fresco is a good replacement for X in the same way GNU Hurd is a good replacement for Linux. The dieas and potential are true next generation, but the implimentation is years away. Which is fine. I agree X certainly will hold us as long as it needs to.

I read a post when kde 2.0 came out that some Linux users got it to load with just QTembedded installed. Maybe it could be possible to use kde itself without X. I asked a kde hacker at linux expo 2000 about the possibilities of porting Konqueror to Windows( mozilla and netscape were both considered dead at the time) and he told me that X is integrated in most of the kde applications. It will take alot of work to get it to work without X.

However Fresco aka Berlin is dead, has 3 programmers working on it, and its written in Forth so nobody can contribute code to it because the language is not well known. I remember reading about it in 98 and years later the ability to draw basic shapes has just surfaced. Very immature and years behind. Aqua is nice but only available from apple. News is dead and was suppose to be an alternative to X. I don't know much about it or if their are some sources of it. Otherwise the OOS community could use it to write their own graphical environment.

Gnome or Kde using QT or GTK+ Embedded may be the only real viable option.

There's not really any more support for anti-aliased fonts now than there was before the Render extension, except that the Render extension makes drawing of anti-aliased fonts fast.

But the application still has to do the work itself. Whether it does so through "standard" libraries like the gtk or KDE toolkits is irrelevant: the bottom line is that anti-aliased fonts requires client-side support.

Clients have always been able to do anti-aliased fonts if they wanted to, but prior to the Render extension they had to do it the hard way: by actually drawing the individual characters and doing the transparency blending themselves.

The implementation of anti-aliased fonts is all wrong, IMO. The XFree86 folks should define a new font server protocol that knows how to talk about transparency (indeed, the protocol could easily be implemented such that it uses the same socket and everything: if the X server sees that it's talking to an old font server then it will revert to the proper monochrome font protocol), implement a font server based on Freetype that actually uses it, and hack the X server backend so that it automatically does the right thing when asked to perform operations using an antialiased font. The client shouldn't even know or care if the font is antialiased: that's a server-side-only issue (it's acceptable to name antialiased fonts differently, using perhaps a different encoding name or something, in order to make it possible for the client to distinguish between antialiased and nonantialiased if necessary).

Font handling belongs in the server. The client should never have to worry about it. Which means that the situation as it is now should never have come to pass. The Render extension is very useful for things like doing transparent windows and such, but it should never have been used for font handling: that was an evil hack, and now we're stuck with it.

What's this all about? I'm not biased towards or against X, I simply don't know enough.

But I do know that Microsoft also improves Windows with each release, addressing many major complaints. We still don't support them despite all this! So I don't see how your argument is useful at all..

And besides this, yours is the first modded up comment about X and whether it's obsolete or not.

Well, so tell us: in what way are Windows or Macintosh OS X supposed to be more efficient? Where are these great gains in efficiency in their architecture supposed to come from? I mean, it can't be the use of IPC or system calls for the application to communicate with a graphics server: Windows and Macintosh have that as well.

In reality, there is no fundamental difference in the client/server window system architecture between OS X and Linux. For NT, there is a difference: large chunks of the windowing code have moved into the kernel ad some point, but you still need system calls to talk to it. Of course, there is nothing to stop anybody from moving X11 into the kernel.

Overall, the idea that network transparency is some sort of special feature that one pays a high price for is nonsense: all major desktop operating systems run in protected mode, and most GUI applications run in a different context from the window system. X11 simply has been designed that way from the ground up, while Windows and Macintosh have evolved there from "direct mode" graphics. Network transparency in X11 is not so much an issue of IPC or how it does graphics--it uses IPC like all desktop windowing systems--but in having well-defined network transparent support for features like window management and configuration information. It's lack of those features in Windows and OS X that means that Windows and OS X are not network transparent.

In practice, XFree86 is a damned efficient window system that, when it has comparable drivers for the graphics cards, beats OS X handily in terms of performance and memory usage, and usually even beats Windows.

You need screen on another computer, use TightVNC.

TightVNC gives you a "screen on another computer". It does not give you network transparent windowing. If you are running a well-designed X11 desktop, you can run applications on any machine, and they will behave as if run locally. You can also move individual windows between machines and displays. Of course, Gnome and KDE both break this behavior, but that's not X11's fault.

MSWindows 98 is snappy, even on quite old hardware. XFree runs like shit. It feels klunky and laggy.

That's a ludicrous claim. X11 worked reasonably well on 1988 hardware already. X11 servers obviously can run like a charm on 1998 hardware, hardware that's more than an order of magnitude faster.

And that's also what one finds in practice: Windows 98 requires much more hardware (memory, CPU power) to run than Linux/XFree86. If you claim were having a problem with Linux/XFree86, either you are making it up, or you had a bad driver, or you misconfigured something.

I haven't much experience with OSX, but with Windows... KDE/Gnome/Windowmaker
all feel klunky with dealing with any type of object (window, icon, pointer). [...] And even with the (older and) newer Xfree86'es, I STILL have the "page tear effect" in many applications. Even in Mozilla. I'm sure I'm not the only one (and if I am, how do I fix that)?

So, KDE/Gnome/Mozilla are clunky. Let's add Java to the mix, too. You won't get any argument from me there. Those toolkits rely heavily and unnecessarily on bitmaps. They are effectively written with a local direct drawing model in mind. They fail to use the X11 APIs properly in many ways. And that's not really so surprising: KDE, Mozilla, and Java all use cross-platform toolkits, and they have been designed primarily around Microsoft's APIs and Microsoft's performance characteristics, with X11 support kind of as an afterthought.

I also know
that X wastes a bunch on bandwidth that Tight VNX saves. Try that
"oh-so-nice-network-transparency" over a modem. I have, and it sucks compared to
how snappy a 640x480 8bit black background screen transfers over EVEN regular
VNC.

The default X11 protocol is optimized for minimizing CPU usage and latencies assuming LAN-speed connections. That's the environment people are using it in, and that's the environment it has been successful in for 20 years.

X11 does not try to minimize network traffic. If you want to run X11 over slow connections, you need an X protocol compressor. One comes built into your X11 server, but you need to enable it (lbx).

And there is nothing wrong with using VNC--it's a great system. It simply isn't a network transparent window system, it's a remote display--different function and different application.

still stand by what I said. Go get a copy of WIn98, and a feature-equilavalent copy of Linux with X and managers.

Well, and I say: you are wrong. I have run X11 and Windows 95 on the same hardware, I have run X11 and Windows 98 on the same hardware, and I'm running X11 and Windows XP on the same hardware. X11 has always been competitive with Windows, and usually beat it, in actual measurements as well as "feel".

What's there to address? 3D games under X11 don't involve the X11 protocol, they use DRI (the equivalent of Direct3D). If that is slow, it's a problem with the 3D drivers or the game, it has nothing to do with X11. Basically, this claim is characteristic of your reasoning: something doesn't work, and you blame X11. I have to say, I have run all versions of Quake on Linux and have had comparable frame rates to running it under Windows.

But to what you accuse me of, it's MY fault X runs slow....

It's your fault to make bogus comparisons. Face it, Linux is still largely unsupported, and it is certainly unsupported on Windows 98-style hardware. It's not suprising that you might configure your machine less than optimally or that your drivers aren't very good. Most people aren't bothered by that, since it runs fast enough, but if you are going to nit-pick about performance, you have to nit-pick about your own installation as well.

Likewise, a lot of GUI developers (KDE, Gnome, etc.) come to X11 without knowing much about X11 or understanding how it works. It isn't surprising that they produce inefficient or sluggish code.

But we know X11 can run fast. You said so yourself: you found it responsive on a 120MHz SPARC, hardware that it is actually supported on.

If you want X11 to run fast under Linux, either figure out how to configure it properly and buy the right hardware for it, or go out and pay the money for a commercially supported version with drivers that were written with access to closed hardware specs.

---Usually when there's complaints from a wide amount of people, it's "the people" you trust. Not the few who complain about the complainers. If anything, it has too many features. I believe we insult/harass/jeer at MS for doing the similar thing to Windows/Office. Called something like creeping featurism....... BUT it's different when we're talking about XFree86 cause it's LINUX stuff.

You know having fully featured infrastructure components, which X is, is damn nice when writing applications. Feature creep is bad in a word processor, good in your display system.

X has little to do with Linux. X has been around for a long time.

---Yeah, it IS getting faster...

This goes directly to the network transparency myth. X window systems tend to be a little slower on login because things run in user space. Once things are running however, there is no performance penalty at all. With X you can choose a lot of things that can affect display performance. Seems to me that other display systems don't have this option. Want a blazing fast X system? Choose reasonable window managers. A machine running TWM these days is very fast yet will still do everything needed in a nice clean minimal way.

As a comparison, I have an older SGI IRIX machine running at a blistering 30Mhz. Scrolling text in a window, minimize, raise, lower and resize are all nice and fast. X is clearly not the problem here as it has been proven to be effective for years. That machine was manufactured in 91 and will still display 3D applications in a usable way.

---Yeah right. 3-D on linux/Xfree SUCK ASS. Want compairsons? Go play X game (with port to linux) on windows and then play it on Linux. You get shit for framerates, and dont tell me you're different.

I don't think so. OpenGl based games run just as well if not better than they do under windows. My current 3D machine used to be a windows machine and I ran the game in both environments. latency was a lot lower in the X environment than it was in the win32. Lots of people see this so you can forget your one guy argument. Running programs like Maya or Pro Engineer work very nicely as well. This used to be the case, but is not anymore. So, 3D, check.

------Do you see a pattern here? X is versatile. X is extensible. X is the industry standard -- all Unix GUI programs use it.

---Yeah, and all good games are out for Windows. Windows games are the industry standard. (sound dumb? same way you sound with X)

Yeah this does sound dumb. The X window environment has been setting the bar for display systems for years. Just think, they got it right long before win32 environments were even stable. X is the industry standard in many areas. Games are a niche. An important one, mind you, for the overall consumer market, but this does not make an industry standard all by itself. High end scientific applications, Mechanical CAD, Visualization are just a few of the true industry standard applications that have all ran under X for years. Ask users of any applications in any of these areas what the transition was like when moving to the win32 platform. It took a long time for things to work as well as they did under X. Very few things are really better.

Games? Direct X? These both sound dumb to me if they are to be considered the way of the future. Games will eventually end up on whatever platform has both power and marketshare to sell copies. Linux + X can do games very well right now, but marketshare is smaller. As that changes, you will see the games same as you did for win32.

I think it says something when the best graphics guy around continues to invest in OpenGL. Direct X is a capable, but clearly dead end API. Hardly competitive at all really. Got your killer application running under Direct X, but want to run it on higher end graphics systems? Sorry, win32 only. Maybe the next revision, that they make damn sure you keep paying for, will have what you need. Using OpenGL avoids this problem nicely.

If you want do discuss other aspects of the interface, you might equate OpenGL to X in that they have the same core design ethics. OpenGL has also set the bar in its way for years before Direct X was even a consideration. To get Direct X where it needed to be Microsoft had to thrash and almost kill SGI through their Faherienhit (sometimes spelling sucks --sue me) project.

Finally, if you want to again consider industry standards, consider this:

Every last high end scientific and engineering application that actually matters uses OpenGL for its display engine. Why? Because it is accurate, stable, scaleable and just works well. Microsoft would love for this to change, but creators of these applications know all to well the dead end nature of the Direct X API.

---And you're 1 out of how many??? You need screen on another computer, use TightVNC. Uses a bunch of less bandwidth too.

I will agree with you about the bandwidth issue, though this can be mitigated with ssh and compression. However you totally miss all the points here while showing that you really have no idea why people, who know what X does, use it this way.

X is a big part of why UNIX systems are true multi-user systems and the network transparancy is the key feature making this a reality today.

Any X window user can basically run any application from any machine they want from the machine they are on. Lots of people do this. It is called multi-user computing. Most people not doing this really just don't know it is an option.

This feature has some interesting ramifications when it comes to systems design and implementation. Not having it eliminates many choices that could reduce administration and costs.

Example:

Company uses high-end MCAD product; namely, EDS I-DEAS. This is complex and powerful software with included data managment.

If you are running win32, then you have only one choice. You load that software onto every machine that will ever use it. Outfit every machine that will ever use it with high end CPU, video, disk and RAM. To administer, you must deal with each and every machine all the time. Service packs, driver changes and other things like applications that change core system shared library code hose things up on a regular basis. Heavy users as well as light duty users must possess all necessary resources on their local machine.

Upgrades to software must be deployed locally on each machine. Complex scripting is needed to really get things done in a reasonable manner. Upgrades to hardware get quite expensive over time as each user gets new hardware which means new OS which means new display and drivers along with the reloading and rebooting that comes with that.

Now consider your options when you are running a real multi-user OS and the X Window display system.

You configure one multi-cpu server and remote display on just about any 3D capable PC. Machines can be new or old just as long as they have a good network interface and graphics engine. Almost any recent vintage machine made in the last 3 years or so will perform this task nicely. Because the application is running directly on the server, many data intensive applications that used to bottleneck on the network now run smoothly. Cost per user is low because the OS is multi-user. Properly sized shared resources make for a good computing experience for all the users. For the occasional power user, go ahead and give them local compute if you need to. The choice is yours with X, you don't even get to consider it with anything else.

Now upgrade time. Add CPU or RAM to the server, all users benefit. Want to change software revisions? Great, it will take a fraction of the time because of shared code and configuration data. This leaves plenty of time to deal with those power users computing locally. Users local machine gets hosed up, what do you do? Give them a replacement one with the standard applications loaded and fix theirs as you have time without impacting their workflow at all. Since their critical data is in a shared stable environment, they will hardly notice.

When Open Office gets just a bit better, this will be possible for more mundane applications as well. The savings and advantages are obvious --if you know you have the option.

BTW, Apple is now beginning to ship an Aqua supported X server. Wonder why that is? Could it be because X has some advantages? Maybe they are interested in high-end applications being ported to the Mac. Not sure of the reason, but I am sure they would not do it if X really was as you say...

Schools all across the country are all working on implementations of the Linux Terminal server project. This project depends on X and its features. Administration will be remoted and centralized to save costs and improve response time.

At home here, I run win32, Linux and SGI irix. Each of the machines have applications I am interested in running. All the UNIX applications are avaliable on every machine with just two clicks and can be used by anyone at any time. My wife is currently watching a DVD as I type this. That same machine is providing Evolution e-mail to the win32 machine via X at the same time. Why bother running more than one mail client. With X, I can choose any client I want and use it anywhere I want.

It is easier than you think and very well worth it.

Finally, Tight VNC is pretty cool for what it is, but it is not multi-user. Sure, it will save you a trip to a machine, but will not allow any sort of multi-user action of any kind. Limited and totally non-competitive compared to X.

Network transparancy is *huge* and most of the industry is blind to it because Microsoft and Apple do not provide it. Their loss really.

---How about modularizing the obsolete crap (like the XT module in the linux kernel) or pulling the garbage out altogether? MSWindows 98 is snappy, even on quite old hardware. Now take that nice dual cpu motherboard and slap linux on that with a well-supported XFree video card. XFree runs like shit. It feels klunky and laggy. And no, I'm not using KDE to use as a test. I'm using TWM. The smallest gui manager out there.

I will give you points here. A lot of OSS software has been gaining in functionality in trade for speed. I wrote an article about this a while back titled "Where Is the New Linux Experience?" When I wrote that, I had the same experience you did.

Things are changing now. The feature growth is needed to capture users interest and get things done. Truth is, hardware fast enough to run most things is very cheap now so this is becoming less of a problem. Development is now starting to address speed issues and it is showing results. Compare KDE 3 to KDE 2 and you will notice the difference.

Given the cost savings of OSS over software you pay for, and you do pay for all that win32 or Mac software don't you? The price of a newer machine is easily justified.

The parent post is dead on. Every time X gets mentioned, people like you, who really have little grasp of the bigger picture, bitch and moan about how X doesn't do exactly what their older and inferior system does.

The only reason why video overlay might not work for you is if you were using in XF86Config file generated by ATI's config utility from before they supported video overlay.

Well, it did work insofar as the video was shown. It did not work because the video overlay caused artifacts all over the screen! Little chunks of the video image were drawn at random locations horizontally from the overlay window, which - needless to say - sucked. And I used config files from the same driver versions' utility, and yes, I did read the README.

I had this behaviour in every version. I reportet it to ATI in every version. I did never even get a reply. So to all those who cry "support DRI" and stuff: I'm right behind you in that matter. But those folks can't do shit about Via sitting on patents for S3TC/DXTC, and I don't have the time or knowledge to work around this myself. I've since given up on getting any commercial game to run too desperately. If it doesn't work after a sane amount of time, I just play it in Windows and the current DRI drivers at least allow me to do some basic GL hacking with some basic extensions.

While I'm sure there is a lot of great stuff coming out in this release the thing I'm waiting for is the ability to change the resolution of the X-server without shutting it down. I heard that there was code to that respect in the works does anyone have any information on this?

There's support for DVI flat panels now so long as you POST on that head, as well as real acceleration on all the modern nvidia cards. Looks like no more grabbing and rebuilding the non-free kernel-invasive nvidia stuff.:)

Just informational.. I've been running an XFree86 4.3.0 beta on my OS X desktop for a while now and it is MUCH more responsive than 4.2.. I can run KDE in full screen mode and it is actually usable. With 4.2, it was slower than using VNC over a T1. So, for all those who wished apple would have included a full screen mode in its X11 betas, 4.3.0 is what you're looking for. I believe the changes they incorporated were actually from Apple anyway (they released the source back).

I run the nVidia drivers, and have no problem. Why would anyone not use the nVidia drivers under Linux. I have a dual head setup (not Xinerama). One is a Gforce 4 Ti4600, the other is a GF2. I can frag with my first and keep an eye on slashdot and my e-mail on the second.

I use them on my GF2/GTS, and they've got some SERIOUS bugs! X frequently locks eating 100% of the cpu until I kill it... I ran strace and it's just looping. I have to remotely log in to do so, as even if I could get to a console, they're scrambled after killing X, requiring a reboot to "fix".The newer the driver, the worse the problem, to the point that I can lock it seconds after logging in in a predictable way. I posted info on the nvidia forum, no replies of any use.I am using one of the older drivers (2 or 3 releases old) and I can actually have X going for a few days now, instead of minutes or hours.This is not acceptable... if I was willing to put up with this level of instability I never would have switched to linux 11+ years ago.

I bought a Gigabyte Maya (Radeon 9000 Pro) recently, to replace my aging TNT2 M64, and overall, I'm pleased with it...it's much faster and has better features than a GF4 MX440, which is what I was actually looking for, but the drivers have definitely been a problem.I had my first XP Blue screen within 5 minutes - and the error message clearly showed the crash was in the ATI driver. It's not crashed since, but it still happened.I've also noticed artifacts and weirdness in a number of places.Overall, I'm happy with the card, but I think that If I was going to spend the money on a high end card, I'd be looking at an nVidia, not an ATI, even though the 9700 has an edge over the GF FX.I've never had a problem with the GF2Go in my laptop, and my girlfriend's never had a problem with the GF2MX in her machine.

I've got the AIW Radeon working fine under Linux. I used the gatos drivers from gatos.sf.net, which have been ported to the new XFree 4.3 for a while now. Tuning and 3D support both work great, but capture is still an issue for the gatos project. They're working on things though.

XFree86 communicates with the local client over a
Unix domain socket or a platform-specific transport
(on SVR4 and Xenix, for example). In either case,
there's no TCP involved.

It also uses shared memory to transmit images.

There have been some attempts to make XFree86
use a shared memory transport, but at least on
Linux, it turned out that it's not worthwile. The
kernel's Unix domain implementation turns out
to be just as fast as any custom code that XFree86
could implement.

X servers listen for connections on a variety of different communica-
tions channels (network byte streams, shared memory, etc.). Since
there can be more than one way of contacting a given server, The host-
name part of the display name is used to determine the type of channel
(also called a transport layer) to be used. X servers generally sup-
port the following types of connections:

So, while you might be correct in some cases, you're not always correct. If you're connecting to a remote host, odds are good that you're using TCP.

It is my understanding, based on reading of some xinerama docs, that xinerama does allow 3d acceleration, but only to the first monitor. Some drivers can supposedly handle it, if it is off the same card through Xinerama (or was planned.) NVidia's reportedly can, because the driver doesn't interact with Xinerama. The driver hides the interface from Xinerama, by claiming to be one screen at something like 1280x480 for example of two 640x640 monitors together.

(NVIDIA's supposedly can, but dispite being able to get almost everything else running I come across, a second monitor (TV) seems too difficult or something, even copying config files from people with the same setup. I think it just doesn't like me.)

Please note: this was a while back, and I am not sure of that. Please correct if wrong. I am pretty sure on the Nvidia stuff, not so sure on the Xinerama stuff.

Since yesterday? You mean you got a head start yesterday. You'll still be emerging it when Debian Stable gets it.;)

Bah. I emerged rsync at 12:00 today, and then niced an "emerge -u --deep world" shortly after that. On my dell 8200 laptop (1.6ghz), by 4:00 I had a shiney new X, mozilla 1.3_beta, and a whole bunch of other neat stuff.

It's not for someone with a p266 who wants to stay bleeding edge (bad idea anyway), but I see debian users complaing all the time (scroll up) about how it's gonna take forever for this stuff to even get into the unstable branch.