Slashdot Mirror
X.Org 6.8.2 is Out
ertz writes "The X.Org Foundation today announced the fourth release of the X Window System since the formation of the Foundation in January of 2004. The new X.Org release, called X Window System Version 11, Release 6.8.2 (X11R6.8.2) builds on the work of X.org X11R6.8.0 and X11R6.8.1 released in 2004. X11R6.8.2 combines the latest developments from many people and companies working with the X Window System and an open X.Org Foundation Release Team. All Official X.Org Releases are available for download from the ftp site and at mirror-sites world-wide."
Is it being actively maintained or developed?
Anyone in the know know why Debian is sticking to a fork of the old XFree code, and not moving to x.org like other distros?
I wonder if Ati users will have to wait another 6 months to get 6.8.2 support.
It looks like its moslty a stability update than features:
The X11R6.8.2 release is intended to be a stable bug fix release ("Maintenance update") for the X11R6.8.0 and X11R6.8.1 X11 releases of the Xorg Foundation, containing bug fixes, security updates and a small set of new features, which include the following:
* ATI R100 video driver
* ATI "radeon" video driver
* ATI Rage128 video driver
* CYGWIN infrastructure update
* DMX Library updates
* Intel i810 video driver
* libXpm security update (CAN-2004-0914)
* Mesa (OpenGL) update to release 6.2
* Fixes to the pseudocolor emulation layer (currently only used by the Neomagic driver.)
* "nv" (Nvidia) video driver
* Postscript print driver
* Xprint infrastructure update
I wish they'd release Sarge already so that Xorg will go into unstable.
Paying taxes to buy civilization is like paying a hooker to buy love.
This announcement means nothing without a changelog
This is actually a little faster on my 500mhz intel system! And who said code get's slower as it ages?
Can someone set up a torrent at www.mininova.org? It is an open-tracker and well-populated.
Someone should have done this before we slashdotted their server.
A NYC lawyer blogs. http://www.chuangblog.com/
when will netbsd switch to xorg for its official X.
i know they have no problem with the new XFree86 license, but there are other reasons. Xorg is the new de facto standard. it has more features, cleaner code, and the best xfree86 developers have moved to xorg. xfree86 will soon be obsolete, it's time they switch.
what's holding them back? they can still keep xfree86 on as an alternative too.
Marge, get me your address book, 4 beers, and my conversation hat.
here is a mirror http://mirrordot.org/stories/63d72f637743d71a6cfd0 1e6d95be129/index.html
Dear Taco,
Please post a link to a summary of changes when anouncing the release of a new version of any software.
Forget about the X.org website, it's worthless. If you want to see what's changed in 6.8.2, turn to the release notes over at Freedesktop.org.
It's like deja vu all over again.
I bought parts for a new PC which arrived on Monday, and while setting up SuSE 9.2 I discovered a slight ... incompatibility. If you're using a PCI-Express NVidia card on x86-64, things may prove somewhat problematic with X.org 6.8.1. In my case, the graphical installer simply wouldn't run, and after installing via VNC I couldn't get the proprietary NVidia driver to work without serious corruption of the mouse pointer, missing text and so on.
;-)
I had been concerned that I'd have to switch off stuff like dual-head, hardware acceleration etc., but it turns out it's a (now fixed) bug in X.org regarding PIC-Express and 64-bit Linux on AMD processors. I was downloading some semi-official 6.8.2 packages just before seeing this...
So, if you're having problems with X on a spangly new system, I hope this helps.
Now maybe some of the "Linux fonts are awful" trolls will stop.
I am trolling
I guess the BSDs still don't count on /.
do() || do_not();
This applies to a broad range of OSes. It has very little to do with Linux directly.
OpenOffice.org is used because OpenOffice it trademarked (by someone other than OpenOffice.org). X.org is probably used because X by itself is often used as an abbreviation for the X Windowing System, rather than a specific implementation.
I am TheRaven on Soylent News
What happened to those guys? David Dawes' crusade finally just peter out? Does anyone else still use XFree?
This guy is way out there
How about Xgl, the port of X to OpenGL HW/SW?
--
make install -not war
Windows does not drive video card development. Games drive video card development, and they only drive it one direction: forward. The bigger problem is that PCs have such a wide variety of video cards, ranging from high-end to low-end, external to built-in, and they all differ in various ways. The way you do something on one card may not be the same way you do it on another.
Apple doesn't have this problem, because Quartz Extreme supports a finite set of graphics cards, and Apple computers all ship with compatible cards. Even without Quartz Extreme, however, most of Mac OS X's eye candy still works because it's implemented in software. The only flaw is that you can't disable the fluff and save those cycles. In the end, it's probably all for the best, because Mac OS X looks like ass without it, but it would still be nice to turn off the antialiased fonts and glowing buttons when I'm trying to run three Adobe applications at once.
Then again, I could just stop beiing a cheap bastard and buy more memory. What was my point again?
Formerly GNU/Anonymous Coward. This message has been determined to cause cancer in laboratory animals.
Had a similar problem myself.
a -video/nvidia-glx-1.0.6629
/etc/portage/package.mask file, then "emerge nvidia-kernel nvidia-glx"
Update to a moderately recent version of portage, (2.0.51 iirc)
and add
>=media-video/nvidia-kernel-1.0.6629
>=medi
to your
That should drop you down to the 6111 driver, which is far more stable than the piece of crap 6629. Reboot, or kill your window manager, rmmod nvidia, and modprobe the new one and things should be a lot more stable.
I've gone from locking up X two or three times a day to running solid under heavy load for over three days now with no problem, so I'm fairly sure its fixed it for me too.
It looks like I'm having a similar problem on windows XP too with the current drivers, so I'm going to try the same thing there.
HTH!
Remember kids, it's all fun and games until someone commits wholesale galactic genocide.
the X windowing system is at Version 11 release 6 (X11R6) since the early 1990's.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
May 16, 1994, actually. But they haven't removed anything from the API.
It implements the 6th revision of the 11th X-windowing system specification. Hence it's X11R6, but Version 11 of the X-Windowing system is the one that's a standard, so they can drop the 11. The result: revision 6. The 8.2 is the implementation version.
This should have been put in the BSD section as well, for obvious reasons. I'd add the Unix section, except there isn't one. Come to think of it, wouldn't it make a lot of sense to have a single section for Linux and Unix (including BSD)? The distinction between Linux and Unix is more legal than technical.
I believe Windows remote desktop does this
You believe entirely, 100% wrong. Windows does no such thing.
Remote desktop actually works very simply, much like VNC does. It's simpler than using a remote X server as well.
Take a look at the source code for rdesktop sometime. It handles mouse and keyboard redirection, audio streaming (two way), and a video protocol.
Remote desktop "feels fast" because of two things. For one, apparently it has some good kernel level hooks so that where other stuff has to "watch" the frame buffer to figure out changes, remote desktop is notified. It's a much more efficent method, and it means that the client is truly dumb. It doesn't have to know anything about fonts, or widgets, or windows, or anything.
X works quite a bit differently. It also doesn't have to know about widgets and all that stuff. Windows RDP goes "after" everything is drawn and takes a look at the end product - the compisited ready to draw images or portions of portions of the screen. X actually brings the primitives over the wire. Which can be sometimes much, much faster and more bandwidth effective. It depends on the application.
This is a good short inro on xlib programming.
I've used Windows, MacOSX, various commercial unices, linux and bsd, and have come to a conclusion, that the X server's client-server design compromises the latency of usage.
I thought this was a driver issue, for example, on the same machine, opening, moving and resizing windows is very snappy on any window system beside X, be it MSWindows (yeah I know crappy, insecure, bloaty etc, but snappy), BeOS or OSX. Even the X11 on Darwin isnt quite as snappy as it should be being a GUI system.
In the case of BeOS, the graphic system is highly simplified, compared to client-server X, with a window manager on top. In the case of MSWindows, all graphics card manufacturers have designed their cards and their drivers to be optimum for windows, each little function on any chip, of rage, TNT, Matrox is used in the best way to blit, display and alter windows. I dont know much about cocoa, which came from the NeXT design...
Apart from the latency, I think the process priority of X and its child processes should also be rethought, under heavy load X and its WM becomes very unresponsive.
Linux/BSD have far superior OS designs and c libraries compared to MSWindows, its sad to see something simple holding them back from the Desktop market. Sure the lack of opensource graphics drivers are also holding it back, and so is the lack of standardization (gnome vs QT, menu system and location in the filesystem, even package standards... rpm?), but this one hurts in that it affects the image of opensourced OSes to commandline-shy users. gl-enabled apps even within windows run beautifully, but superior hardware is required to let the window system run as smoothly as other OSes. Some people think part of the culprit is the GUI system sitting outside of the kernel space, and all GUI-related processes being in a tree, rather than being children of init.
I wonder if X can be compiled as X-lite, bypassing the client-server overhead, possibly compiling WITH a simple WM rather than running it on top, and being run at a higher priority, should make things smooth. Any thoughts?
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
I have a supermicro (7505 chipset) dual Xeon board that supports both SBA and FW. However, when I try to enable SBA/FW I get lockups. I fixed this by disabling them in the modules config. /etc/modules.d/nvidia
options nvidia NVreg_EnableAGPSBA=0 NVreg_EnableAGPFW=0
Then run modules-update and reload the nvidia module. You may have to reboot for it to take effect. One thing to note is the new drivers DIDN'T default to off as the older ones had. So some people are seeing fixes just because they downgraded...
I wonder when Linux users will stop buying hardware that doesn't have published interfaces.
As soon as you tell us what to buy instead. Other than NVIDIA and ATI, neither of which publishes a full register level spec, which video chipsets are available as consumer level video cards sold in Best Buy stores or as part of a notebook computer? Or do you expect us all to buy X11 thin clients instead of video cards?
Yes, I'm very dissappointed in Debian/unstable for this. Certainly many other packages are available in unstable, up to CVS and bleeding-edge upgrades. But no X.org.
I've had some nasty things happen with package dependencies breaking in unstable, so I'm fairly sure they're not holding off because of that.
With all due respect, you don't really seem to know much on this subject. As I understand it, it is not the client-server model, nor the inefficiency of the X protocol that is at issue here. It is rather a the stagnancy of the x toolkit (which could be blamed on the xfree86 organization, if one likes to point fingers) that has caused this.
As has been stated in another thread, X11R6 was first released in 1994. No significant changes were made to its drawing libraries before the addition or the render extension (with anti-aliased fonts) by Keith Packard in the 2001/2002 timeframe. In 1994, things that we take for granted like true-colour displays. Windows 95 had not been released - Windows 3.1 was mostly seen in 256 colours!
As more graphical applications (e.g. web browsers, image viewers) became the norm, and 32-bit colour became common, application writers sought solutions that would allow them the functionality they needed. GTK+ and QT became toolkits that supplied the features that X lacked, at the cost or having to perform client side rendering. This pushes more and more pixels with higher bit-depths through the X protocol to the server. Some solutions were devised for special cases like OpenGL (GLX) and video (Xvideo), but X's core display system did without updates.
Since the clients now had to push lots of bits through the X protocol to the server, 2D graphics displayed the latency that you describe, even on really fast hardware. In a way, the Render extension seems to have pushed this over the edge since software fallbacks required (esp. for text) made rendering crawl.
The solution that the X.org guys have come up with is this: reduce the reading and writing over the X "pipe". There are a few methods that they are using. First is the XFixes extension. This extension supplies some additional functions that were missing in the core protocol - like the ability to address a region. Once this was in place, the Damage extension could be created, which allows the client and server to pass less information back in forth because they can now identify when a region has been damaged and needs to be redrawn.
The next piece is Composite and the composite manager. Composite allows the server to draw windows into an offscreen region so that the composite manager can redraw them on the screen. By doing this, the composite manager can use the hardware acceleration in the video card to do smooth opaque moves, and additionaly special effects. Theoretically, a composite manager could be written to use OpenGL, which would be really smooth. I can testify, however, that using Composite and xcompmgr on my PC at home is smooth as glass. 32 bit colour, drop shadows, and all the niceties...
The next step will be Cairo, Glitz, and XGL. I am anxiously waiting for a release of this stuff, because it is way cool.
Schrodinger's cat is either dead or really pissed off...
I always hear about Sarge, but what about the unstable branch of Debian ? I still don't get why Sarge would require unstable to be frozen like that - and in fact, it isn't the case for most of the other packages.
It's very simple.
Debian has three major branches: stable, testing, and unstable.
The stable branch is treated very carefully. It will get security patches, but otherwise will not be changed. It's a "frozen" release. Most Debian users will run the stable branch on their servers.
The testing and unstable branches work together and are closely related. The unstable branch is where new packages are checked in. Once the new package has been in unstable for a while and is working out well, it will be auto-migrated into the testing branch.
And this is the answer to your question: Debian cannot update the unstable branch to X.org without cutting off the testing branch from further updates, or risking that X.org packages might get migrated into sarge by the scripts that update testing. Why would the Debian guys make more work for themselves by doing this?
All three branches have "code names". The unstable branch is code-named "sid", always. The testing branch is currently code-named "sarge". When sarge is "released", what will happen? First, the current stable branch (code-named "woody") will be retired from the main servers. Second, the servers will be updated to have the sarge packages listed as the stable branch. Third, a new code name will be chosen for the next release, and the testing branch will be named with that code name. (At that exact moment, I guess the testing branch will be identical to the stable branch, but that won't be true for long.) Finally, all the checkins that were held back, waiting for the release of sarge, will start to flood into unstable; this is when you can expect to see X.org in unstable.
Actually there is a fourth branch of Debian: experimental. You will really see X.org show up in experimental before it even shows up in unstable. Once people have good success with the packages in experimental, the packages will be checked in to unstable. (Just because it is called "unstable" doesn't mean that Debian is completely careless.)
The problem is that the expected date release of Sarge was pushed back over and over.
This is just Debian for you. Debian is a loose coalition of volunteers, and their sole goal is to put out a distribution that will be rock solid. They ship "when it's done", not according to some schedule.
Note that there is any reason you cannot use sarge now. Why wait? It's already very stable. I used to use unstable on my desktops, and that was stable enough for me; testing should be even more stable.
The Debian X Strike Force was IMHO quite slow at reacting to the upcoming of XOrg.
The X Strike Force is not a large team, it has a lot of work to do, and what you think of it doesn't really change anything. If you join the X Strike Force and help them get their work done, then I will listen attentively to your opinions, and until then, I'll gently suggest you not complain of their slowness.
If you want to combine the Debian goodness with the X.org exciting new flavor, I have two suggestions for you.
First, you can read the discussion here about how to compile your own X.org from the CVS, and set that up on your Debian system. It works so well there is "no need for packages", according to that discussion.
Also, if you would like everything that is good about Debian but with faster release cycles, you ought to look into Ubuntu. Ubuntu is committed to a new version every six months, and their next release (due to release in April 2005) already has X.org checked in. I'm using that to type this message. It's definitely not as stable as the released version of Ubuntu from October 2004 but I can deal with it and I like th
lf(1): it's like ls(1) but sorts filenames by extension, tersely
You must work in Sun's marketing department.
I just installed Slack 10. I discovered that if I rename my old XF86Config to xorg.conf, it works. It was just a lucky guess on my part that this would function.
Package: *
Pin: release a=hoary
Pin-Priority: 50
to
# Ubuntu Hoary
deb http://archive.ubuntu.com/ubuntu/ hoary main restricted universe multiverse
to
apt-get update
apt-get install grep-dctrl
cat status | grep-dctrl xorg -F Source -s Package | perl -e 'while (<>) { print; print "Pin: release a=hoary\nPin-Priority: 1000\n\n" }' >>
When all is said and done, these steps tell apt where to get ubuntu packages from, then tell it not to install any them, then tells them to make an exception for the Xorg packages, treating them just like they were regular debian packages.
You'll also have the option of installing any software in ubuntu that's not in debian yet, and all of the potential breakage that implies.
"You know, Hobbes, some days even my lucky rocketship underpants don't help" -- Calvin
I really thing there need to be a fifth branch that even goes way beyond experimental. A tree where just about anything will show up literally a day or two after its release. It could be called the god branch or something.
The Debian X people cannot change over to X.org until Sarge is released, otherwise Unstable will go bonkers, which will ruin the propagation of bugfixes to Sarge, which will make the release impossible. The focus now is on reducing the Release Critical bug count to as close to zero as possible so the release can happen, after which I seem to recall that X.org will be added to Debian Unstable ASAP.
:)
So in summary, I hope the people complaining about the slow release of Debian aren't the same ones who keep asking why they aren't massively upheaving their package repositories during the release process
Xorg needs your help. Be it coding, documentation. Please help out and Hop on irc.freenode.net #xorg-devel if you want to help
:)
Things to help with:
Documentation - Doxygenifying the Xlibs, Xserver sources.
And other things
Everyone wants a Tux in their life.
Actually, for ages, the X strike force in Debian were the only people who were ensuring that X worked on 11 different architectures (as I'm sure you know everything in Debian needs to). This is a gigantic amount of work!
What with USB working the way it does, where you can chain off as many devices as you feel like, and computers being fast enough to handle all of them at once, it seems to be like it should be possible to do the following:
....hmmm..... I wonder how one goes about learning the X input system....
Three Users, user zero, one, and two, are sitting in a conference room using a giant screen projector as the monitor, attached to a laptop someone brought. There are three different keyboards and three different mice attached to the laptop as USB devices. Some might even be IR so they are being used from across the room.
User zero picks up keyboard 0 and mouse 0, uses mouse zero to click on a terminal window and focus it, then uses keyboard 0 to type into it.
Meanwhile User one sits at keyboard 1 and mouse 1 to demonstrate something on the web using a browser window.
Meanwhile User two, using keyboard 2 and mouse 2, is making a diagram in openoffice.
Essentailly, there are three different "input contexts" each one consisting of one mouse and one keyboard, and each has its own mouse pointer, and it's own keyboard focus, and the X server is interleaving thier input events together and dispatching them to the appropriate applications.
The place where I would have found such a thing useful was a roleplaying game where I had a lot of visual aids on computer, one of which was a map with little tokens players could move to represent themselves on the map (each token was a layer in Gimp) It would have been handy to have public mice for them and my private mouse for me to use on the private GM screen (the laptop's own screen).
But, it doesn't seem to be possible without writing it myself....
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Follow http://cvs.freedesktop.org/xorg/xc/ChangeLog?rev=1 .365.2.155&only_with_tag=XORG-6_8-branch&view=mark up, check for commits with "xprint" or "print" in the description.
Client/server is not the problem. In many cases it can be much faster because it encourages batching together hundreds or thousands of requests into a single context switch.
The problem with X is much simpler, but nobody wants to hear it. The problem is the design of having a seperate process that is the "window manager".
Anybody who has used X for many years will know that the problems with moving and resizing windows have remained pretty much constant despite the fact that the machines themselves have increased in speed 100 times. This obviously indicates that overhead or latency is not at fault. The constant is retrace speed. Monitors now update about the same speed as before. If something is drawn by two different unsynchronized processes, you can see the two parts one retrace interval apart, no matter how fast your machine is. And the window manager means the border and the contents of windows are being drawn by two different processes.
Proof: try one of those media players that draws everything out to the border. Try resizing them. Ideally, to remove all aspects of window management, put it over an empty part of the desktop, or do all your work overlapping the contents of some other program (ie don't overlap both the borders and contents of another window). Notice that these apps are probably not doing very efficient graphics because they are full of eye-candy, yet seem to resize quicker and better than any other X appliacation.
How to fix it? The answer is to make the window borders be drawn by the toolkits. Yes, this will result in different window borders by different programs. No, this does not "confuse" the user. Users are confused by bad interfaces, not by different ones.