XFree86 4.0.2 Released

XFree86 4.0.2 is officially out now. Besides adding a driver for those us with S3 Savage chipset based laptops, support for a variety of other chipsets, mesa updates, improved DRI support, this new release adds the Render extension which will hopefully give us anti-aliased fonts, alphablended menus, and a stromboli delivered nice and hot to your door. Mmm. Strom.

Comments

Re:Nvidia Detonator drivers?

[xercist]

They seem pretty hesitant to talk about it, even in the unofficial nvidia irc channel. That's the _first_ place it'll probably be available though.

irc.openprojects.net, #nvidia
/ctcp ice-dcc xdcc list

Be sure to bother ripperda if he's on - he works at nvidia doing coding for their linux drivers, and just loves to be bothered! :)
I find myself on there quite often to see if they've improved VIA chipset support, which currently sends my kernel down in a blazing fire :(

--

I think you're confused.

[bconway]

The reason you're seeing such delays at startup is because Gnome and KDE are huge, versus the X4 server which starts very quickly. I run X 4.0.1 with the latest and great version of WindowMaker, and startup from the time I type 'startx' to the time it's finished loading is under 5 seconds on a PIII-550. Needless to say TWM and others less intensive (Blackbox is great) start up even faster. Try just running 'X' if you don't believe me, and you'll get the standard gray screen in about 2 seconds. A lot of time the X server might start up slowly if it can't reverse resolve itself for whatever reason, so make sure your own machine is in /etc/hosts.

very confused...

[jmd!]

Is there any text that explains the new XFree 4 infrastructure in plain english?

you've got:

DRI,
GL, GLU, GLUT, GLX,
Mesa,
Utah GLX,
SDL...

I know very little about X/video rendering, but I'd like to upgrade to XFree4 and actually know what pieces of the puzzle i need.

Does DRI replace Mesa? Does Utah GLX replace DRI for cards it supports? Is Mesa even needed? Is plain Mesa included in the Xfree source tree, or is it a fork? If I don't have a 3d card, does mesa still install as a software renderer? Does this give better performace over the 1fps syndrome in xfree3/windows95? Are any of the projects I named obsoluted by the new infrastructure? (utah glx comes to mind...)

maybe someone here can explain it on a level somewhere in between the "gimme URLs of the RPMs so i can upgrade my redhat box" and the in-depth developer documentation on the dri/utah glx pages.

Hopefully any responce would also give others the confidence to take on this new infrastructure.

Also, does the new "render" extention take effect automatically for all new programs compiled that link to the standard libraries?

Re:very confused...

[nathanh]

Is there any text that explains the new XFree 4 infrastructure in plain english?

Ok, here goes...

• GL: Graphics Language. More commonly called OpenGL, a graphics library developed at SGI. SGI owns the OpenGL trademark but they recently relaxed the licensing and released conformance tests for OpenGL. There used to be literally dozens of 3D APIs but only OpenGL and Direct3D seem to have decent marketshare/mindshare these days. OpenGL abstracts 3D so the programmer doesn't have to know about projections, lighting, rendering, texturing, etc.
• GLU: OpenGL is pretty good but doing some common operations is a regular pain in the proverbial. GLU is a platform independent library that will build spheres, test collisions between 3D shapes, determine if a point is inside or outside a 3D shape, etc. GLU works on top of OpenGL.
• GLUT: OpenGL is platform independent but certain operations (like creating windows, receiving mouse clicks, resizing windows) change across OpenGL platforms. GLUT lets you write a single application that will compile and work on Windows, X11, MacOS, etc. GLUT is quite limited and is primarily used for simple demonstration programs rather than full blown applications.
• GLX: X11 is a networked windowing system. Your client and your server might be on different machines. GLX packages up OpenGL commands into network packets, spits them across the X11 network pipe, then unpacks them at the other end. This lets you run accelerated 3D remotely: the client could be running on a mainframe, crunching through millions of FP operations, and your 3D display could be a cheap Linux/NVIDIA box. This is sometimes called INDIRECT RENDERING.
• Mesa: Brian Paul wrote a free open-source implementation of OpenGL called Mesa. The name has no hidden meaning, it just sounds nice. The original versions of Mesa only did software rendering. More recent versions have had accelerated drivers for Glide, DRI, Direct3D, etc.
• DRI: Indirect Rendering is slow. SGI figured this out many years ago and created something called Direct Rendering. Direct Rendering lets the client talk directly to the video hardware. On UNIX this is quite complicated (because of permissions, multiple users, security, hardware contention) so an intricate software design called the Direct Rendering Infrastructure coordinates everything. The DRI used on Linux (designed and implemented by Precision Insight, now part of VA Linux) requires certain features only available in XFree86 4.0.
• Utah-GLX: An Indirect Rendering implementation which runs on XFree86 3.3. It is indirect because every OpenGL command gets stuffed into a packet, sent over the X11 network connection, unpacked at the other end, then rendered. There is a "Direct Rendering Hack" which only works with the Utah-GLX Matrox driver. Utah-GLX is slightly slower than the DRI but had the advantage of being simpler to implement, so it was available with more drivers much earlier than the DRI was.
• SDL: OpenGL only defines graphics (2D and 3D). The people at Loki needed to handle cdroms, audio, mixers, joysticks, keyboards, mpeg playback, etc. They created a library called SDL which abstracts all the things that games need. SDL relies heavily on libraries like Mesa to do the grunt work. You can think of SDL as a more powerful version of GLUT.

Does DRI replace Mesa?

No. Your client software speaks to Mesa. Mesa has a DRI driver which sets things up with XFree86 4.0, gets hardware access to the card (using the card-specific kernel module), then starts blitting away merrily on the card (Direct Rendering).

Does Utah GLX replace DRI for cards it supports?

No. You can think of Utah-GLX and DRI as two seperate projects trying to achieve the same end-result, but in different ways. The DRI is probably the best long-term solution. The two projects seem to work in cooperation fairly well. Many Utah-GLX developers are also DRI developers.

Is Mesa even needed?

Most definitely.

Is plain Mesa included in the Xfree source tree, or is it a fork?

The Mesa in the XFree86 tree is the Real Official Mesa. The Mesa project is still run independently but the code is regularly "synced" with XFree86.

If I don't have a 3d card, does mesa still install as a software renderer?

Yes.

Does this give better performace over the 1fps syndrome in xfree3/windows95?

No.

Are any of the projects I named obsoluted by the new infrastructure? (utah glx comes to mind...)

Utah-GLX is the only 3D accelerated option for XFree86 3.3, so it isn't an obsoleted project yet.

Re:very confused...

[amccall]

Rolls up sleeves...

Ok. DRI is also known as "Direct Rendering Infrastructure", it provides a method of access to the graphics hardware which eliminates some of the layers of abstraction in using OpenGL see http://dri.sourceforge.net, for info.

GL/GLU/GLX are all part of a 3D API which allows applications to use graphics hardware. GL provides the core functions, GLU provides extensions, and GLX relates to how the those relate to X.

Utah GLX was an effort to produce hardware accelerated 3d drivers for X a little while back for XFree 3.3.x... There is still work going on it.

Mesa is a "compatible" GL, since they can't legally call it OpenGL. Mesa is the basis for both Utah-GLX and DRI. The methods which the driver works are different though.

SDL is a cross-platform developer library which allows low-level graphics programs to be easily ported. (It also does sound, input, and timers.)

XVideo is an extension to X to allow mpeg/video accelerations, and tv tuner support, and a few other things.

The list of the features in the new render extension can be seen on the main page, but the biggie is the alpha-channel support. Most programs will not take advantage of it immediatly, but in time I think we'll see some nice things come from it.

Wow! Features!

[be-fan]

Look at the new features! If this were MS code, it would be worth at least a century or two jump in the version number! The cool ones are:

Bug fixes: Yea, those.

Render Extension: The render extensions and additional stuff added to x11perf, xft, and xlib to support it.
Compositing code for Render is complete, but a lot of stuff (polygons, image scaling, seperate alpha, see the summery) are still unimplemented.

Updates to nv for GeForce2: Hah! BeOS had GeForce2 support before X!

xf86cfg: A new, graphical configuration utility.

And much much more!

Here is the link.

It says that Render uses XAA for acceleration, and acceleration on the MGA chip is already implemented. 2Qs

1) If it uses XAA, why does it only accelerate on MGA?

2) Does this mean that it becomes a Render vs 3D choice for NVIDIA users? As far as I can see, the NVIDIA drivers don't support the Render extensions. Or am I just confused.

Re:Font antialiasing NOT compiled by default

[keithp]

The integration is not within XFree86, but of FreeType2 with our binary build and installation process. I should have started that a couple of weeks ago, but got caught with various other activities (like getting Qt working).

The XFree86 pieces are easy to do if FreeType2 is already installed; I expect the distro vendors to just make X require FreeType2 and ship a package for that as well.

I know at least one Linux vendor will.

Re:(+1, Thanks!)

[nathanh]

One followup question...in Xfree4, if you have DRI working, is all 3d rendering through Mesa done as direct rendering? Windowed and fullscreen?

Yes, one of the design goals of the DRI was accelerated windowed 3D. Sometimes a certain feature might only be available when fullscreen rendering (eg, page-flipping) but these are exceptions to the rule.

Another design goal of the DRI was multiple simultaneous 3D clients. At the moment you might lose hardware acceleration for some clients if you've got too many OpenGL clients running at the same time. It depends on the hardware.

Re:Antialiased fonts requires toolkit support???

[q000921]

The X11 protocol gives applications bit-accurate control over drawing. The spec doesn't just say that you call XDrawText and something vaguely resembling the text will appear in the window roughly where you want it to, it defines the exact way in which the text bitmap gets combined with the window contents. Furthermore, the X11 server is not permitted to allocate extra colors (grey values) just because it feels like it; the application may require control over those values itself.

The X11 protocol and Xlib are not at the level of abstraction of the Windows GDI, Postscript, or other, similar APIs; they are lower level. Anybody dealing with them needs to write a lot of code dealing with different device classes. In X11, you get a Windows GDI-like API, with all its conveniences and limitations, more at the level of the toolkits. Such toolkits can then provide you with antialiased rendering when available without code changes. GTK, Qt, fltk, and wxWindows all have hooks for putting this functionality in.

Re:Wouldn't you know it!

[GrenDel Fuego]

XFree just keeps getting better and simplier to config (xf86cfg is great for the first version) and in particlar many thanks to Keith Packard for the wonder render

Nevermind xf86cfg, have you tried "X -configure"? Spits out a usable X configuration file. You then just make whatever changes you want to it.

Re:Render

[keithp]

Render is a new rendering model for the existing windowing model; we'll need another extension for a shiny new translucent windowing model. The extension for that will be simple, but the internal reorganization of the X server will be rather gory. Exactly the opposite of the Render extension where designing the extension was the fun part and implementing it was straightforward.

As for Render, it's got everything but separate alpha, polygons and image transformations. Put another way, it's got just enough to manage anti-aliased text and alpha compositing images.

Volunteers to create software renderers for triangles, trapezoids and image scaling are welcome to help. For the polygons, all that I want is code that takes a triangle (or trapezoid) and generates an A or ARGB map, that way I can layer the result over existing compositing acceleration.

Re:Antialiasing support?

[q000921]

As far as I can tell, Microsoft didn't invent much of the typographical technology you point to--most of it came from Apple, Adobe, Bitstream, and many other sources.

As for doing antialiasing behind the scenes in an X11 server, a hack like that may work most of the time, but it deviates from the definition and may break some applications. Doubtlessly, the same thing was true when Microsoft added antialiasing to Windows, but Microsoft controlled the Windows API. Hummingbird doesn't control the X11 API and if they deviate from the specs in this way, they are simply providing you with a broken X11 implementation.

Re:Conspicuously absent...

[tolldog]

As some have said, there are nv drivers on the nvidia page.
But, in the notes, it think that it says that there are some problems with the GeForce2...
They have an opensource driver available on the page as well. It is for the XFree 3.x and not 4...

I know that the SGI Linux machines are now shipping with the GeForce2 cards and that the drivers are a combined effort of nVidia, SGI and VA.
I have been told that you can find better drivers on SGI's page by downloading some of the patches for the SGI Linux systems. This may not work. I went to far and messed mine up.

I have tried using the nVidia drivers with some software on my box and it seemed to be messed up.

If you can get any further, let me know.

Re:DGA support in XFree86 4.0 and above ...

[tjwhaynes]

The mouse support providing DGA 1.0 in XFree86 4.0.1 was subtly broken and gave jumpy and unpredictable mouse behaviour which was most noticeable in Quake 3, among others. This has been fixed in the CVS Xfree86 tree for a few months now and I assume therefore it is fixed in 4.0.2.

Cheers,

Toby Haynes

Re:Font antialiasing NOT compiled by default

[keithp]

FreeType 2.0.1 is sitting in XFree86 CVS, but it hasn't been included in the binary releases; there just wasn't time for the kind of integration and testing we would have liked. There aren't any license issues, FreeType2 uses a license which is compatible with the regular XFree86 license.

You need to build/install FreeType2 and then build/install the Xft library with FreeType2 support. Yes, this is a pain, but I expect Linux distros will include support by default.

Owen Taylor is hard at work getting Xft working with GTK+ 2.0, KDE has taken my Qt patches and incorporated them into their copy of the Qt tree. We're on our way to the magical land of anti-aliased text, and it's happening faster than I thought possible even a couple of months ago.

Re:Slashdot theft?

[Anonymous Coward]

>>never knew VA was a non-profit org

Not intentionally.
Bwahahahahahahahaahahahahah.

Re:(+1, Thanks!)

[nathanh]

only applications run with proper permissions can access the video hardware. DRI is a purely direct rendering interface

Correct.

it doesn't abstract away desctructive parts of the card (i.e. if users had access to the accelerated instructions, they could basically 'blit' a new kernel image from graphics memory, to get around the normal memory protection and security permissions).

False. Several of the drivers do special things because of these security issues. For example, cards with programmable DMA destinations have those parts of the cards hidden as kernel ioctls.

Because of this, you must be root, or applications must be setUID root in order to get direct rendering - otherwise they will render in software.

False. One of the design goals of the DRI was non-root direct hardware access. There is further discussion of this topic here.

http://www.precisioninsight.com/dr/drm.html

In particular... "The direct-rendering clients, however, do not run as root, but still require similar mappings. Like /dev/mem, the DRM device interface allows clients to create these mappings..."

Part of the purpose of projects like GGI/KGI have been the long-standing goal of creating a kernel API to allow as direct as possible access to the video card without allowing the user to damage the system.

The KGI has different design goals. It is closer in spirit to linux-fb. It is arguably not suitable for high speed 3D like the DRI.

Your understanding is a little flawed. There is some very good information on dri.sourceforge.net and www.precisioninsight.com. The whitepapers on Precision Insight's website are excellent.

Re:Darwin/Mac OS X???

[BLarg!]

I believe what it means is that X will compile and run under Mac OS X (as it does under WinNT). So you will be able to run your X apps on a mac.

-- BLarg!

Antialiased fonts requires toolkit support???

[kcbrown]

Or a separate library?

I'm about to talk out my ass, but...

This is ridiculous. Why not instead: design a separate font server protocol that takes the same font specification as the older font server and outputs a font with alpha information and set up the X server to automagically detect that the font server is talking the newer protocol and treat the font data as including alpha information, then render it appropriately to the screen.

As for fonts in the font path, just have the X server detect that the file is of the new alpha-capable format and deal with the font appropriately.

I mean, the whole point behind having an abstraction like the X server that deals with fonts is that the applications don't have to know things like whether or not the fonts are antialiased...they Just Work.

So please, tell me why this won't work, and why it's not being implemented this way.


--

Re:Antialiased fonts requires toolkit support???

[keithp]

Fonts in the core protocol are in much worse shape than you think.

• No advanced font information (like kerning tables)
• No standard way for applications to provide their own fonts (PDF documents can embed fonts)
• No support for vertical/diagonal escapements

The first problem would have required a significant new extension to codify the information available in current font files and still not solve the problem for future font file formats.

The second has traditionally been solved by creating an application-specific font server. What a kludge.

The third would be relatively easy to add to the existing core fonts, but would have required requests to transmit the new metric information.

Instead of a collection of ugly kludges, a new font mechanism was created placing the burden for locating and loading fonts squarely in the clients space while the X server handles what it does best -- drawing stuff on the screen. While this has been done in the context of the Render extension, the advantages for applications and toolkits is enormous. You should see Owen's changes to Pango using this stuff, he's able to directly access the font file information for composing glyphs together.

However, I agree that building a system which makes all font handling dependent on the toolkit is a bad idea. Towards this end, I've started on the Xft library which is the part of XFree86 designed to make font file access and glyph rasterization consistent across all X applications. Applications are free to go around Xft and do their own thing, but Xft is a thin enough layer and provides transparent access to the FreeType library which accesses the font files so I think this won't happen. I've built Xt applications, changed Tk and Qt and seen changes to GTK+ all using Xft. The results provide identical glyph images and a single location for font configuration throughout my desktop.

Probably the biggest advantage of the new system is that even if the current Xft library turns out to be irreparibly broken, we can pitch it on the scrap heap and start over without changing the X server. Extensions are hard to get propagated to every desktop; libraries can be shipped with applications and installed without trouble.

I added sub-pixel sampled text with very minor changes to the Render protocol; I can add sub-pixel positioned text without any changes at all. Glyphs are now rasterized on-demand, rather than having the entire font done when opened. This means using 10646 encodings is finally feasible within X; Qt, Tk, Java all use 10646 internally, now X can support that natively with no tremendous performance hit.

This can be viewed as the Unix lesson all over again; parts of the system which can easily be done outside of the "kernel" (X server) should probably be done there. In this case, the advantages are overwhelming.

do they even READ story submissions?

[itarget]

For a while there I was afraid slashdot wasn't even interested in announcing this release.

When they started putting the build online:
2000-12-19 03:22:54 XFree86 4.0.2 release(ing?) (articles,x) (rejected)
When they finished putting the build online:
2000-12-19 22:55:45 XFree86 4.0.2 is out (articles,x) (rejected)

Go figure. :-P
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.

Re:Antialiasing support?

[QuoteMstr]

No, just the toolkits. Recently, there was even a patch for XEmacs posted that allowed this to work with it.

Still missing...

[psergiu]

- standard S3 support (LOTS of "business" PCs found in companies have S3 cards - the one i am writting this onto has a s3trio64v2)

- mono / 1bpp framebuffer / hercules support. 3.9.x had it. It vanished beginning with 4.0.1.

- an option for "DO NOT blank the damn text console/tty you're starting on". I have at home a dualhead system (one matrox + one hercules :) and there is NO way i could have one X (matrox) and one text (hgafb) setup. X will blank the text console at startup.

- extensive documentation :)

Other than that - it's K3Wl !


--

Comment removed

[account_deleted]

Comment removed based on user account deletion

Wouldn't you know it!

[_ganja_]

I spent last night downloading XFree864 from CVS and compiling, now binaries are out! Well, I did it for anti-alias support anyway so no loss.

I'm writting this using KDE2's konqy fron CVS (also last night) with anti alias text and it looks great.

There is a real easy way (?) to set this up without applying patches to QT etc. A Simple HOWTO based on what I did is below HOWEVER, I have no idea if this is needed for the final 4.0.2 release.

Download, make and make install freetype2 from www.freetype.org, this should be a recent CVS checkout or snapshout, i used this: ftp://freetype.sourceforge.net/pub/freetype/unstab le/freetype2-current.tar.gz

Download X in source form, create the file:
xc/config/cf/host.def

To have this line:
#define Freetype2Dir /usr/local

Make and install X with make World & make install.

Get an updated qt that contains the patches to use the new render, the easiest way to do this is to do a qt-copy checkout from kde's anon CVS. This already has the patches applied and a configure option to turn on render use.

Configure qt with:
./configure -xft -sm -gif -system-jpeg -no-opengl -no-g++-exceptions

make QT...... You now have a QT with render support, anything you compile against it will get anti-aliased text including the whole of KDE2.

Good luck!

Stromboli

[JCCyC]

(...) this new release adds the Render extension which will hopefully give us anti-aliased fonts, alphablended menus, and a stromboli delivered nice and hot to your door.

Why would I want a volcano delivered to my door?

Slightly off topic: holding Debian packages

[TrentC]

There's a file you can edit to change this, however I can't quite remember what it is as my Slackware machine doesn't have it.

I think its either
/etc/X11/xdm/serverrc
or
/etc/X11/xinit/xserverrc

probably the first one, I'm pretty sure its xserverrc though

I don't know how different the distros are, but on Debian it's located in /etc/X11/xinit/xserverrc. I just tweaked it myself.

If you're only going to use the 75 dpi fonts on Debian, you may want to deinstall the xfonts-100dpi package, and put it on hold so that apt-get doesn't download newer versions of it as well. (This is how I was preventing the 100 dpi fonts from showing up previously...)

An easy way to hold packages in general:

# dpkg --get-selections > installed.txt

This will dump a list of all of the packages and their status (install, deinstall or hold; purged packages don't show up on the list). Edit the list with your favorite text editor, replacing "deinstall" or "install" with "hold" and then:

# dpkg --set-selections < installed.txt

Jay (=

Re:Conspicuously absent...

[amccall]

ATI is providing specs and paying VA Research(I believe) to develop open source drivers. NVidia has decided to keep their drivers closed source.

However, there is a GeForce2 driver in the release, but the acceleration is little, due to the simple fact that their are not specs for an opensource GeForce2 driver. (IE: the people that developed the closed source GeForce driver, can't talk about it...) Also note, that the Radeon driver does not yet provide 3d DRI support, and that is forth coming.

Three cheers to the DRI and XFree86 guys for their continued hard work, which trully shows in this product. Please let the mirrors update, though.

Happy downloading.