Slashdot Mirror

← Back to Stories (view on slashdot.org)

New XFree86 snapshot - 3.9.17

Posted by Hemos on from the go-out-and-get-it dept.

MartinG was one of many people who wrote with the news that XFree86 has released 3.9.17. It's availible on their ftp server and features some relatively minor changes since 3.9.16. Still leading up to the promised 4 release, but that should be happening in the near future.

4 of 295 comments (clear)

  1. 3.9.17 is much more modular by kzin · · Score: 5

    From the Release Notes:

    Unlike XFree86 3.3.x where there are multiple X server binaries, each of
    which drive different hardware, XFree86 3.9.17 has a single X server binary
    (called XFree86). This binary can either have one or more video drivers
    linked in statically, or, more usually, dynamically load the video drivers
    and other modules that are needed.

    and

    The XFree86 X server has a built-in run-time loader, donated by Metro Link
    http://www.metrolink.com. This loader can load normal object files and
    libraries in most of the commonly used formats. Since the loader doesn't
    rely on an operating system's native dynamic loader support, it works on
    platforms that don't provide this feature, and makes it possible for the mod-
    ules to be operating system independent (although not, of course, independent
    of CPU architecture). This means that, for example, a module compiled on
    Linux/x86 can be loaded by an X server running on Solaris/x86, or FreeBSD, or
    even OS/2. One of the main benefits of this is that when modules are
    updated, they don't need to be recompiled for each different operating sys-
    tem.

    This means the video drivers are standardized... Maybe this will encourage video card vendors to include an XFree86 driver along with the MS-Windows ones.

    - Adi Stav

  2. Did Slashdot just step sideways? by ajs · · Score: 5

    Is this a change-of-year thing? I'm seeing people posting "XFree86 sucks because I'm not on the development team", "XFree86 sucks because I don't like UNIX domain sockets", "KDE smokes X"

    And these are the ones that got moderated UP?!

    Look, first, if you don't like the way development is going, grab the source, and do it yourself. Don't necessarily fork the entire project, just take over your corner, and do whatever you like. Keep it in CVS, and merge the new releases in on a vendor branch.

    Second, four letters: XSHM

    Third, KDE is several layers above X, and requires X to run, so what the heck do you mean SMOKES?

    Please, people, do try to pull it together, here.

    Imminent demise of Slashdot predicted. Film at 11.

  3. Someone didn't spend much time reading... by John+Fulmer · · Score: 5

    PI's web site. Here's a rundown from one of their graphics It lists several different paths through the X system that can be programmed for.

    3D Direct Rendering

    -Raw OpenGL compat Rendering Library -> Hardware
    -GLX/DRI -> Kernel Module -> Hardware
    -XLib -> X Transport -> X Server -> Hardware

    X11 2D (Normal X)

    -XLib -> X Transport -> X Server -> Hardware

    3D Indirect Rendering

    GXLib -> X Transport -> X server -> Hardware
    XLib -> X Transport -> X Server -> Hardware

    So while, yes 2D is done the same old way, There are many new 3D options available, including bare wire access to the hardware.

    Two items on the NT video subsystem:

    Note that one of NT's major sources of instabilities is in its video drivers. Any wrong call inside the driver can and does blue screen the box. With X's user-space model, this can't happen easily. There is a trade off on performance, but with X you get stability, multiple screens, and native network windowing, with the tradeoff being in having to use an asynchronous display instead of a synchronous display. (Displaying graphics synchronously gives faster graphics at the expense of CPU)

    Also note that DRI is essentially an improved version of SGI's GLX implementation on Irix (SGI's version of Unix), which ABSOLUTELY SMOKES 3D rendering on NT, on neo-equivalent boxes. If you've never seen 3D done on a SGI O2 or better, you haven't seen good 3D. X isn't such a dog then... :)

    jf

  4. Re:Yes, time to fork. by extrasolar · · Score: 5
    "It is time to GPL the damn thing."

    The FSF advises against it. See The X Windows Trap. I quote:

    "When you work on the core of X, on programs such as the X server, Xlib, and Xt, there is a practical reason not to use copyleft. The XFree86 group does an important job for the community in maintaining these programs, and the benefit of copylefting our changes would be less than the harm done by a fork in development. So it is better to work with the XFree86 group and not copyleft our changes on these programs. Likewise for utilities such as xset and xrdb, which are close to the core of X, and which do not need major improvements. At least we know that the XFree86 group has a firm commitment to developing these programs as free software."


    So if even RMS advises against GPLing the X Windows System then it is probably not a good idea ;)