Slashdot Mirror

Has anyone used any of the pre-4.0 snapshots on an SGI 1600SW w/ the Number Nine TTR IV?

Unlikely, given that the Number Nine section of the driver status document says:

4.0:

No native support for these chipsets, because the old driver has not been ported.

Summary:

No Number Nine chips are supported in 4.0.

The release notes say:

This release isn't quite as complete as we would have liked. The main missing pieces are a nice configuration tool and support for some of the hardware that 3.3.x supports. The first point means that configuring the server might be more painful than usual. The second means that your hardware might not be supported by 4.0, or it might be supported at a lesser level (conversely, some hardware is better supported in 4.0). We've attempted to provide some information about the second point in our Driver Status document. Please check there first before trying 4.0. Unfortunately that document is still fairly basic, but it should at least give you an idea of whether you're likely to be able to use 4.0 at all or not.

which might (from the "as complete as we would have liked") indicate that support for the Number Nine cards, and other cards not supported in 4.0, may arrive in a later release.

Has anyone used any of the pre-4.0 snapshots on an SGI 1600SW w/ the Number Nine TTR IV?

Unlikely, given that the Number Nine section of the driver status document says:

4.0:

No native support for these chipsets, because the old driver has not been ported.

Summary:

No Number Nine chips are supported in 4.0.

The release notes say:

This release isn't quite as complete as we would have liked. The main missing pieces are a nice configuration tool and support for some of the hardware that 3.3.x supports. The first point means that configuring the server might be more painful than usual. The second means that your hardware might not be supported by 4.0, or it might be supported at a lesser level (conversely, some hardware is better supported in 4.0). We've attempted to provide some information about the second point in our Driver Status document. Please check there first before trying 4.0. Unfortunately that document is still fairly basic, but it should at least give you an idea of whether you're likely to be able to use 4.0 at all or not.

which might (from the "as complete as we would have liked") indicate that support for the Number Nine cards, and other cards not supported in 4.0, may arrive in a later release.

If everyone keeps hitting the main FTP site instead of one of the mirrors, the stuff'll never replicate.

Here's a hint: Mirror List

http://www.au.xfree86.org/4.0/RELNOTES. html

Enjoy. Congrats and thanks to the XF86 team

Eric

(here's the introduction/installation instr. for those with mirror probs):

XFree86 4.0 is the first official release of the new XFree86 4. XFree86 4 represents a significant redesign of the XFree86 X server. It is very important to keep in mind that XFree86 4 is still very much in development, and it contains a lot of new work. That means two things: there is a lot of new exciting stuff to try, but being new code, it hasn't had nearly as much of a workout as the stable 3.3.x releases. If you're looking for a well-tested, stable release, and can't afford the inconveniences that new software can sometimes cause, then you are probably better off sticking with the 3.3.x releases for now. If you have the resources to try out the new version and investigate its features, or if you just like being on the bleeding edge, then please try 4.0!

This release isn't quite as complete as we would have liked. The main missing pieces are a nice configuration tool and support for some of the hardware that 3.3.x supports. The first point means that configuring the server might be more painful than usual. The second means that your hardware might not be supported by 4.0, or it might be supported at a lesser level (conversely, some hardware is better supported in 4.0). We've attempted to provide some information about the second point in our Driver Status document. Please check there first before trying 4.0. Unfortunately that document is still fairly basic, but it should at least give you an idea of whether you're likely to be able to use 4.0 at all or not.

On the subject of configuration, we have updated the basic text-based tool "xf86config" to generate config files in the format required by 4.0 (3.3.x config files won't really work with 4.0). We're also working on some other configuration tools, including one that is built-in to the X server. An early version of this is included in the release, and it works well for some hardware. To try it out, just run (as root) "XFree86 -configure". Both of these configuration options will at worst give you a reasonable starting point for a suitable configuration file. We've put some effort into documenting the 4.0 config file format, and you can find that information in the XF86Config manual page. Please check that and the driver manual pages and related documentation for further information about that.

Oh, another thing you might notice is that our documentation is rather patchy. Most of what is present should be in reasonable shape, but there are gaps. We thought it better to leave out docs that were very out of date rather than providing inaccurate and misleading information.

Finally, before you download and install the binary distributions for this release, please have a quick read through the Installation Document. It may save you some time. If those cautionary notes haven't turned you away (and we certainly hope not), please read on... The sections below describe some of the new features and changes between 3.3.x and 4.0. There is a lot of new stuff, and we definitely don't have enough space to cover it all here.

Want to work at Transmeta? Hedgefund.net? Priceline?

XFree86 is just one implementation of X,

True.

specifically for x86 platforms.

False. On the home page of XFree86, it says:

The XFree86 Project has traditionally focused on Intel x86-based platforms (which is where the `86' in our name comes from), but our current release also supports other platforms. One of our current goals is to increase the range of platforms that XFree86 runs on.

Note, for example, that the list of systems on which XFree86 has been tested in the XFree86 3.3.6 README includes "Linux (Intel x86, DEC Alpha/AXP and m68k)" (emphasis mine).

XFree86 is just one implementation of X,

True.

specifically for x86 platforms.

False. On the home page of XFree86, it says:

The XFree86 Project has traditionally focused on Intel x86-based platforms (which is where the `86' in our name comes from), but our current release also supports other platforms. One of our current goals is to increase the range of platforms that XFree86 runs on.

Note, for example, that the list of systems on which XFree86 has been tested in the XFree86 3.3.6 README includes "Linux (Intel x86, DEC Alpha/AXP and m68k)" (emphasis mine).

Summary of new features in 3.9.17 compared with 3.9.16: http://www.xfree86.org/3.9.18/RELNOT ES2.html

Summary of new features in 3.9.16 compared with 3.9.15: http://www.xfree86.org/3.9.18/RELNOT ES3.html

Chris Hagar

Summary of new features in 3.9.17 compared with 3.9.16: http://www.xfree86.org/3.9.18/RELNOT ES2.html

Summary of new features in 3.9.16 compared with 3.9.15: http://www.xfree86.org/3.9.18/RELNOT ES3.html

Chris Hagar

Summary of new features in 3.9.17 compared with 3.9.16: http://www.xfree86.org/3.9.18/RELNOT ES2.html

Summary of new features in 3.9.16 compared with 3.9.15: http://www.xfree86.org/3.9.18/RELNOT ES3.html

Chris Hagar

ftp://ftp.xfree86.org/pu b/XFree86/snapshots/3.9.17/binaries/

has binaries for
FreeBSD-2.2.x and 3.x
NetBSD-1.3
Linux on Alpha/Intel, glibc only.
Solaris

They're .tgz packages. tar -zxf 'em from root. If you have a copy of Slackware pkgtool floating around you can use that. Otherwise, there are a number of small utils that will convert them to .rpm for you.

If there isn't one for you (eg, you still have a libc system) download the source. It's a usually a simple make World && make install && make install.man. Be warned, on a K6-2 500 the process took a few hours. Oh yeah.. The funny looking INSTALL.TXT file is actually nroff formatted. 'nroff INSTALL.TXT | less' works.

See section 2.1 of the 3.9.17 relnotes
--

Gee, I could swear I submitted this late yesterday when the file tree changed..

Anyway, the source can be had here, and you really should read the release notes here once they appear.

No real info is available on what exactly is new in 18: Any XFree developers here that can fill us in?

Gee, I could swear I submitted this late yesterday when the file tree changed..

Anyway, the source can be had here, and you really should read the release notes here once they appear.

No real info is available on what exactly is new in 18: Any XFree developers here that can fill us in?

http://www.xfree86.org/3.3.6/SiS2.html#2

Information for SiS Users : Supported chips
Previous: Introduction
Next: XF86Config Options

2. Supported chips

SiS 86c201

(External hardware clock)

SiS 86c202, SiS 86c2x5, SiS 5597/5598, SiS 6326, SiS 530, SiS 620

(Internal clock synthesizer)

Color expansion is not supported by the engine in 16M-color graphic mode.

Information for SiS Users : Supported chips
Previous: Introduction
Next: XF86Config Options

It's called documentation.

We all know it, XFree86

XFree86 is a freely redistributable implementation of the X Window System that runs on UNIX(R) and UNIX-like operating systems (and OS/2). The XFree86 Project has traditionally focused on Intel x86-based platforms (which is where the `86' in our name comes from), but our current release also supports other platforms. One of our current goals is to increase the range of platforms that XFree86 runs on.

This project does, and continues to be everything we need. With out these programmers *nix would be sitting in the dust of Microsoft. Version 4.0 is the most anticipated version yet; I know I'm salavating over the next release!

A quick gander at their faq says nothing about this.

Specifically, what is the difference between:

• 3.3.x (such as 3.3.6)
• 3.9.x (such as 3.9.17)
• 4.0.x (yet to be released)

thanks,
donfede

Freshmeat has a stale link. The 3.3.6 release notes are here.

definitely a hero, definitely unsung. he's been working on xfree86 for eight years. we all use X. although you'd really want to give the gong to all four founders of the project.

How about ftp://ftp.xfree86.org/p ub/XFree86/snapshots/3.9.17/RELNOTES......from the document itself: "This document contains some information about the features present in XFree86 3.9.17 and their status."

OK Jackass here you go.

http://xfree86.org/developer.html

That page tells you how to sign up for membership. They say they'll allow anyone who seriously wants to develop or beta test. So tell them you're serious. Have some 3D hardware? Offer to test out their new rendering structure. But first, pull your head out of your ass.

Wanting development code 'for the hell of it' is not a good thing. People who go grab what's called unstable and then gripe about it not working suck. What's worse is how many of them do that and STILL don't report problems they find. People looking for something to do should either learn to develop or beta test for real. The first one may not be for everyone, but the second just means you need to submit some bug reports.

So there's your CVS access. I don't know if you're 'good' enough, your attidude really doesn't imply that you are.

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

as the homepage says, "XFree86 3.3.6 will be release in parallel with 3.9.17 as well." So expect 3.3.6 very soon, too. It'll be located here more than likely

bye,
-jimbo

KDE is the desktop environment. It runs on top of XFree86, which is what controls the overall graphics. When you say that KDE is better than XFree86, you must be confusing XFree86 with Gnome, another desktop environment available under and the X Window system.

KDE is the desktop environment. It runs on top of XFree86, which is what controls the overall graphics. When you say that KDE is better than XFree86, you must be confusing XFree86 with Gnome, another desktop environment available under and the X Window system.

KDE is the desktop environment. It runs on top of XFree86, which is what controls the overall graphics. When you say that KDE is better than XFree86, you must be confusing XFree86 with Gnome, another desktop environment available under and the X Window system.

Last I heard Dirk was still working for SuSE. At least, that's what it says here.

Chris

Too bad 9 is bankrupt. The i128 series was and is a great card.

-jwb

XFree86 3.9.x and 4.0 will support this. It is a module that scans the monitor hardware and uses the modeline info returned. Only some drivers support it for now though. See http://www.xfree86.org/snaps hots/3.9.16/RELNOTES1.html for details...

Just a friendly comment, but bug reports are always welcome on the XFree86 releases. Especially if you see such a mouse problem. There's work going on toward 3.3.5+ and if you've seen problems in 3.3.5 it's worth sending a bug report to XFree86. Include a server log also so that they can track what hardware/version you have running.

The XFree86 Project, Inc. was a member of the X Consortium of old, too. At least in 1994 UUNET sponsored them and contributed the membership fee. So belonging to a standards body isn't anything new to them.

Actually, I'm kind of shady on the details of how they lost that membership. Could someone more knowledgeable tell what exactly happened when TOG took over X? I was under the impression that the new X.Org had more or less the same members as the X Consortium. Apparently not...

It is entirely possible the people at Sun, IBM, HP, Compaq, (and possibly others) decided that as they're supporting Linux from other perspectives, that the needed to tell TOG that it needs to as well.

Convincing signs of a TOG "change of heart" would include things like:

• Defining UNIX 1999 or UNIX 2000 in such a way that Linux systems could become branded as UNIX, rather than their current comments
• Releasing Motif/CDE in Open Source form.

Shameless Plug: People should help Sponsor XFree86. My local Linux Users Group, NTLUG, is in the process of soliciting that members help sponsor several free software project organizations, including XFree86.

ATM all one can do with geforce is vga16, because it dosn't seem to VESA compliant!! I've heard rumors, that Xfree 3.9.17 will have support for it, but there no notice when it will come out... Sure, last Xfree snapshot was just 31. August, and they proomised to do a snapshot every 6 weeks and that is already due... Maybe I'm too impatient, but owning the fastest card in the block and only beeing able to use it fully on windows...

much (most?) of the software that the Debian team puts in the DebianBSD distribution would still be GPL, which means FastBuck Inc. would not be able to take DebianBSD as-is and apply a closed-source license.

This is better than the opposite observation that I was going to point out, which is that there are components of Debian, such as Perl, Python, and XFree86 that already use non-GPL-like licenses.

Xfree86 has full support for Wacom input devices, because Wacom is one of the sponsors of the XFree86 project.

With the foundation in place, XInput support for the Gimp is in progress -- for more info, check out this and this. One thing to remember-- if the tablet has control over the core pointer in X, you can still use it to draw without the pressure sensitivity. Which is still a thousand times better than drawing with a mouse.

I have been using a Wacom ArtPad (supported quite nicely in XFree86) for over a year now. The best thing about a pen tablet is that it is not a mouse -- you can jump to any point on the screen in the time it takes to shift your hand. Though it took a while to get used to the buttons on the pen (and they still kinda annoy me), it has made working at the computer much more comfortable (not to mention, it has increased my Starcraft dexterity exponentially -- i can repair 12 bunched wraithes with no missed clicks. Though it kinda blows for quake...)

To me, this new pen combines all the disadvantages of a mouse and a pen into one. The worst thing about mice is the mouse ball by far -- it always gets dirty, it requires you to use the same amount of force constantly. Like all pens, it has those annoying buttons.

If you use a Wacom tablet, the serial port connects to the tablet -- not the pen. All that fancy radio hardwire, besides sounding like a frustration in the wings (interference = no mouse!), really doesn't offer you anything that different from what already exists.

Drivers exist because Wacom has done the sensible thing by sponsoring the XFree86 Project. Plus, WACOM is a respected manufacturer that is more or less the standard for graphic designers worldwide.

I doubt the cable from the tablet to the serial port will really bother you that much. Of course, if it does, check out the graphire. And if you want something to really make you drool, check out this.

I have been using a Wacom ArtPad (supported quite nicely in XFree86) for over a year now. The best thing about a pen tablet is that it is not a mouse -- you can jump to any point on the screen in the time it takes to shift your hand. Though it took a while to get used to the buttons on the pen (and they still kinda annoy me), it has made working at the computer much more comfortable (not to mention, it has increased my Starcraft dexterity exponentially -- i can repair 12 bunched wraithes with no missed clicks. Though it kinda blows for quake...)

To me, this new pen combines all the disadvantages of a mouse and a pen into one. The worst thing about mice is the mouse ball by far -- it always gets dirty, it requires you to use the same amount of force constantly. Like all pens, it has those annoying buttons.

If you use a Wacom tablet, the serial port connects to the tablet -- not the pen. All that fancy radio hardwire, besides sounding like a frustration in the wings (interference = no mouse!), really doesn't offer you anything that different from what already exists.

Drivers exist because Wacom has done the sensible thing by sponsoring the XFree86 Project. Plus, WACOM is a respected manufacturer that is more or less the standard for graphic designers worldwide.

I doubt the cable from the tablet to the serial port will really bother you that much. Of course, if it does, check out the graphire. And if you want something to really make you drool, check out this.

Its always best to check the XFree project's website for updates. They have no set date for release yet, but they do have snapshots available for download. Its worth checking it out!

http://www.xfree86.org

: I don't know any of the technical details, as I'm
: less of a coder than anything else, but isn't X
: generally a "client-server" display system?

It was XML, not X, the individual was referring to. They are different things entirely.

XML Information
X Windows Information

I could crash XF86 with switching from some SVGALIB app(like quake I in console mode) to X .

Accelerated X has its uses in the portable market but that's about it, most Graphic cards are supported under XF86 and I can't seem to find a reason to pay for something I don't have any extra benefits from. For a list of supported cards, look here.

--

XFree86 4.0 will have Precision Insight's Direct Rendering Interface which will bring Linux 3D framerates on par with Windows. Precision Insight has even hired Mesa's Brian Paul to bring his experience to the project. The day is coming when Linux will achieve gaming parity with Windows...

A XFCom X server for Linux is available for the single Rage 128 at Suse. I believe it will probably mainline in the next version of the XFree86 server, it seems quite stable. This should mean that most of the information for the dual processor version is already known, so hopefully a driver will follow quickly.

If you mean DRI and GL support, that's coming in version XFree86 v4.0, which hasn't announced a release date. The next snapshot, 3.9.17 should be available mid-month according to the XFree86 page.

The second is that a common printing system for UNIX does exist--but not for Linux. It's called XPRINT,

Define "printing system". Section 1.1 of the X Print Service Extension Library documentation says

Several keywords and concepts used in this specification were borrowed from the abstract standard ISO 10175, the subsetted standard and implementation represented by POSIX 1387.4, and the yet further subsetted implementation represented by OSF Palladium. The X Print Service does not attempt to duplicate the functionality or APIs provided by any of these print subsystems, or by any other print subsystems such as System V lp or BSD lp. It does, however, attempt to allow implementations to work with these print subsystem, and its architecture is open enough to allow tighter binding to a specific print subsystem in the future.

CUPS is a "print subsystem such as System V lp or BSD lp[sic]"; XPRINT generates stuff to feed to a printer, and a print subsystem such as the SV or BSD one, or CUPS, queues up that stuff when handed it, and feeds it to a printer.

So XPRINT isn't enough to do printing; you need a print spooling system, as well as a system for actually generating a file containing instructions to a printer telling it what marks to put on a sheet of paper (or what stuff to send over a fax modem, or whatever). CUPS is, among other things, a print spooling system; an X Print Server will probably assume that a print spooling system exists and that it should hand print jobs to that system.

You could debate whose job it should be to turn printer-independent drawing instructions into the appropriate drawing instructions for a particular printer; if somebody wants to argue that XPRINT should do that, they'll have to demonstrate that it's OK to require all programs that print more than just plain text to be linked with Xlib and company, and to be run in an environment that has X Print Servers handy (be prepared to have to respond to people who do not want to be required to do that, and may even have good reasons not to want that).

Oh, and I don't consider it a "UNIX standard" until I can rely on it being on all UNIX systems, even if I'm, say, in an environment where all the UNIX systems are headless servers.

before anyone flames me, read the docs for XPRINT,

I did (which I was able to do, because I happen to have Frame Maker; has anybody converted the various X specs written in Frame into a format that those who don't have Frame can read, and made them publicly available?), and they specifically indicate that XPRINT isn't a print spooling system.

Someone PLEASE write an XPRINT module for XFree.

What's missing? The XFree86 3.3.5 release notes say

XFree86 releases starting with the 3.2A beta are based on the X Consortium's X11R6.3 (the final release from the X Consortium).

R6.3 is an update to R6.1, and is intended to be compatible with R6.1 and R6 at the source and protocol levels. Binaries should be upward-compatible. X11R6.3 includes some new Xserver extensions: SECURITY, XC-APPGROUP, XpExtension (print extension), ...

Yes, he probably did, in fact.

That would be a neat trick.

Not all that tricky if the video card and monitor support the VESA Display Data Channel standard and the video card can get enough information from the monitor that way to let the host identify it.

I haven't bought the standards in question from VESA (they aren't cheap), so I don't know what sort of information you can get from plug-and-play monitors, but check out the VESA standards page.

It looks as if support for DDC, and at least some of the information you can get from it, may show up in XFree86 4.0; see this item in the XFree86 3.9.16 release notes.

I've been thinking the past week or two that if Apple can keep up their lead on the processor market as they clearly plan to (of course I'm still confused as to why IBM and Motorla make chips for Apple), owning a Mac might not be so bad (even if most of their stuff nowadays looks like it was built by space aliens IMHO). I also thought it was interesting that they were supporting a project, MkLinux, with The Open Group (not that I've ever been a big fan of TOG).

Of course, this old article made me laugh a bit. Use MacOS for graphical applications? Why bother with a dual boot? TOG, of all people, should know you can run graphical applications on Linux. After all, they're the ones who put together X.Org to maintain the official X stuff (TOG getting X.. ugh..). Seems kind of silly to me.

It seems like a smart move to Apple, though, to support Linux. After all, if they can have Linux running on their machines, and have superior hardware to what's already out there, they could tap some potential markets (especially if they have modems on their computers.. I'm so sick of Linux "desktops" without modems because the computer makers love winmodems, which is something I'm sure that Apple doesn't subscribe to, at least, as their machines obviously don't run Windows).

P.S. Yes I realize the "X" link leads to the XFree86 site. I have my reasons, but I don't want to explain them, ok? :)

ftp.xfree86.org/pub/XFree86/snapshots/3.9.16/

Try Here.

PI is working with the Xfree86 team on a hardware accelerated GLX module for Xfree 4.0. The support wasn't in the pre-release 3.9.15 but they said that it would be in an upcoming pre-release. The stuff that suse is working on is called MLX and it hasn't been updated in months but it still works(sorta, full screen only) on my Diamond FireGL 1000 pro.

PI is working with the Xfree86 team on a hardware accelerated GLX module for Xfree 4.0. The support wasn't in the pre-release 3.9.15 but they said that it would be in an upcoming pre-release. The stuff that suse is working on is called MLX and it hasn't been updated in months but it still works(sorta, full screen only) on my Diamond FireGL 1000 pro.

PI is working with the Xfree86 team on a hardware accelerated GLX module for Xfree 4.0. The support wasn't in the pre-release 3.9.15 but they said that it would be in an upcoming pre-release. The stuff that suse is working on is called MLX and it hasn't been updated in months but it still works(sorta, full screen only) on my Diamond FireGL 1000 pro.

Although I suppose that this goes back to ESR & RMS's ongoing debate about open source v. free software, last year's aborted X11R6.4 licence change makes me somewhat sceptical of The Open Group as any kind of reputable open source (nevermind free software) developer. Although they seem to have recanted, (see www.xfree86.org) I think a suggestion to developers that they go and clear all their ideas via the The Open Group and try to get them to initiate X12 to integrate them in; is going to leave a bad taste in many people's mouths.

As for the suggestion that using Motif is a good path for open software development (even with Lesstif coming on apace), try telling that to the Mozilla developers.

However I do agree that as a mature standard X11 has a lot to offer and further would respectfully suggest that many of the more vocal "let's get rid of X" proponents don't understand exactly what they are proposing to chuck out (as opposed to the developers etc. who are doing less talking and more coding).