The X.Org Foundation announced today that it has begun tagging pre-release builds for the X11R6.8 release of the Xorg server & X Window System and asked for volunteers to start building and testing them. The Release Plan and Status web page lists the new features and changes included in this release, and updates on bugs found in testing so far.
X.Org begins beta testing for X11R6.8 release
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
A lot of people are gonna be happy about X Composite Extension being included in the new release. ^_^
Alright!
Shadowed and transparent windows!
Which distro will ship this release, Mandrake, SuSE?
this release of xorg will sure be included in Fedora
I suspect all of them 🙂
Can’t wait to get SuSE 9.2 with this and KDE 3.3!
> Alright!
> Shadowed and transparent windows!
>
> Which distro will ship this release, Mandrake, SuSE?
Gentoo 😉
The CVS version of Metacity looks for the composite extension when configuring. Hopefully this means nicer and fancier looking windows for Gnome.
All of the major one at least. Real question though is which distro will ship it first?
When will Debian ship it? In 2 years, when it runs on all 11 platforms? I hope they get it in experimental asap. Can’t wait to try it out!
WOW, these guys are really on track…
normally xfree releases take aaages to come around but X.org seem to be accelerating features in there.
nice work
Does KDE/Gnome/Whatever be compiled with support to X Composite to have those nice windows?
I think not but you never know…
Which distro will ship this release, Mandrake, SuSE?
Unfortunately mandrake won’t ship xorg 6.8 with the upcoming 10.1.
I like mandrake a lot but one thing really irritates me: why can’t they release their distro a month later, so that kde3.3, gnome 2.8 and xorg 6.8 can be included?
Maybe it looks cool that they’re always the first to release a distro, but they miss important packages.
Ah well, there’s always urpmi. I think that I can urpmi gnome 2.8 and xorg 6.8 when mandrake 10.1 is out.
According to the first comment: X Composite Extension, I don’t know what it is exactly. Can somebody maybe explain in non-technic language what the main important new features of the upcoming xorg release are (maybe a few screenshots…). Thnx in advance.
There’s no guarantee the compositing extension will ship enabled – they are currently going to default it to disabled as there are still bugs and other issues with it. This is a time based release, designed to fit in with the Fedora/SuSE release cycle, so it’s possible it won’t ship enabled or with driver ABI compatibility.
If that is the case, it’s no big deal. At their current progress I doubt it’d slip by more than a release cycle. So, at most it’s 6-8 months out from here.
For those not in the know: X compositing allows for lots of swish eyecandy a la MacOS. It also adds some useful features for, eg, screenshot apps which can now screenshot a window even when it’s partly covered. But most people want it for the eyecandy
This from Keith’s X Server but the technology is the same.
http://freedesktop.org/~keithp/screenshots/giantclock.png
Hi guys,
I will prolly compile this in the weekend, but if I get it running, any idea how to actually use the transparent window stuff? I mean how do I ask kde to make this window transparent??
Any testing guide is appreciated
this release of xorg will sure be included in Fedora
Looks like it shoud make into Fedore Core 3 based on the FC’s plans. However, for the Gnome Desktop it may not be ready in time for version 2.8. Hard code freeze is planned for Aug 30th, Aug 25th is the plan release date for X11R6.8. It would be nice to get an official statement from the Libgnome maintainers
will fonts look better/similar to windows now ?
The fonts in Linux have looked as good (if not better) than Windows fonts for a lonngg time now.
They may look a bit ‘different’, but its not ‘bad different’.
Before I switched to Linux I was really really used to the windows way that fonts are drawn on the screen..
But it only took me a day or two to get used to the way fonts look under X and Linux…
Composite is still pretty unstable. If you want to test it, get the Xorg source from CVS, compile and install it (make World; make install), edit your /etc/X11/xorg.conf to include the following statements
Section “Extensions”
Option “Composite” “Enable”
EndSection
Then get xcompmgr from freedesktops CVS (it is inside xapps), and enable the extension by the command xcompmgr -cf . If you are using the Nvidia binary drivers, please remember to add the line
Option “RenderAccel” “1”
to your devices section, otherwise performance can be really bad.
A few people have wondered what the Composite extension is and exactly how it works. Composite is a perfect example of the mechanism-over-policy way of thinking in X. The extension simply allows a particular client to split the rendering tree in two so that, for example, the X server draws the root window then splits the rendering of all top-level windows into a memory buffer. A client using the composite extension can then get access to these off-screen buffers and draw the windows on screen however they see fit. Keith’s example manager uses the Render extension to draw the windows slightly transparently and with drop shadows. Suitably written applications may even pass the compositing manager an alpha map for the window so that partial transparency may happen.
Its all beautifully simple and allows for all sorts of other things (for example, instead of Render use OpenGL to draw the windows as 3d texture-mapped polygons or send them over the wire to some VNC-type program on Windows allowing a kind of ‘rootless’ VNC – the possibilities are myrriad).
I compiled and successfully ran the current cvs tree of x.org this morning, and attempted to compile the xcompmgr from the freedesktop.org, however it states that “xcomposite” is not found.
Has anyone tried this yet and proved successful.
Some other strange problems I noticed, it now takes nearly 4 times longer to start GDM or KDM and Mozilla crashes when reading this page, works fine in Konqueror.
Anyone know which terminal font this is? It looks nice.
http://freedesktop.org/~keithp/screenshots/giantclock.png
I’m not 100% sure, but it looks like Bitstream Vera Sans Mono.
Everyone seems to believe this to be the best thing since sliced bread. I’d say around 50% of those who are “whoo” now will be “eww” if it does not fulfill all of their wet dreams (which it sure won’t, cause it is software and not dreamware).
I think it’s Andale Mono, no?
> I’m not 100% sure, but it looks like Bitstream Vera Sans Mono.
I think so too.
Anyone could explain whats the deal with Xprint?
What position it occupies in linux printing stack?
By reading some answers on on http://wiki.freedesktop.org/Software/XprintFAQ it seems that it has some redundant functionality with cups and clashes with Xft going suns STSF route.
Will it play nice with emerging printing architecture bringing some new functionality or will we end up with another set of redundant solutions that introduce more problems than they actually solve?
X11R6.8? I thought X11Rx.x is a name of standard, not just server implementation.
Will not X11 change from ‘standard protocol that anyone care of’ to ‘protocol used by Xorg server, everyone else tries to be compatible but not always success’??
To be as frank as possible:
The X Consortium released X, starting with version 1, and ten more versions followed, thus the last one being X11, release 6. This was open-sourced, and XFree86 overtook development. They just incremented the XFree86 version number and always left the X release number X11R6.
When X.org decided to fork XFree, they chose to use the X version numbers. The last release was already called X11R6.7, so it’s got nothing to do with protocol or anything, only the server implementation. It’s only confusing because XFree86 handles this differently.
Why? It seems pretty nice to me… the only bad things I think that can happen is:
1. Not all windows get shadow.
2. Pixel garbage when using it.
3. Being slow and bloated.
4. Not being included in this release o.O
5. Blow my graphic card >_>
6. Not work at all…
So what? I’m optimistic for a change!
Anyone could explain whats the deal with Xprint?
What position it occupies in linux printing stack?
—-
yes. it has been quite dead for a long time in Linux. lpd or cups is used instead
Can someone explain this in laymans terms – I heard that it made resizin/moving windows smoother – Someone quoted Windows, but in my XP doing any sort of resizing or moving is dog slow….
My current X is fine for this kind of thing….
Ben
Yes, I’m curious about Xprint as well. It seems, that it does PDF rendering like what Aqua does but also serves as a print-server. Does this collude with CUPS or LPR or are they just trying to simplyfy the printing interface.
Nice Changelog too. I remember going through the XFREE86 changelog and found them difficult to read. This is nice and clean – particularly with some HTML formatting added.
Its just the ability of X to precisely determine which parts of the screen needs to be resized and draw only that again instead of repaintaining the whole screen. its done much better with X damage
IIRC, XDamage can control what pieces of a window get “damaged” and needs redrawing, e.g. when you move a window over another, you “damage” the window in the bottom. Usually, toolkits redraw the whole (bottom) window again. With XDamage, the X can warn the (bottom) window that only a part of it needs redrawing. This mean less CPU power to draw windows, as it only need to draw part of it, not the parts that are not “damaged”.
If I’m wrong, I missed something in Jim Gettys’ presentation
I maybe mistaken-so if I am wrong correct me politely please;
Xprint was originally part of the mozilla project. At some point it got integrated into XFree86. Unfortunately there was no synching between the two versions. What xorg has done is to merge the latest version from mozilla back into the one now maintained at xorg. Xprint functions primarily as an interface between applications and what ever printer server you are using(cups/lpr/omni)-ie. Xprint exposes the functionality exposed in your print servers` printer driver to the applications-providing, at least in theory, a unified application printer interface to your print server. One of the problems in the Linux world is that there is no *single* application printer interface.
Although all KDE/GNOME applications can use their respective interfaces to the underlying print server(kprint/libgnomeprint) many applications do not support these interfaces,at least directly,ie.mozilla, adobe acrobat reader, star office, xpdf etc. In theory an actively maintained Xprint package would make it possible for all applications to have a common printer interface-which is of profound usability importance-ie. it is confusing when many applications each provide different printer/printer configuration dialogues each exposing different options and different features of the printer to be printed to…
Work is also ongoing looking for ways to integrate libgnomeprint with Xprint-which would allow for a transparent printer interface between all GNOME applications and those third party applications which hitherto have each had their own printer interfaces(dialogues)..Xprint offers exposes more functionality of the printer than does libgnomeprint. Of course then comes questions concerning libgnomecups/gnoem-cups-manager-which comes from ximian and is used in ximian openoffice(unlike normal openoffice or staroffice) and of course work now ongoing at integrating libgnomeprint with dbus-HAL work….And of course then comes the question of whether or not kprint will follow a similiar course of integration-which may be likely because Xprint is now, via xorg, officially a part of freedesktop.org…
It seems like XWindow doesn’t manage well the double-buffering paint mode, results that resizing or moving windows causes lags and jerks on the screen.
Is there something new in the double-buffering management in Xorg ?
On the other hand, is it true that Xorg will use hardware acceleration throw DRI or NVDrivers to draw windows on the screen as it is planned by MS in their upcomming Longhorn ?
Quote:
“On the other hand, is it true that Xorg will use hardware acceleration throw DRI or NVDrivers to draw windows on the screen as it is planned by MS in their upcomming Longhorn ?”
I sure hope not. There are still many cards that are unsupported by either. Even my freshly bought laptop has no support for these. For sure it would deter new linux users when they find their desktop has got extremely slow. Even though their cards “work fine in windows”. Also DRI is still not a complete replacement for manufacturer provided drivers.
Before we get caught up in eyecandy, we need more DRI support for more gfx cards.
In a way.
Presently X and windows draw in the same way, drawing directly to the screen losing a window’s contents when it is under another window. When windows are dragged the applications have to redraw in order to display what was under it. It was done this way because this is the most memory efficient, the window contents do not need to be stored only screen contents. Double buffering can be done in this scenario, but at a toolkit level.
New systems like osx, and in the future x and longhorn draw each window into its own memory and the combine the windows into the screen memory. This saves on having to redraw each window when dragging at the expanse of memory efficiency. It can also be used to create neat effects like expose and looking glass. It can also slow down window resizing since the window’s memory buffer needs to be resized and depending how it is implemented this can be an expensive operation.
Hardware acceleration can be applied to each part of this. Originally osx did it all in software, then in 10.2 it started using opengl to combine the windows only the screen (quartz extreme), and I believe that in 10.4 it will use opengl to do the drawing operations in each window as well.
With composite x can now use this newer drawing model. The combining can be hardware accelerated or not depending on what composition manager you use. I believe the reference one uses xrender which is not hardware accelerated in most drivers. For drawing the window contents x presently still uses the 2d hardware. In the future when cario (using the glitz backend) comes out vector graphics in x will use opengl to draw. There are also plans to move the x server over to use glitz for drawing, at which point everything in x will be accelerated using the 3d capabilities of our graphics cards.
So like most free software it will happen in an evolutionary manner. We are seeing the first releases now. Probably in a years time a lot of this stuff will be released and will be used by gnome and kde (kde won’t be using cario, but with qt4 they will be releasing their own opengl accelerated rendering infrastructure).
Expect delay from Fedora team
<snip>
Support for new ATI cards
* A patch from ATI was circulated that added support for the R420 (X800), R423 (X800 PCIE), RV380/M24 (X600 PCIE), RV370/M22 (X300 PCIE) and RS350 chips, Render support for all Radeon chips below R300 [already integrated by EricAnholt] as well as some misc laptop, CRTC init and Xv fixes
* This patch is currently being reworked in light of the recent DRI and Mesa merges by ATI and will be checked in when ready
<snip>
does this mean we now have free/open source 2d/3d drivers for about all ati cards ?
There are certain aspects of the Composite extension that X has completely control over. One major example is drop shadowing. X completely controls windows boundaries, positioning, sizing, layering, and so forth. Therefore it is a (relatively) simple matter to enable drop shadowing and get those nice drop shadows on any window, regardless of what’s drawn inside its boundaries.
The transparency/translucency aspect of compositing does need some support from above. For example, Fluxbox’s 0.9.x branch has supported alpha mapping in menus, window decorations, and panels for some time now, but it doesn’t do anything yet (it will with the Composite extension). Complex and unique GUI’s like OpenOffice may never get compositing support, unless all of those XUL objects are reworked to support it. Perhaps the saving grace here is that DE-compliant (GNOME or KDE) applications can all receive some compositing eyecandy in one fell swoop through libgnome or kdelibs.
Either way, and as stated much earlier in this discussion, I’m proud of the pronounced acceleration in developer interest and participation brought on by Xorg. At last we have a FOSS X11 project that encourages the inclusion of the community.
does this mean we now have free/open source 2d/3d drivers for about all ati cards ?
You need an NDA to have access to sources for 3D hardware acceleration for ATI cards.
But what can be taken away from this is that things are really starting to progress. Every since freedesktop.org was formed many people, like the Ximian bunch, praised it as a major breakthough and I think we’re started to see this happen.
You can already see the major hurdles of the linux desktop being crossed, like integration, interopability, and maturity.
So while composite might not be ready and certainly applications like Gnome and stuff will take longer to take advantage of all it offers I think there is a lot to be excited about here.
I must say it has been pretty quiet among the “X sucks” crowd lately.
Maybe the X inventors were on to something good after all.
Maybe they understood that it was implementation (Xfree86) of protocol (X11) that sucked, not the protocol itself.
Hey guys, XFree86 had a new release recently, too. Its got autoconfiguration and DMX stuff and it still runs on a few Linux distros. What about XFree86? Why don’t you wanna play with it anymore?
I think XFree86 is getting lonely..
To hmmm,
I don’t know if you’re aware of XFree86’s new licensing scheme, but thats why Xorg is now the standard
We’re just waiting to see which direction the new xorg goes.
No reason to go after a group who’s idealogy you don’t know about.
If you run fedora, then there are RPMs available at http://freedesktop.org/~krh. There will be official RPMs in fedora development soon though. You can use that link in your yum.conf file as well.
I was wondering if we’re going to see performance improvements or is it more a feature release?
Hooray for a bigger and even more bloated version of a 20 year old window server! Seriously, can’t we just start from scratch and make ourselves a window server based on modern technlolgy? Does every new addition to our Linux/UNIX desktops have to be a shameless hack or workaround? Its beginning to look alot like Windows 3.1.
>I was wondering if we’re going to see performance improvements or is it more a feature release?
Well, the new Composition extension uses wastly more memory,
so when apps starts using it, you’ll probably see more memory
wasted..
Hooray for a bigger and even more bloated version of a 20 year old window server! Seriously, can’t we just start from scratch and make ourselves a window server based on modern technlolgy
—–
ya. throw away everything and start from scratch. that really makes sense. get a clue
what are you talking about? the X11 protocol is fine. It is really modular and you can design modules to catch up any new feature apple or microsoft may realase. Keith Packard and the rest of the crew just proved it. 20 years old or more is also the design of unix. And as much as you may think that it is old, its architecture is the one that will be out there you want it or not for the most OS. Just take a look at macosx. It is pretty, solid, fast and easy to use. Most of macos users don’t even know that there is a unix os underlying all the fancy gui.
Actually no, the X protocol is not fine.
It was a good idea on paper, but was supposed to be replaced after a while.
The problems with the X protocol are inherently evil.
Network transparency is a myth heavily crippled by too much data on modern UIs, also higher latency times are problematic.
There are various solutions to hack around those problems like VNC or NX.
The x.org people are totally aware that in the long time the current X protocol needs an overhaul or has to be replaced.
They are working on it ans with Cairo there is a smooth replacement in the line which permits higher level drawing functions than X does. The transition as far as I can understand it will be smooth. First Cairo will be another layer on top of X replacing the old x drawing libs. Then it will be rooted into opengl (already possible) for the fastest drawing speed possible for client only machines and in the long run it will replace X entirely, with X being a legacy which will be carried along the way.
At the end of this road there will be a display pdf system like Apple has it already and Sun already had it ten years ago.