Slashdot Mirror

← Back to Stories (view on slashdot.org)

XFree86 4.0.2 Released

Posted by CmdrTaco on from the get-it-while-it's-hot dept.

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.

10 of 249 comments (clear)

  1. I think you're confused. by bconway · · Score: 5

    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.

    --
    Interested in open source engine management for your Subaru?
  2. Re:Font antialiasing NOT compiled by default by keithp · · Score: 5
    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.

  3. Re:very confused... by nathanh · · Score: 5
    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.

  4. Re:Slashdot theft? by Anonymous Coward · · Score: 5

    >>never knew VA was a non-profit org

    Not intentionally.
    Bwahahahahahahahaahahahahah.

  5. Re:(+1, Thanks!) by nathanh · · Score: 5
    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.

  6. Re:very confused... by amccall · · Score: 5

    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.

    --
    ------ 24.5% slashdot pure
  7. Re:Antialiased fonts requires toolkit support??? by keithp · · Score: 5
    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.

  8. Comment removed by account_deleted · · Score: 5

    Comment removed based on user account deletion

  9. Wouldn't you know it! by _ganja_ · · Score: 5

    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!

    --

    A journey of a thousand miles starts with a brutal anal raping at airport security

  10. Re:Conspicuously absent... by amccall · · Score: 5
    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.

    --
    ------ 24.5% slashdot pure