X.Org 6.8.2 is Out 450
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."
Mostly stability (Score:5, Informative)
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
Re:So is Xfree86 dead? (Score:4, Informative)
Mirror (Score:4, Informative)
Re:Debian? (Score:3, Informative)
Because it's not sticking to a fork of the old XFree86 code, and it is moving to X.Org, like other distros.
X.org (Score:5, Informative)
Re:NetBSD (Score:4, Informative)
It's been in pkgsrc for a while, and works fine
PCI-Express and X86-64 fixes (Score:5, Informative)
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.
Section Linux? (Score:2, Informative)
Re:X.org, openoffice.org (Score:5, Informative)
Re:Changelog (Score:5, Informative)
2. Summary of new features in X11R6.8.2
This is a sampling of the new features in X11R6.8.2. A more complete list of changes can be found in the ChangeLog file that is part of the X source tree.
* Freetype was updated to version 2.1.8. But installing freetype from X distributions would often or usually result in the replacement or use of "stale" versions of freetype. On Linux, FreeBSD, Solaris 10, and SCO5, therefore, X11R6.8.2 will by default use the version of freetype2 that is installed on the system. If your system doesn't come with an installed freetype2 and you wish to use the version supplied with this distribution, please add: #define HasFreetype2 NO to config/cf/host.def.
* The XTT font module and FreeType1 have been retired because FreeType2 subsumes their functionality
* Retire old PS Type1 font rasterizer (except for CID font usage) since the FreeType2 rasterizer now handles PS Type1 (*.pfa, *.pfb)
* Render implementation fixes
* Updated x86emu and resynced with upstream at Scitech
* Updated SiS driver
* Updated Nvidia driver (opensource version)
* Render acceleration for ATI's R100 and R200-series cards
* Substantial speedups in the software implementation of the render extensions when compiled with gcc 3.4 on the i386 architecture.
* Infrastructure for rotation support in drivers
* New Trapezoid specification for the Render extension
o Respecify Render to include only 'normal' traps
o Allow backward compatibility but internally covert to new format
* Software mouse cursor is now based on the Damage extension
* A new keyboard driver is enabled by default. The old driver is disabled unless explicitly compiled in by defining the macro |USE_DEPRECATED_KEYBOARD_DRIVER|.
* All extensions (except Xserver-specific extensions "DMX" and "XpExtension") can now be enabled/disabled from the configuration file and from the command line.
* Mac OS X updates:
o Support dynamic screen configuration changes in rootless mode
o Added option to always use Mac command key equivalents
o Interpret scroll wheel mouse events correctly when shift is held down
o Added trivial Xinput support
o Fixed launch of X clients from Finder with a space in their path
o Fixed some GLX rendering problems on Mac OS X 10.2 and earlier
* Updated xterm version
2.1. New X extensions
X11R6.8.2 includes four new extensions:
XFixes
The XFixes extension is a collection of improvements for deficiencies in the core protocol, including
* Notification when a selection changes
* Server-side region objects
* Allow clients to track the cursor image
Damage
The Damage extension allows a client to be notified whenever something is drawn to a window. This feature is useful for VNC servers, for screen magnifiers, and for clients using the Composite extension to update the screen.
Composite (experimental)
The Composite extension allows a client to request that all drawing to window is redirected to off-screen buffer. Though the Damage extension the client, called a 'compositing manager', can know which areas of a window is modified and render the windows on screen. By making use of the drawing requests from both the core protocol and the RENDER extension, the compositing manager can create special effects, such as translucennt windows.
The Composite extension is considered experimental in X11R6.8.2 and is turned off by default.
XEvIE (X Event Interception Extension) (experimental)
XEvIE is an extension to intercept core keyboard and pointing device input It allows consumation, modification or synthesis of input events before these are sent to their final destination (i.e., interested clients). This feature is required by the GNOME accessibility project.
The XEvIE extension is considered experimental
Re:Debian (Score:3, Informative)
Re:All I want (Score:3, Informative)
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!
Re:So is Xfree86 dead? (Score:5, Informative)
Version 6 (Score:3, Informative)
Re:version numbers (Score:3, Informative)
Re:Debian (Score:3, Informative)
Comment removed (Score:5, Informative)
Re:Debian? (Score:5, Informative)
http://necrotic.deadbeast.net/xsf/XFree86/trunk/de bian/local/FAQ.xhtml#debianplans [deadbeast.net]
Re:Why is this under "Linux"? (Score:2, Informative)
This applies to a broad range of OSes.
Very true.
It has very little to do with Linux directly.
False, linux is by far the largest user platform for xorg.
Re:So is Xfree86 dead? (Score:5, Informative)
No, the real question is whether anyone qualified to continue X development is still sticking with XFree86. From what I can see, the answer is no.
Try disabling SBA and FW (Score:3, Informative)
Re:Mostly stability (Score:1, Informative)
Re:So is Xfree86 dead? (Score:2, Informative)
Re:Debian? (Score:3, Informative)
I think many of us are wondering when x.org will be added to Debian unstable. It's nowhere in the package lists for stable, testing or unstable [debian.org].
I can't find any recent news regarding X.org for Debian [google.com] on Debian.org, or in the FAQ [debian.org]. I see some discussion and debate about 7 months ago, but many things have changed since then.
Re:Mostly stability (Score:4, Informative)
Ever design circuit boards? I have. I tried making some by hand with rub-off stuff from Radio Shack and ferric chloride, and it was a PITA. Then I found www.custompcb.com in Malaysia which sent me two 4x5.5" boards for $26, including shipping. $26 is a lot cheaper than it would have cost me to set up my own photolithography and etching lab.
Re:Torrent? (Score:5, Informative)
"Client server is slow" myth dispelled, once more (Score:5, Informative)
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.
Re:So is Xfree86 dead? (Score:3, Informative)
Actually IIRC much of the reason for the fork was due to a license change that many groups/people thought was too restrictive and incompatible with the popular OSS licencies (GPL/BSD/APACHE etc...)
-kaplanfx
The relationship between unstable and testing (Score:5, Informative)
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 [debian.net] 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-linux.org]. 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
A Config tip (Score:2, Informative)
Re:Which card instead? (Score:3, Informative)
Help is on the way. TechSource [techsource.com], which makes video cards for air traffic control and medical applications has started work on a desktop/workstation card that will be able to accelerate enough of X.org and OpenGL to be usable. It won't blow your socks off in gaming, but for many users that's not important anyway. More importantly, the specs will be fully open. More information on OpenGraphics.org [opengraphics.org].
Oh and yes, it's been mentioned on Slashdot [slashdot.org] before.
Join us and help out!
Re:Debian/unstable (Score:3, Informative)
Once sarge releases, things will hopefully go back to the craziness we all love.
You can get a lot of newer packages out of the new(er) 'experimental' repository, but X.org isn't in there.
If you really want X.org in debian: (Score:4, Informative)
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.
Re:Ati Drivers (Score:3, Informative)
You can try the live version.
About 3d, you need ATI to release a driver.
They did publish specs in the past, so there were drivers up to 9200, but then they stopped.
The problem you talk about is not so. There are some 3d video cards, and some winmodems that are not supported, but most hardware is.
Proprietary drivers have problems of their own, too.
I have some hardware that does run on the Linux kernel, and doesn't on newer versions of win (aimslabs tv tuner, samsung webcam) because hardware vendors died, or just don't wanna release new drivers.
Linux drivers for most hardware are there, and are there forever.
Win drivers are not time-proof.
With respect to hardware support, Linux isn't behind win, for me, because I can run more hardware with Linux (including pctel winmodem, and Doom3 on my accelerated, shaderlicious nvidia FX5200 [don't laugh]), including old hardware that I don't have winXP drivers for.
Of course, there is still lots of hardware that doesn't work with Linux, and won't, but of course the same can be said for Win. I'm not saying that changing from an already bought win machine to a gnu/linux one is easy, but it's very easy to buy a PC with all of its hardware supported. For example, most VIA motherboards have support for all their integrated peripherals, including winmodems, sound "cards", ethernet, 3d accel for S3 prosavage video chips.
Re:Debian/unstable (Score:4, Informative)
The reason is the release of Sarge (Score:2, Informative)
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
Re:Ati Drivers (Score:3, Informative)
How do you mean? If there are open specifications for driver iterfaces won't that accomplish the same goal? Think of it from the manufacturer's point of view. They already have to conform their drivers to Microsoft's interfaces. You don't just knock off drivers over night, either -- its a big job that is easy to get wrong. So they spend their time making sure that things work on Windows because that's what, 90% of their market? 80%? Its an important chunk of their revenue stream. But the beauty is this: as long as their driver is compatible with the interface, they get a lot of leverage -- they are gauranteed to work in at least the current platform release of windows (and sometimes several generations), their driver is loaded into the kernel (or at least protected space), they can expose controls via automatic hooks directly into existing UI features, and they can get their driver certified. All of which they can do without releasing source code (since they don't want to). That is a high level of operability, integration, compatability all while offering exceptional *trusted* low-level access to hardware. Finally, the consumer only needs to know that the hardware has been certified. Once they see that, they can be confident that they will be able to use that card on their platform with little or no fuss and that their platform will unlock all of the features of the hardware. There is no such equivalent in Linux.
But why can't that be done in Linux? Maybe not in the kernel directly (it ought to be defined there, though, in my opinion) but perhaps in the X server or somewhere. Standard interfaces are just as important as source code and sometimes the need for a standard binary interface exceeds the need for source code. I'm all with you in the desire to have everything source based but even with that, a sophisticated binary interface for video drivers makes sense and is necessary. This is also true for other hardware drivers--audio comes to mind: why does my audigy stutter when I switch to another task on linux? It is butter on Windows so its not the hardware's fault. Its the binary interface and its integration into the kernel that makes the difference. There is no reason why Linux can't offer the same sort of services and experience the same sort of results. Its not a magic Microsoft thing -- hardware support on Linux isn't up to snuff mainly because Linux has yet to fully develop that infrastructure.
Best of all, if Linux creates a model that can become a standard, Microsoft will finally get some competition in the driver model arena. That's how it locks-up and locks-in hardware manufacturers in the first place -- they have the infrastructure and they provide the specs. So having the source code alone won't help relieve us of Microsoft in this case. This is a case where binary interfaces are more important than vendor source code -- specifically because a standard mechanism needs to exist to allow many vendors to participate without becoming dependant on any one vendor's model. The key thing to remember is that we don't need source code to verify that a driver is correct and/or bug free as long as we have a standard interface we can test it against.
X strike force (Score:2, Informative)
Re:Xprint updates (Score:2, Informative)
Re:Debian/unstable (Score:2, Informative)
You could also compile it from source and install it under