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?
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
This is actually a little faster on my 500mhz intel system! And who said code get's slower as it ages?
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.
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
How about Xgl, the port of X to OpenGL HW/SW?
--
make install -not war
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.
http://necrotic.deadbeast.net/xsf/XFree86/trunk/de bian/local/FAQ.xhtml#debianplans
Debian will move to Xorg the day Duke Nukem Forever is released.
I see you've been playing with the Duke Nukem beta as well.
The experimental version of Debian that will be running xorg REQUIRES Duke Nukem Forever to boot. It runs as a client process, accessible by shooting the bouncer at the alien-infested oyster bar (from the opening screen take 2 lefts, a right, a left, and straight on three blocks. It'll be on your right.) Killing the bouncer will fork off a process that boostraps the new Debian, from which point you can fire up xorg either using startx or by defaulting to runlevel 5.
The Future of Human Evolution: Autonomy
As you wish: click :)
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
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.