Slashdot Mirror
New XFree86 snapshot - 3.9.17
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.
X development is way too closed. I can get a kernel snapshot all the time but can't get a snapshot even if it has some major fixes. And too me a kernel seams a lot more critical. More stuff can go wrong with a bad kernel than a bad X server. I wish they would release what they could much more often.
It has been statistically shown that helmets increase the risk of head injury.
You might want to look into how this stuff works a bit more before you spout off like that...
--
The unsig!
Actually i am aware that KDE runs on top of X i gust prefer using KDE and find that KDE's feature are better that X
How can the features be better or worse? They're two totally different things.
X is a display server, it manages video card and input devices.
KDE is a window manager, is manages the look/feel of windows, their movement, etc.
How can you say what you're saying? Window Managers cannot be better or worse then X, as they are not equal.
Don't compare apples to oranges.
-- iCEBaLM
Oh yes, kde smokes xfree...
For those not very familar with the X Windowing System (the linux user group of north alabama has a good writeup by the way, drop by http://luna.huntsville.al.us/faq and go to the X section), a quick briefing of what makes up X:
- X server: talks to graphics system, keyboard, mouse, etc
- X clients: all other programs that talk and request resources from the X server
- toolkits: scroll bars, text input, all sorts of things like this. GTK, QT, and motif are examples
- window managers: let the user manipulate the windows present on his display. TWM, FVWM, WindowMaker, Enlightenment, KWM, etc. (KWM is KDEs window manager)
Up until a few years ago, open source "deskop enviroments" weren't really available (GNOME and KDE are opensource examples). These enviroments often use a toolkit, consistent ui guideliness, and have methods of letting apps talk to eachother easily. They also sometimes include window managers (KDE uses KWM, and recently others can be used as well; GNOME has always sought to be "window manager independent," meaning that if you have a supported wm, you get extra features. If not, you just don't have the extra features.
Hope that clears a few things up!
cfrost@hiwaay.net (my domain is currently down...)
As someone who uses X basically to run half a dozen Xterms, Netscape, and occasionally the Gimp, what's the advantage to upgrading to 4.0?
It seems that loadable modules for font rasterizers, etc., would make the initial setup easier, but once that is up, what's the difference to someone who doesn't use 3D or any other sort of "multimedia?"
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
you should really update to the 3.9 tree, the matrox drivers are considerably faster (especially over the ones in accelx)
--
Geoff Harrison (http://mandrake.net)
Senior Software Engineer - VA Linux Labs (http://www.valinux.com)
Geoff "Mandrake" Harrison
Some Random UI Hacker
XFree is being developped under the BSD development model -- cathedral style -- and released under a BSD (X) license. The two are not necessarily bound.
Apparently, the XFree developer fear that people start looking at their development sources. I remember, a few years ago, they only made time-bombed binaries available for their beta-version! Given the success that projects like Linux, KDE and Gnome have shown using a completely opposite strategy, we have every reason to believe that such a model would work better.
And no, before someone mentions it, I'm not karma-whoring: I actually considered working on XFree, I was interested in working on TrueType support, which has been since then released. But I could'nt even find a mailing list archive from their site! So I had no way to find out what was being worked on, which issues there was, or who to contact.
Will hardware accelerated 3d work with a G400 and dri in this release? Do I just use the glx module?
Or do I download the glx module from the glx website and use that one?
It has been statistically shown that helmets increase the risk of head injury.
major.minor.patchlevel
that's what the version number means.
--
Geoff Harrison (http://mandrake.net)
Senior Software Engineer - VA Linux Labs (http://www.valinux.com)
Geoff "Mandrake" Harrison
Some Random UI Hacker
http://glx.on.openprojects.net
you can do direct rendering with matrox and rage pro cards already with xfree 3.3.5
In any case I'd wait for 4.0 before forking if I were you. Unless it really takes forever to turn up, that is. Forking right before the XFree86 team comes out with a major new update seems like a recipe for needles integration trouble.
And finally: only the current copyright holders can change a license (and only if they all agree about it). Others need to stick to whatever they got in the first place.
--
Linux user since early January 1992.
The XFree86 Project has been working very hard to get the 4.0 release out the door. It is taking a little longer than expected so we will be releasing the next pre-4.0 snapshot (3.9.17) before the end of the year. We expect to release 4.0 about two months later in mid-Q1/2000.
XFree86 3.3.6 will be released in parallel with 3.9.17 as well.
That means we should be getting a new version of the stable server shortly as well. Hopefully, many of the development features that can be integrated will be integrated.
And to the naysayers, the X people do a fine job with a very old piece of software. E-mail your suggestions to them, not your complaints.
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
V4 will/does have good multihead support, so you could run one server with two displays, (think ``:0.0'' and ``:0.1'').
_Also_ there's a swell idea called 'Xinerama' that is similar to multihead (id est, it still uses several monitors), but ALL as a single DISPLAY.
Want another xterm? Drag that man-page rxvt up to the third monitor so you can code in the tree xterms side-by-side.
- chad
The config file is particularly nicer to read and write, too.
In short, there's some nice new features, but only if you're itching to use them should you change versions.
There are several extensions already present in XFree86 which do exactly what you're complaining about. The XDGA extension allows programs to bypass X and write directly to the hardware, and the XShm (or MIT-Shm) extention allows X and a program to share a segment in memory which the program writes to and X writes to the screen.
Your first argument also has nothing to do with XFree86, it's an argument against the X protocol. With the power of current systems, trading the network transparency provided by X for a small increase just seems dumb. You might be able to squeeze a bit more performance out of your P75, but you certainly wouldn't notice it on a PII 400. The one place it is logical to make this trade is with games. That's where the previously mentioned extensions come in.
On the other hand, I agree with you about the XFree86 developement model. X would certainly benefit from a more open developement model. Forking the tree would be a great way to piss off all the people who have been working for so long to provide a free (speech) X Server for us, but it would do little to make us a better X Server. A much better idea is to simply let them know we would like to see a more open development model.
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
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.
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
Woah, AMD Athlon rocks!! The complete 3.9.17 build took less than an half hour on my box *grin*
Now for the results. The only tweaking that had to be done to the source tree was to remove the doc directory from the build process. Looks like the top Makefile is missing in the docs directory. After that things compiled just fine (Debian Potato BTW).
I had to do some massive editting in the XF86Config file to get things up and running on a G400. I don't understand why I have to specify the location of my card on the PCI bus. Can't XFree figure this out automatically?
Anyway, this thing is SUPER MODULAR, I like it! I had to add the xaa module in the module section in order to get full XAA (duh) accelleration and to remove the unresolved symbols reports from mga_drv.o. But now that it works --> Mozilla is bloody fast!! Slashdot renders in 2 seconds, and that includes the time for the data to download! I'm using Mozilla because the netscape binaries either segfault or act up under 3.9.17. Next on my list of most wanted features: GLX MGA support!
Perhaps more info later on...
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
It is no coincidence that the windowing system is named X. Study after study has shown that the sociopaths who use Linux and other Linux-like operating systems primarily use their graphical environments to view pornography. Fitting, isn't it? A piece of software named X that is used for viewing X-rated material. An independent study performed by the beloved Reverend Jerry Falwell has revealed that there is an abundance of homosexual pornography on the Internet as well. Evidence of this can be found by looking at the Reverend's IE 5.0 bookmarks.
Friends, here is what we're dealing with: a windowing system for a communist operating system that is used for the most part to view pornography of a homosexual nature. I've just clicked off so many negative things that I'm quite convinced that we all see why it is so important that X be destroyed. You see, I believe that X is Satan's window into this world, his eyes and ears in the world of the living, where he gets a chance to sink his claws into unsuspecting prey and secure their place in the land of the damned when they move from this life to the next.
XFree86 is doubly bad, because it also happens to be free software; as we all know, free software is a concept that is universally despised by God's good little capitalists. It's not surprising that it's free. Satan wants it to be free. He's dumping it onto the world and encouraging its use by giving it an attractive price. Friends, we all know that monetarily, XFree86 has no price
So what can we do to stop X, with its promotion of homosexual pornography, and its augmentation of the intrusion of the socialist Linux operating system into the lives of decent people? Friends, we can do a lot. Write your congressman (I do not say "congressperson", because it is universally known that women cannot be effective legislators) and tell him to support the XFree86 Supression Act being introduced next session by the wonderful American Bob Barr. If you happen to have access to any Linux machines owned by friends, reformat the drives and install Windows 2000. Burn their Linux CDs, if you are so inclined.
Friends, I am convinced that we have the moral fortitude to fight this fight and emerge victorious. We will meet X head-on and defeat it in a glorious battle for the minds of our children. X will not win. X is going down.
Thank you for your time.
but that is the great thing, the binaries are OS-independant, iow a Linux-i386 one will work on *BSD, Solaris-i386 etc.
the question is whether the cpu-dependancies are just an issue of endianness and bits-per-word or what, as if so, perhaps a post-processor could be developed that reverse-compiled them, and then recompiled them for a new platform... not much in the way of hardware secrets is given away by changing the endianness of bytes....
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde
Grrr. my nick is "Forward the Light Brigade"...
X is not closed source.
I like GPL, but X is traditionally under the X license (basically BSD w/o adverizing clause)
this is why most windowmanagers are under the X license... they could go GPL at any time, but most respect the wishes of the XFree folks (and the X consortium folks above them...)
just because it is legal doesn't mean we should do it, and oh, BTW, forking X is a HORRIBLE idea... something that complex should not start having compatibility issues!
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde
Grrr. my nick is "Forward the Light Brigade"...
I think it's important for companies to follow published standards. If the product follows a published standard, then at least minimal drivers could be produced without much effort - heck, one day we could have an OS that comes with the "standardized" driver code and then companies could release enhancement drivers. On the other hand, I personally don't like the idea of a "compatability list". I think it limits the vision of people writing new stuff. We need a "not-yet-compatable" list. ;)
Price, Quality, Time. Pick none. What, you thought you had a choice?
Don't compare apples to oranges.
Actually, it's more like comparing the apple to the apple tree.
The FSF advises against it. See The X Windows Trap. I quote:
So if even RMS advises against GPLing the X Windows System then it is probably not a good idea
-----------
"You can't shake the Devil's hand and say you're only kidding."
When you move from CPU to CPU there is a lot more at stake than just that. Basically what you have suggested is a Video driver written in something equivalent to Java.
I.e. It can be done but it's probably be slow. Better to make X source compatible across CPUs so the PPC, x86, Alpha etc... bins are separated by simply a "make all"
--= Isn't it surprising how badly I spell ?
About 2 weeks ago a patch for the SVGA server has been availabe to add support for the GeForce. You can get the precompiled binary, or patch of the SVGA server at http://www.s2.org/~jpaana/nv/
I haven't had any problems with it, plus support for the GeForce is going to be availabe in 3.3.6 - which should be availabe soon.
I have no idea on what so called "improvements" have been done but most graphical apps have yet to actually work with 100% efficiency for me. I have a suspicion that I am underutilizing the graphics hardware on my machine but am not able to actually do anything because it dosn't actually display properly. Now I have never had much success with the various support "forums" that the Xfree project actually provides. I really don't care what they do as long as they do it right and not concentrate all development resources on the newest Voodoo 3 6000 or something.
I have a couple of questions related to this
1. Does anyone make any decent video cards (actually new things) that would run on classic PC hardware say something that would be found on a "regular" computer on a 486/33 or 486/66 motherboard
2. If not why not
3. Is there ongoing development in creating either a modular windowing system or something lightweight (similar to Qnx or similar). Most of my hard crashes in Linux are usually due to running graphical apps that take almost all the system resources and then make the system totally unresponsive to even direct calls to the X server.
4. Something that would allow for better setting of parameters or perhaps autodetection for various modes a little better.
I tried to set up my videocard a few times before I got anything that would work. First video: Super-VGA;Chipset: ATI 68800-6 (Port Probed);Memory: 1024 Kbytes;
RAMDAC: Sierra SC1148{2,3,4} 15-bit or SC1148{5,7,9} 15/16-bit HiColor (with 6-bit wide lookup tables (or in 6-bit mode));Attached graphics coprocessor:Chipset: ATI Mach32 Memory: 1024 Kbytes
I got the above when I attempted to superprobe it so I was at least able to run the Super VGA server but when I attempted to run the Mach32 server the screen was extremely elongonigated or it allowed for a high resolution but when I ran something like a window manager or an application all of the little details like the menus and buttons and such were just eliminated with their text. Now not to create something that may be a source of shame but does anyone still care about this type of thing anymore or is this release and the up comming one just going to be a little thing for all the big boys to play with around town with their brand new $7,000 graphics adapters. I think that the server may increase preformance but I'll be damned if I can get the thing to adaquately work.
Slashdot social engineering at it's finest
Your comparison of AGP to ethernet in this context is completely invalid. The X protocol is much higher level than that with which your cpu talks to your video card.
Your X client sends the message: "draw the string 'I am a lamer who doesn't understand X' at (26, 44)" and the X server then proceeds to spit each and every pixel that makes up the string over the AGP bus. Depending on the font size and average coverage, the amount of AGP bandwidth used will vary, but even in the simplest realistic cases, the X protocol will end up using ~25-50x less bandwidth than pushing the pixels directly, and in typical cases, X will be well over 100x more efficient (This is all ignoring things like LBX which help even more). An X server has a much more complex and high level command set than even the most expensive professional graphics accelerator.
Your argument does, however, apply to protocols like VNC. That doesn't, however, make VNC any less useful for the people who use it.
It's great that Slashdot informs us of updates to "cornerstone" Linux products like XFree86, but may I offer a suggestion?
;-)
Instead of simply providing a link to an FTP site containing the updated files, how about offering a link to the homepage, or some sort of "announcement" or "new features" page on the web-site. That way we can, at a real-quick glance, see what's new and decide if it's worth it before starting a download. It'd also save some time hunting down the relevant information manually, or, -god forbid-, via another site like Freshmeat...
(as for the previous poster's comment about a software-update posting being irrelevant on Slashdot, keep in mind that a large portion of the Linux community uses XFree86, plus it's bleeding-edge... so it's "News for Nerds" and "Stuff that Matters"...)
Daltorak
Only idiots compare Berlin to X, as the systems have very little functionality in common. X knows how to talk to hardware, whereas Berlin doesn't. Berlin needs to have some combination of GGI and OpenGL.
It would be vastly more sensible to compare Berlin to GTK, Qt, or FLTK, as that is where there might be properties in common.
It needs to run on many kinds of systems.
GGI would be the most likely candidate for this; it's not there yet.
Yes, there are users that only want to run applications on one host's console. And that's why X provides things like the SHM extension so that if everything's local, performance can be made better.
But those that focus on Console! Console! Console! are ignoring that they're not the only users, they're restricting flexibility, and, more importantly, they're ignoring that network support is getting more important all the time. You see, there's this newfangled "Internet" thing...
"GnotX" won't represent a realistic alternative unless it is network-aware.
If the new system doesn't permit running the applications that we already have, then this means discarding all of the X-based software that people have been finding useful over the last dozen years.
Notably, no more KDE, no more GNOME, no more StarOffice, no more WordPerfect, no more ApplixWare, no more Netscape.
Even if there was a way that "GnotX" made a GTK, and thereby GNOME, port easy, this would definitely be injurious to vendors of X software like ApplixWare and WordPerfect (that have some Motif involvement, and thus mandate having a real good X emulation).
"Legacy" vendors won't see this as a move to cooperate with, and like it or not, that's a factor having significance.
People propose things as replacements for X that weren't truly designed as such, or that, worse still, aren't really designed at all.
The original incarnation of "Berlin" amounted to this; they flung epithets at X, claiming it was obsolete, and that they'd do K001 x86 assembly hacking to produce something that would just destroy X.
This was quite silly; they never had a clear design, only a set of claims that amounted to "Because We're Cool Hackers, We'll Outdo X." That may represent intent; that does not represent design.
If you're not part of the solution, you're part of the precipitate.
I know this may sound silly, but I think they should take the video drivers out of X and make them run in kernel space! The creation of universal video drivers will help speed the developement of X and non X programs. X clients are not designed for speed in terms of multimedia and games (although it is not too bad at doing them). Also many home uses may not need the network transpancy layer. Yes I do know one of X's jobs is to handle the video card. That should change in the future!
Why should console apps act differently than X apps when it comes to 2D/3D graphics acceleration?
If I wanted to create a GUI system independant of X I would not get the benefits of X's video card drivers. I would have to reinvent the wheel. I find that extremely limiting as more and more companies come on to the Linux/Unix bandwagon.
BTW this will never happen but one can dream.
In addition to reducing fundamental stability, the Windows solution also makes it hard to release resources when a thread or process dies. Windows leaks memory like a seive, whereas all "X" resources are tagged and when the OS sends a SIGPIPE to the "X" server to signal that a socket has closed, "X" can release all resources associated with that socket.
BTW, if you are running the "X" server local to the machine, the socket can be used only for control commands, not for actual data. Actual data would be sent via shared memory. I suggest that you read up on the SysV IPC spec and see why it's not a good idea to send *ALL* data to the video display via shared memory (basically: shared memory does not go away when the process that allocated it dies, and the "X" server would not be notified if that other process died so it wouldn't know to manually de-allocate that shared memory).
Finally, regarding the performance argument: SGI. I think that says it all. SGI has graphics performance unmatched by anyone -- and runs "X". SGI is perfect proof that "X" does NOT have to be slow -- if "X" is slow, that's an implementation problem, not a fundamental problem with "X". Yes, it's faster to draw directly into a frame buffer than it is to draw directly into a shared memory buffer and then send a command via the "X" socket -- but not MUCH faster, especially if (as with SGI) you have made some optimizations at the OS level for local sockets. I think they have it down to where sending data on a local socket is actually putting it into a buffer, and then mapping that buffer into memory on the other end, somewhere around 20 or 30 cycles. The only real time consumer is marshalling and de-marshalling (i.e., converting the data to a stream, then converting it back to native-format binary at the other end), but that's hardly a killer.
-E
Send mail here if you want to reach me.
There's no need for you to comb your hair; this didn't even graze you as it went over your head.
(Criminy, some people would need a prybar to haul their twisted knickers out of their arses!) Don't be so uptight -- laugh once in a while!
J
I think not...(*poof*)
_E
Send mail here if you want to reach me.
That could be compared to HTTP, where there are an extremely diverse set of web servers, resulting from its relative simplicity.
As for the size of X, I understand that the port to the Itsy weighed in at about 300K. The things in X that are bloated are things like:
- Font cacheing and the simple fact that scaled fonts eat RAM
- Cacheing of hidden objects/windows
which represent things that would cause similar "bloat" in any alternative system.If you're not part of the solution, you're part of the precipitate.
I really love how they forgot to include an Imakefile in the doc directory causing compile to halt. I just downloaded 35 megs of crap for nothing.
WAY TO GO XF86 DEVELOPERS!
-- iCEBaLM
We hope to make it as open a development process as possible. I'm the intermediary between XFree and the SourceForge project. I take the public snapshots and move them into SourceForge, then I do all my work on the public site, and finally I send patches back to XFree. It seems like the best way to do open development with the current restrictions. I does add a little overhead for me of course!
So, if you're interested in DRI work, please check out our SourceForge project. We are looking for anyone interested in participating.
- |Daryll
The DRI work is actually being done in an open repository at http://dri.sourceforge.net. I encourage anyone interested to check out the materials there and join the development list.
At the moment, it is probably only ready for developers (rather than end users), but we're making good progress.
I incorporate all the public XFree snapshots into the SourceForge site, do all my work on SourceForge, and then feed patches back to XFree.
- |Daryll