Slashdot Mirror
X.org X11 Server Release 6.8
kormoc writes "The developers of X.org have just release the long-desired version 6.8.0. This release brings real translucency and allows one to set values on different windows. Also, nifty drop shadows as well as XDamage, an extention that limits redrawing of windows to only the areas that were damaged. The Xcomposite extention is still not stable, but it works well for some people. Why not give it a shot?"
I think you mean http://freedesktop.org/~xorg/X11R6.8.0/doc/RELNOTE S.html
as in 6.8.0
Exercise caution when modding this message up: the author acts like a jerk when his karma is excellent.
I installed this from cvs yesterday. The new composite extension amazing, full shadows and transparency possible, yet everything renders faster than i've ever seen X, no flicker whatsoever.
In order to use the composite extension i had to add:
Section "Extensions" Option "Composite" "Enable" EndSection
and
Option "RenderAccel" "true"
to my nvidia driver section of my xorg.conf file
then install xcompmgr to turn it on since kwin doesn't utilise it yet.
Really, why?
What is it with drop shadows?
They're something that's easy to define, work well in MacOSX and Windows XP, and don't work very well in (some) current X11 servers. So obviously, you're going to get loads of graphics geeks rushing to fix it.
That said, the drop shadows in KDE on XFree86 look fine to me already.
Here for 6.8.0.
If you want to find out when it is available in portage without sync then check the portage database
----
Dropshadow screenshotsp ng 9 500411796a9ba106_1.jpg
http://ruinaudio.com/Xorg-xcompmgr.png
http://jserv.sayya.org/misc/matchbox-gcin.png
http://jserv.sayya.org/misc/matchbox-xcomposite4.
http://img3.exs.cx/img3/6458/screen_lynucs_175940
Translucency screenshots
http://freedesktop.org/~mallum/argb.png
http://freedesktop.org/~krh/Screenshot.png
I've five iTerms going right now (yeah, MacOS X). They're all the same colour yet I can easily see where they intersect *and* I can see the text below through the shadow. It's an efficiency thing ...
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
This is awesome! From section 3.3 of Release Notes:
E S3.html#3
The nv driver for NVIDIA cards has been updated as follows:
* Support added to the nv driver for the GeForce FX 5700, which didn't work with XFree86 4.3.
* The driver now does a much better job of auto-detecting which connector of dual output cards the monitor is attached to, and this should reduce or eliminate the need for manual xorg.conf overrides.
* The 2D acceleration for TNT and GeForce has been completely rewritten and its performance should be substantially improved.
* TNT and GeForce cards have a new Xv PutImage adaptor which does scaled YUV bit blits.
http://freedesktop.org/~xorg/X11R6.7.0/doc/RELNOT
It's part of a stable X.org release. The unstable extensions are not compiled by default, but they do bear mentioning because they are significant additions to X, and will make huge changes to the eye candy, as well as the utility (eg expose in mac os) of X
well, XDamage is an extension, which means, it doesn't modify the existing protocol, but adds more request/response types to said protocol, via a well defined extension protocol.
It should, now that X developers can work with package maintainers rather than having an establishment work against them (the XFree86 way). Yay for more code and less politics.
Previous long lead times, according the Brandon (Debian's X release manager) were brokenness on some of the platforms Debian supports about which the developers in power didn't care, as well as reams of patches they wouldn't accept (like ones from ATI supporting "new" cards that weren't accepted after 6 months).
The whole point of FreeDesktop was to help everyone coordinate so that the process could be smoother. Most of the poeple on both sides were fed up with the politics and are working to make that the reality now.
I accept it as a joke :)
...
When that is said, the latest release, the 904 drop, compiled in 21 minutes on my machine and has been running perfectly fine for a few days. Ofcourse, I'm running an AMD64 based machine. Your "joke" is actually true if you run a P1 160Mhz box, then it will take weeks to compile
If you mod me down, I *will* introduce you to my sister!
I have a Windows XP box on my desk right now; the only drop shadows I see are under the icon text. I'd be hard-pressed to compare that to the (gorgeous) Mac OS X effect or this new X effect... - Fromage
X is the protocol. X11 is the 11th version of the X protocol (the first version of the X protocol I saw was X10, and that was some time ago on an already ancient machine). X11R6 means the X Window System, Version 11, Release 6 - that's the basic protocol level.
.8.0 bit at the end is X.Org's specific version numbers for their implementation of the X11R6 protocol. (Other organizations implement X11R6, such as Sun - they call their version of X11R6 OpenWindows).
The
I believe there was a prototype windowing system called W that preceeded X, but that's now ancient history (the first X Window System implementation to run was in the mid 1980s).
Oolite: Elite-like game. For Mac, Linux and Windows
Having said that, the presence of the new ARGB visuals is known to confuse and break some programs. Worryingly, Mozilla+Flash and GTK 1.2 apps (like XMMS, VMware, etc) are amongst the things that have apparently broken.
To "unbreak" them you need to set a magic environment variable but as of yet there is no automatic blacklisting mechanism in place for userspace apps so .... you just have to be able to diagnose this breakage yourself.
Hence the fact that it's described as unstable.
ISTR that one of those things Xorg wanted to do was to separate the X client and server packaging. It's generally frowned on to install an X server on a server machine, but it would be nice to have X client software available there. The current Xorg/XFree packaging isn't friendly to splitting out the X client libs, or making the package control system recognize that so you could install X clients.
I don't see anything about separation of client and server libs and packaging. They have some other projects listed elsewhere, but nothing terribly solid about client/server separation.
Looking at the Xorg release plan (closest I could find to a roadmap) at http://wiki.freedesktop.org/XOrg/XorgReleasePlan
Anyone aware?
Another thing that would be neat to see is integration of the GLX/DRM work on the S3 Savage line of chips. According to the DRI page there's some work being done on this, though it's not ready for prime time. My laptop has a Savage, and my Mom's computer uses the Via KM133, which has an imbedded Savage. Of course this is an area where perhaps I *should* be trying to help.
The living have better things to do than to continue hating the dead.
"When will we see fully improved network/remote access?"
:) )?
What's wrong with ssh (besides the occasional "oops, wrong machine" moments
"When will we see some innovation instead of eye candy?"
In case you missed the point, this is about innovation, eye candy is just a nice side-effect. For example, XDamage improves X over slower network connections.
"The hooks for modular gui plugins should be there"
You mean something like the extensions for X?
"Why not work on something to compete against microsofts new gui/api interffaces based upon 3d rendering instead of pixel rendering? why not kill 2d before the competition and work on an graphical interface that is competitive instead of intriguing."
Well, it would be time to make up your mind on eye-candy.
3D desktops so far were nothing but neat eye-candy, from a usability point of view they have added nothing (one can argue that in fact they are worse than 2D ones). But anyway, I had the impression that the people of X.org are working on something like that.
If you want something to change, help them - but first, please, get your facts right, because spewing uninformed bullshit on slashdot does not help anyone.
Real life is overrated.
When can we see a trusted computing environment?
SELinux integration with the X server (SE-X) to allow you to lock applications down tighter is being worked on in a branch of Xorg CVS. It's not done yet AFAIK. The idea here is that you can take the features of "trusted" military-strength windowing systems where it's possible to have secure windows such that you cannot screenshot them, other apps cannot send events to them and so on.
When will we see fully improved network/remote access?
This statement is meaningless but NX compression is clearly the way forward here.
When will we see some innovation instead of eye candy?
Again, totally useless statement. Nowhere do you define "innovation" or even show that it's a good thing (hint: I'll take an efficient and usable desktop over and pointlessly innovative one any day).
The hooks for modular gui plugins should be there - just as with any gui. OS/2 had the object based interface, windows has the pretty indepth theme integration and OSX has the PDF display..
Again a meaningless statement. There are actually some pretty convincing arguments out there that DPDF/DPS type systems are the wrong way to implement a graphics system, and that XRENDER type trapezoid rendering is the right way. I suggest you investigate first.
Windows XP has themes - great. You realise that Linux has pioneered the way when it comes to theming? It was the first to have a totally themable desktop (I think this is true even if you include gross hacks like WindowBlinds), still the only OS to have systematic icon theming, the only one I know of that has mouse cursor theming etc.
Why not work on something to compete against microsofts new gui/api interffaces based upon 3d rendering instead of pixel rendering?
I think you've misunderstood what Avalon is. It's not about 3D GUIs, it may include using 3D acceleration to speed up rendering on machines that support it but this doesn't affect the APIs.
Quick release cycles don't do anything for corporate adoption. Give us the "killer app" - in this case a desktop/windowing system that delivers everything we seem to bash in other systems as insecure or proprietary.
I don't know of any other open, standardised windowing system with the security features X has. If you can show me one, I'd be interested.
On the other hand...
;-) ;-)
Fabian Franz: In fact, our FreeNX implementation is only the last piece of the mosaic. 99,9% comes from NoMachines's GPL/NX components, that we simply use unchanged in FreeNX.
[...}
Kurt Pfeifle: In the last 15 months, there have been servere misunderstandings concerning the whole NX software, which was considered to be "non-Free" by several Open Source developers, just because NoMachine also based its commercial products on top of it.
Without having a deeper look, rejecting NX as "practically unusable, if only the libraries are released under the GPL whereas the NoMachine NX Server remains proprietary". These biases simply overlooked, that a commandline tool was shipped by NoMachine almost from the beginning, including the source code which allowed everyone who was interested to build an completely working NX tunnel.
[...]
Fabian Franz: Our implemementation was intentionally kept simple. It's a simple Bash script...
You are surprised? Yeah, right: FreeNX Server is a Bash script, which glues together GPL library and executable components of NX to a working whole. All that stuff existed for 15 months untouched.
The fact that it is Bash means that every Linux developer can fix errors in our FreeNX server.
Kurt Pfeifle: I was merely a mentor for the FreeNX development and I do the documentation. But I can confirm: Fabian isn't lying...
FreeNX consists of less than 500 lines of Bash code (additionally to the NoMachine/NX source code parts, which are under the GPL).
Fabian did the implementation of the FreeNX server all by himself. First of all, Fabian is a true Bash wizard.
Secondly, this implementation should prove how "complete" the GPL components of the NX are already since 15 months.
So, i'd be guessing anyone from Gnome can code that up in a couple of days as well, there really isn't a whole lot of magic here.
I'm not satisfied with the above answers, so I'm going to try one myself.
The X Windowing System was originally an MIT project for unix (not linux specifically, it works with linux because linux carries on with the unix specification) that was made open source and turned into open source. X is just the name of the system, the 11 is the current version of the specification. 11 has been active since 1988.
The XFree86 organization managed the X-Window-System until version v4.3. Earlier this year, though, they released v4.4 under a license that was thought incompatible with the GPL, which caused a split. Alot of politics went on and alot of people got angry, which caused the birth of the X.Org foundation, which is now industry backed and also backed now by most major distributions such as Slackware (I think they were the first?) and Mandrake, Redhat, Gentoo. Others such as Debian still use XFree86 v4.3 instead of updating to 4.4.
The first version of X.Org was version 6.7 (which carried on the MIT X versioning system), which was released on March 31 this year. Now X11R6.8 has been released, carrying along again with the numbering system.
I hope that explains it for you.
No, the overhead of the X protocol is negligable. When doing profiling runs the bottlenecks are nearly always either in the serverhardware link or inside the toolkit. The applicationserver link doesn't really slow much down at all.
Umm. they have had that for sometime now, its called 'seamless windows' in citrix-speak. And has been out for at least a couple of versions now.. ( we expiremented with it 5 years ago, might have been beta then.. dont remember now to be honest )
You simply "publish" a single application specify that its 'seamless', and run it as a single window.. no 'citrix desktop' required..
We do it every day now, with hundreds of clients...
---- Booth was a patriot ----
Its not just that it looks nice. The technology behind it is what matters. The Composite extension for example double-buffers the windows (or something like that, I'm the person to speak about this) so moving your windows is much smoother, and you can notice that even now in this released version, where all those pieces are far from being "rock stable" or "fast". It also allows to have a miniaturized version of your desktop (one which is a _real_ miniaturized version of your desktop, with the miniature of a video player in other virtual desktop being updated, etc) much more easily. Damage can reduce greatly the amount of bandwith used in VNC-like clients, etc.
Shadows and transparencies are just one of the things which you can do with all those toys, but the fact that the pieces behing them are there is what matters, using the hardware to do all this, etc. As a plus, shadows and transparencies are nice (I'd like to have them even in the light window managers at least). I don't know why people is so concerned about "shadows are not useful". This is a win-win situation, no drawbacks.
No, the X Server is the program for displaying stuff. X11R6 just specifies a standard protocol. The protocol doesn't need to be a network one (and on your local machine, none of the X clients talk over your TCP/IP stack).
Anyone can implement an X server that adheres to the X11R6 protocol (and several UNIX vendors have; in the closed-source UNIX world Sun has their own implementation, and I bet all the others have too, although they may be based on the reference implementation - the old X Consortium X server). In the open source world, we have two implementations (which are very similar but now diverging - the XFree server and the X.Org server)
I don't know the historic reasons for why X was designed because I was only a small child in 1986 (I dare say somewhere on the Internet has the story as to why it was made in the way it was), but separating the client and the server like they have is extremely useful - the client doesn't care where the X server is or what the X server is. It means the client is well decoupled from the implementation of the X server - an X client running on HP/UX will display correctly on an X.Org X server running on Linux and you don't need to worry about DLL hell to make it all work - it just works. It's a very clean design and that's one of the reasons it's lasted so long.
As for the different implementations, X clients (i.e your programs) aren't linked to the X server or its header files. OpenWindows could be a radically different internal design with no header files in common with X.Org's server. What the clients link to is not the X server's header files - but XLib. XLib implements the client part of the deal, including the header files a C programmer would use. And XLib isn't linked to the X Server - it implements the X protocol (and that's why a Linux program written with Vendor A's xlib will work fine with Vendor B's X server running on some completely different architecture).
Oolite: Elite-like game. For Mac, Linux and Windows
"But why do we talk about a "protocol" ? Isn't X a program for displaying stuff ? I know we can use remote display on a network with X, but why isn't it only a feature ? Why is X so focused on network terminology?"
.h file to create windows, draw primitives, etc. Your program is compiled against some libraries that contain this drawing code directly. If you want to do remote displays across a network, you have to use some sort of add-on software or custom library. If you are coming from this paradigm, what you are asking is a very good question.
The fundamental design of X is different than say, MS Windows. It is always network-based. We have to talk about a network protocol because that is how every X client program communicates, even locally. It's not just an optional feature. Its the entire design.
In MS Windows, you write a program that calls functions in a
The difference is that every application that runs on X communicates over a "network". Whether you are opening Firefox on your own desktop or running an application on a remote server thousands of miles away, the application you are running connects to your X server and sends drawing commands over the "network". There is never any direct link to drawing code like there is in Windows - all commands pass over the "network". Of course if the application is local, optimizations are in place to make this communication very fast and not pass through the OS's networking stack.
This lets you do a very neat thing: Every graphical X-based program you have on your linux desktop can be run on any other X server. I'm not talking about just the few special ones that support it or link some special library. I mean every single program. Since you have to use the network even if you are running locally, to run on a remote server you just tell it to use a different IP address for the display. This is true network computing. The display is just an IP address and a port/desktop number.
Download an X server for your MS Windows desktop. Then log in to a Sun/Linux/BSD/etc box and you can run most any X application. There are a very small number of exceptions (like a program that requires an extention that your X server does not have, I.E. OpenGL for Quake3), but those are very rare.
In many ways, X is the most conceptually advanced and "network aware" desktop display system, despite being designed in the 1980s. Unfortunately, it is also painfully old in a lot of ways and painfully lacking in other, non-networking areas. The concept is really great and it works pretty well, but it would be nice to have a crack at redesigning the protocol based on other advances in computing. But failing that, I'm really glad that X.org is pushing things along and modernizing. The XFree86.org team had basically stalled out in a quagmire of politics and a need to cling to the past.
Uninnovate - Only the finest in engineering.
I wrote up a guide to setting up Xorg 6.8RC4 + X Composite with shadows and transperency the other day. These steps should also hold true for 6.8 final of course. Enjoy.
Unstable Apps: Our Android Apps Don't Suck
But why do we talk about a "protocol" ? Isn't X a program for displaying stuff ?
Nope. X is a protocol for sending drawing requests. An X server is a program for displaying stuff.
I know we can use remote display on a network with X, but why isn't it only a feature? Why is X so focused on network terminology?
Some features are just minor tweaks to a basic design that could exclude them, other features are fundamental to the design. Network transparency is fundamental to the design of X. Even when you're not using a remote display, you're always using the X protocol, but over UNIX sockets rather than TCP sockets.
And how about differences between XFree.org and X.org ? And OpenWindows ? Are they three implementations of functions (same ".h"s) for displaying windows and drawing things?
They're all programs that receive drawing requests in X protocol messages and then do their best to fulfill the requests by drawing stuff on a display. XFree86 and X.org are mostly the same codebase as well, but that's not really relevant to their functions as X servers. There are lots of other X servers around like OpenWindows, Hummingbird EXceed, MetroLink, Xi Graphics, XVision, and bunches more. Pretty much any X client application can use any of these X servers, locally or remotely, to display windows and draw things. Some X servers have more features than others, some have better performance than others, some support more graphics cards than others, but all implement the same standard protocol so they're all to some degree interchangeable.
But you asked about differences, not similarities.
Those are some examples of X servers and how they differ from one another. There are many, many more, particularly in the commercial X server space, but they all work with all X clients, locally or remotely, and the common thread that binds them all together is the X protocol.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
For now, Debian is tied to their heavily patched xFree86 4.3
3 1. html
s g00084. html
They have stated that they will not move to x.org until the modular version is available. Apparently it would take a lot of work to modify assumptions made in the apt-get respositories and they don't feel that the current release of x.org justifies the effort. Debian does acknowledge, however, that x.org is the future.
http://lists.debian.org/debian-x/2004/05/msg004
I am making the assumption the x.org's X11R6.8 is still a part of the monolithic tree.
More information here:
http://lists.debian.org/debian-x/2004/06/m