Slashdot Mirror

What do you mean, accidentally typing sudo? You will be asked for a password unless you have (insecurely) set up a nonstandard passwordless sudo configuration. How would you accidentally enter your password?

So the answer: no relation between the risks. But it looks to me that standard Xorg installs are not vulnerable because they are not normally installed with suid on the X server. My Debian system is certainly not configured that way. According to the advisory the exploit is only possible if the X server (Xorg) is running suid.

Please correct me if there are any distros out there installing Xorg as suid. I doubt that there are.

This is a prime example for the necessity of libre drivers.
The good news is, libre drivers for Nvidia GPUs exist, and they continue to work on 32-bit Linux.
AMD Radeon GPUs have much better open source compatibility, though.

Same AC here. On Linux, this is how you'd do that is below -- preface: I do not use X/X.org (last time was in 1995!), so please take some of what I say with a grain of salt. The version of Ubuntu you're using matters greatly too. Someone more familiar with Ubuntu as a workstation/desktop, please comment!

1. Try digging around for resources relating to X.org, as that's effectively what's driving all the GUI bits and interacting with the video driver. I think this is xorg.conf or xorg.conf.d/ and there may be a config file setting (warning: that file/directory will probably scare you). I don't think your WM (window manager) is relevant,

2. Research options described in Ubuntu's Community Support; pick one or several and post there,

3. Try to track down the authors (committers) of the associated video driver and ask them. I did the work for you as best as I could: the X.org driver is called xserver-xorg-video-intel (assuming that's the chip you're using). There's supposedly an alternate driver from Intel themselves here but I have no idea if using it would solve anything (I wouldn't recommend doing the latter on a whim; I prefer to use Ubuntu packages natively if at all possible),

4. Use Launchpad to file a ticket with Ubuntu directly. Also advise searching their system to see if someone else has asked the same thing (try looking for separate terms "tearing", "vsync", "v-sync", or "vblank").

I also own an Intel NUC, but it's a headless server box for building third-party MIPS and ARM router firmwares, so I don't use the GUI (I don't even have a monitor hooked up to it). Plus we might have different NUCs (their on-die GPUs certainly differ between models), and I'm running a fairly old Ubuntu (intentionally).

Sorry I couldn't be of more help, but the above steps is the road I would take if I had to deal with said issue.

X11's main flaw is that it's supposed to be inefficient.

It's so much more than just inefficient.

First the there is the security issue. X security is inexistent. The problem in the last link is by design and it is simply unfixable.

X is big, as in really big, old, poorly written and it typically runs as root. Any buffer overflow or unchecked parameter is a potential privilege escalation vulnerability. Do yourself a favor and don't that dinosaur in your servers.

X is bloated. It has stuff in there like font rendering, drawing primitives, printers, mode setting, dozens of extensions and things that nobody uses. Nowadays, toolkits render their own fonts, and manage their own windows and essentially hand over a large image to the X server. The X server does not even render the image, it handles it to the compositor. X does not set the video mode, the kernel does that. X does not handle keyboard and mouse, it sends the data to the compositor, the compositor tells which window should receive the input and X sends the input event to the corresponding application. In short all X does nowadays is IPC, and there are millions of lines of code just sitting there doing nothing right next to this IPC.

It turns out that it is even terrible at IPC. An application does hundreds of requests to the X server just to display a simple window. You know what the worst case is for that? yeap, remote display. All the back and forth is really disastrous over a slow connection like the internet.

People say network transparent. Well, more like network capable. DRI does not work over the network at all.

Something supported by Mac OS X and Windows for decades like VSync so your don't see tearing is not doable in X.org, there is no way to wait for a screen refresh or prevent X.org from rendering your partially drawn window even with double buffering.

I am guessing you embrace the unix philosophy? if so, what is the one thing X does and how is it doing it well?

Heck, the wayland developers are the same X.org developers. They did miracles to keep X.org alive for so long, but they are moving on to greener pastures.

I would highly recommend this talk by Daniel Stone. He does an excellent job explaining why X.org is obsolete and unfixable.

You wrote that Wayland is the future of X. That's as ridiculous as suggesting a bridge in Alaska is the future of Miami.

So you still don't understand that X is the future of Y does not mean that they share anything other than once Y will be deprectated X will take over it's place and function even though I now have written that three times? Very great for some one who claims that others fuck up...

No. One guy who worked on two X extensions and another guy that did a port to a Debian variant is a tiny drop in the bucket of the developers of X.

I just did a quick look at the changelog from X.org at https://www.x.org/releases/X11... and cross checked names with people who contributed code to the Wayland project and stopped after finding these 7 names: Jesse Barnes, Kristian Høgsberg, Peter Hutterer, Daniel Stone, Gaetan Nadon, Jeremy Huddleston and Josh Triplett. The first three on this list also seams to be the major contributors to X.org in terms of code so hardly the "tiny bucket" that you describe. The most active X.org dev is Alan Coopersmith and he seams to be all in for X.org at the moment though.

You did worse than that, you wrote the following lie:

However the "X sux" is said by the X developers

Why are you trying to start a fight over a topic you know absolutely nothing about? Wayland is not X.

You do realise that the "X sux" part was a direct quote from your text and not my opinion? And nowhere have I claimed that Wayland is X in any way, shape or form

I think he means this.

Mouse scroll wheel support is a waste of bytes, real mice have three buttons and that's it.

Three buttons? Luxury! Real mice make you use the Emulate3Buttons option to simulate the third button!

wayland initially was infested by the type of developers

Wayland was founded by the X developers who wanted to call it X12 but realized that people would freak the hell out if they fixed it the way that it needed fixing, based on their experience with X11.

Do you mean Kristian Høgsberg? I'm curious about how they needed to fix X11 and Wayland being the incremental successor X12, would you elaborate? Got a link?

> From the XFree86 web page:

>> XFree86 Release 4.8.0 is out NOW

>> 4.8.0 release was released on 15 December 2008. Our next full release will
>> be 4.9.0, and is expected to be released in the summer/winter of 2009

[...deletia...]

> How's that working out for you?

In case you missed it, there was an internal revolt inside the XFree86 group, and XFree86 code was forked as Xorg, which is the current implementation. The last person to leave the XFree86 project forgot to turn off the lights.

XFree86 is passed on! This project is no more! It has ceased to be! It's expired and gone to meet its maker! It's a stiff! Bereft of life, it rests in peace! If you hadn't nailed it to the perch it'd be pushing up the daisies! Its metabolic processes are now history! It's off the twig! It's kicked the bucket, It's shuffled off its mortal coil, run down the curtain and joined the bleedin' choir invisibile!! THIS IS AN EX-PROJECT!!

See the current Xorg location http://www.x.org/wiki/ It actually has stuff from late last month, rather than late last decade.

For example there used to be a keystroke for killing grabs. They removed it claiming it was "unnecessary" because you only need it if there's a bug in an application.

They removed it because it was a security problem, not because it was "unnecessary". You could use it to bypass lock screens, which are implemented in part through screen grabs.

The AllowDeactivateGrabs and AllowClosedownGrabs options are available in xorg.conf if you want to restore the original insecure behavior.

It's unclear whether most of the FUD in this discussion is directed at the GPL itself or specifically v3. But it's entirely unfounded.

It's not FUD, and its about the GPL in general - although being GPL3 makes it worse. "GPL2 or later" would have been a better (but still flawed) choice.

You know why libraries aren't generally licensed GPL, right? Anything that links to them has to have the exact same license as the library. For instance, the GPL2 licensed Inkscape can't use this library.

That's the difference between the GPL and the LGPL. You can link to LGPL libraries from any software; you can only link to GPL licensed libraries from code with the same version of the GPL.

In RMS' ideal world, all software would move to the latest GPL and it wouldn't be a problem. Good luck convincing these guys of that.

This is the appropriate license for this image format.

The GPL is not the appropriate license for any general-purpose library. That's what the LGPL is for. Or, like most reference implementations, a non-copyleft license like the MIT license.

Look, I get it, you're a promoter of software freedom. So am I. But this is the real world, and this is a reference implementation. There are conventions to follow for reference implementations, and an OSS non-copyleft license is one of those conventions. This image format could outperform every other format on the planet and it will still see no adoption outside of academia unless there's a compatibly licensed library available. Unless it gets relicensed, or someone writes a non-GPL library, this will go down as just another interesting format that sees no adoption whatsoever.

I'm not sure how - note that Daniel Stone (the presenter) appears here http://www.x.org/wiki/BoardOfD... - so he's one of the current folks in charge of dealing with the current xorg code; who better to judge the current state of xorg than someone who works with it every day? Another good presentation on the current state of X and its problems: http://youtu.be/2l7ixRE3OCw

I've been using a Kensington Slimblade trackball for a while, and I honestly consider it one of the best pointing devices ever made. The scroll function takes a little while to get used to, but it's probably the best implementation of a scroll "wheel" on any trackball.

Out of the box on Linux, the top left button is middle click and the top right is "back". I switch these and add a nice acceleration curve with a custom XInput config. It allows minute movements while retaining the ability to flick right across my 2560x1440 monitor in one finger movement.

The config is as follows:
/usr/bin/xinput set-ptr-feedback "Kensington Kensington Slimblade Trackball" 0 18 10 &
/usr/bin/xinput --set-prop "Kensington Kensington Slimblade Trackball" "Device Accel Profile" 2 &
/usr/bin/xinput --set-prop "Kensington Kensington Slimblade Trackball" "Device Accel Adaptive Deceleration" 3 &
/usr/bin/xinput set-button-map "Kensington Kensington Slimblade Trackball" 1 8 3 4 5 6 7 2 9 10 11 12

The first line sets the acceleration curve, the second sets polynomial acceleration, the third adds deceleration at low speeds and the fourth remaps the buttons. All of the possible tweaks are detailed here: http://www.x.org/wiki/Developm...

I am continually annoyed that Windows does not let me set per-device acceleration settings, when it is relatively easy on *nix systems with a bit of tweaking.

If I was publishing an article talking about how huge numbers of eyeballs solves security problem I'm not sure that I'd choose to publish it the day after it was announced that the X window server code has had some serious security bugs for 25 years that have only just been discovered. Clearly open source code can have serious security holes that go unnoticed for a very long time.

Even the current developers of Xorg disagree with you

Well, they also disagree with the benchmarks. Besides they've been plugging anti-X FUD since they came up with Wayland.

That's exactly ONE driver - intel. And glamour is a HACK.

http://www.x.org/wiki/ExaStatu...

Hmm yes only one card supports EXA with RENDER acceleration. One, that is if you ignore all but one. Never mind that the proprietary AMD and NVidia also accelerate these features.

It does a double-reacharound to do what wayland does by default (and any other sane windowing system). With adding the X protocol cruft with all it's stupid extensions on top.

I love how you argue with complete and utter ignorance of both X11 AND Wayland.

Wayland doesn't specify any sort of acceleration at all. It's a protocol for sharing pixel buffers, and a bit of input device handling. You can go and implement a Wayland compositor using OpenGL for accelerated compositing of the buffers if you like. Weston is exactly this.

And you still haven't explained why Glamour is a hack (will be tricky because it isn't). X11 specifies a bunch of 2D drawing operations. Glamour implements these in OpenGL shaders. So, once you have an OpenGL surface up, you can accelerate all operations.

No, I'm not. First it was XAA, which did shitall.

No it didn't. You clearly never ran VESAFB back in the 90s which really was unaccelerated. The difference was vast.

Then it was RENDER, which supposedly did what glamour does now.

Oh for fuck's sake, you have no clue about any of the underlying technologies whatsoever.

RENDER is an extension for specifing a bunch of new drawing primitives for the X protocol. It has nothing AT ALL about how these are implemented. Nothing. It's a protocol or if you perfer, API spec. Glamour is an implementation of X11 drawing primitives using GLSL.

See the difference?

No, doing 2D in shaders is exactly what you want. Gluing that to the X protocol is patently stupid and counterproductive. It's a stopgap until the Linux desktop adopts wayland.

WTF? The acceleration is done after the X protocol is decoded. The program speaks X. The server decodes the X protocol and then draws it using OpenGL. This is just like any other OpenGL accelerated drawing API: API is decoded then drawing happens.

Actually, it did.

No it didn't. As I pointed out XAA (which is hardware accelerated rendering whether you like it or not) came out in 1996. That was years before OSX even existed.

EXA which accelerated the RENDER extension (actually, acceleration existed before that, EXA was designed to make it work across drivers better) came out in 2005, the same date as you quote for OSX.

The claim "OSX got hardware accelerated rendering first" is blatantly wrong.

And no, hacks like glamour (which got release a fucking month ago!)

I've really not sure what you've got against glamour. Either way, it's designed to obsolete EXA, which will hit it's 10th birthday next year.

Glamour is the FOURTH 2D grapics acceleration generation in the XFree86 derived series. There was ad-hoc stuff first, then XAA, then EXA and now Glamour. Yet for some reason you are despreate to claim that OSX was first even though XFree86 had accleeration before OSX even existed.

Basically you seem to be wildly misinformed about several things:
* What hardware acceleration is
* What X11 does
* What Wayland does
* What Xorg does and did in the past
* What the X protocol is

And yet you argue anyway. I admire your spirit!

So he hacked X to make it work in wayland - among many other things he does with X. This does not imply he gave up working on X in favour of Wayland. A better indications about doing the development activity and who is doing what are the mailing lists:

http://lists.x.org/archives/xo...
http://lists.freedesktop.org/a...

The idea that all/most X hackers gave up on X and are now working on Wayland as its successor is far from the truth.

Also - maybe I gave a false impression - but I am not opposed to Wayland. It is rather nicely designed and well written piece of software. What makes me angry is the idea that it is declared the future of Linux we all have to switch to when it clearly also has some downside, e.g. broken compatibility and network transparency. But those things are not openly discussed, instead they are "adressed" by FUD such as "network transparency is already broken". Oh, you are using it? You must be a lier because Daniel Stone told us it is already broken.

Andy Ritger at Nvidia is already in talks with Ben Skeggs and Martin Peres with Nouveau. They're are going to hash out the details at XDC2014. The impact for Nouveau is in the packaging and distribution parts of the cycle, not development. Also, it was Nvidia who reached out to Nouveau, not the other way around. Nvidia has their reasons for doing this, but it's not an anti FOSS thing. It's more likely one of the more sane reasons posted above.

So everyone just relax their sphincters a bit....

Sure, if you were building dev releases. And as per patches like http://lists.x.org/archives/xo..., you needed systemd-logind.

The point is 1.15 couldn't, and 1.16 can with systemd components. I think calling development builds of the 1.16 branch "previously" is quite disingenuous.

I know it never ran on IRIX - IRIX uses XSgi. The HP-UX box I currently have access to (which is horribly outdated) is running XFree86. AIX, however, does use X.Org. (BTW, IRIX wasn't EOL until the beginning of this year)

bash-4.2$ /usr/X11R7/bin/Xorg -version

X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: AIX IBM
Current Operating System: AIX aix71 1 7 00036A2AD300
Build Date: 07 July 2006
                Before reporting problems, check http://wiki.x.org/
                to make sure that you have the latest version.

I've been using Linux/UNIXes for 15yrs now. One of the beauties of X11 has been the fact that the application programmer typically does not even have to /plan/ for network transparency - it's built in right from the start (in the various graphics toolkits), no special APIs to .

This means that whenever the users have a need for displaying X11 apps remotely (e.g. needing to deploy new thin clients at short notice to accommodate new staff in a corporate environment - very quick setup time), you just simply set $DISPLAY and away you go. I've long come to count on this feature and I value having that option kept open all the time.

I believe in the future fibre optic LAN equipment will come down in price and will offer much lower-latency and higher-throughput than today's copper-wired Ethernet. It may even get to the point where transmit times of sending bitmapped real-time graphics over fibre may be as fast as a CPU writing to a reasonably modest PCI/AGP graphics card.

I think the Wayland project is making a SERIOUS mistake in treating network transparency as a second-class citizen, and will likely see the project relegated to a toy-like status (useful only for gaming and entertainment, or apps that need extremely low video latency like video editing suites) and shunned by the corporate world.

If the current X11 protocol makes it hard to do anti-aliased text, glossy/brushed GUIs, zooming fading menus, wobbly exploding windows and the like, then what we need is a new set of core drawing primitives, much like Apple's Display Quartz system (IIRC). Call it X12 if you will, but keep the network transparency in and that decision will pay off many times over.

I personally have no need for such resource-hogging eye-candy - I turn all of that off and prefer a minimalistic slick-but-functional snappy inteface. I am perfectly happy with X11, and all the current-version applications I use work well with it. It has its quirks and faults, but I believe they can be reasoned with and there is certainly room for improvement: http://www.x.org/wiki/Developm...

I also think the Wayland proposals of polling (pixel-scraping) window buffers and sending them over rdesktop for remoting is only going to lead to massive CPU overhead on shared application servers, for one thing.

At the very least, I'd like to see the major graphics toolkit groups (Qt, GTK, WxWindows et. al.) collaborate on designing a standard remote drawing protocol that has similar transparency to X11 - then I might have more respect for Wayland attempting to replace X11.

(sorry for double post - accidentally selected wrong formatting mode. Mod my other post into oblivion if you wish).

I've been using Linux/UNIXes for 15yrs now. One of the beauties of X11 has been the fact that the application programmer typically does not even have to /plan/ for network transparency - it's built in right from the start (in the various graphics toolkits), no special APIs to . This means that whenever the users have a need for displaying X11 apps remotely (e.g. needing to deploy new thin clients at short notice to accommodate new staff in a corporate environment - very quick setup time), you just simply set $DISPLAY and away you go. I've long come to count on this feature and I value having that option kept open all the time. I believe in the future fibre optic LAN equipment will come down in price and will offer much lower-latency and higher-throughput than today's copper-wired Ethernet. It may even get to the point where transmit times of sending bitmapped real-time graphics over fibre may be as fast as a CPU writing to a reasonably modest PCI/AGP graphics card. I think the Wayland project is making a SERIOUS mistake in treating network transparency as a second-class citizen, and will likely see the project relegated to a toy-like status (useful only for gaming and entertainment, or apps that need extremely low video latency like video editing suites) and shunned by the corporate world. If the current X11 protocol makes it hard to do anti-aliased text, glossy/brushed GUIs, zooming fading menus, wobbly exploding windows and the like, then what we need is a new set of core drawing primitives, much like Apple's Display Quartz system (IIRC). Call it X12 if you will, but keep the network transparency in and that decision will pay off many times over. I personally have no need for such resource-hogging eye-candy - I turn all of that off and prefer a minimalistic slick-but-functional snappy inteface. I am perfectly happy with X11, and all the current-version applications I use work well with it. It has its quirks and faults, but I believe they can be reasoned with and there is certainly room for improvement: http://www.x.org/wiki/Developm... I also think the Wayland proposals of polling (pixel-scraping) window buffers and sending them over rdesktop for remoting is only going to lead to massive CPU overhead on shared application servers, for one thing. At the very least, I'd like to see the major graphics toolkit groups (Qt, GTK, WxWindows et. al.) collaborate on designing a standard remote drawing protocol that has similar transparency to X11 - then I might have more respect for Wayland attempting to replace X11.

The spec in question - http://www.x.org/docs/XKB/XKBp... as Peter references in the bug comments - discusses StickyKeys (4.4 on page 9) and strongly implies modifiers only unlatch on key presses; mouse buttons are not mentioned. His change made the code match this reading of the spec. I have a hard time believing that's what the spec writers intended, but if so then KDE's lock checkbox really isn't supposed to do anything.

Reading the bug report commentary, it appears there's an error in the specification: http://www.x.org/docs/XKB/XKBp... that Peter Hutterer propagated into the code. The specification should be fixed as well as the code. Peter's comments about the change also discuss a null-pointer dereference problem - I'm not clear how that is related to the change - and therefore whether reverting the change is the complete solution.

The specification appears to be dated 1997-12-15, so all this is blowback from 16-year-old specification error.

Having seen plenty of serious bugs sitting unfixed in bug reports for years and years, I don't think the problem of enormous bugfix latency is particularly related to or limited to acccessibility issues.

If you watched the video, it also mentions Kristian Hogsberg (who started Wayland), so that would make it plural.
If you want more, there's also Martin Peres, Matt Turner, Egbert Eich, Rob Clark, ...
You can find their names in the Wayland mailing lists and on the X.org site .

This is what I hate about GPU (opensource) drivers. Never EVER can anyone give full explanations on what the heck is going on. Instead we get oblique hints which more or less equals "RTFS". Or in some rare cases, RTFM. Every time I try to google this stuff up, I ragequit in despair after two hours.

So you're saying you can't write Java without understanding how the JVM is built? The firmware provides you with a very low level API that is very similar to assembler, it's more like runtime-loaded microcode than normal code. If you really care to try, I suggest you start here. Basically you place commands into a ring buffer that is read by the command processor (CP) on the graphics card and then executed on the GPU. There's a ton of registers you can set up, tons of commands, tons of formats (like all the texture formats) and while it is documented it's literally thousands of pages all together.

For example, for the Southern Islands generation alone there is:
229 pages of 3D register documentation
298 pages of instruction set architecture
49 pages of programming guide which expands the
54 pages of evergreen/cayman programming guide which expands the
43 pages of R600/700 programming guide.

Those 700 pages only walk you through the very basics of programming the GPU though, like assembler for a CPU. Beyond that there's very little in the way of tutorials, look at the existing source and figure out what it does down to the registers it sets and commands it sends. By the way, if things are not done in the right order the behavior is often undefined and may lead to soft or hard lock-ups. Personally I gave up because I realized the massive complexity of a modern GPU, quite frankly programming it at this level is extremely difficult.

it used to work fine for older kernels, but for newer 3 series kernels on ubuntu it just doesn't work. No matter what you do.

Most distos don't even ship with xconf any more, and haven't for most of the past decade.

"X RandR is used to configure which display ports are enabled (e.g. LCD, VGA and DVI), and to configure display modes and properties such as orientation, reflection and DPI.

This is the simplest and most powerful way to get multi-monitor systems working using recent versions of Linux."

http://en.wikipedia.org/wiki/RandR
http://www.x.org/wiki/Projects/XRandR/

Thanks for covering this. It appears other tech blogs such as Phoronix like to ignore Vivante, but their market share has increased a lot over the last year, mainly thanks to Freescale and Huawei.

I'm a bit sad that my blog post on GC2000 OpenCL is being used to bash Vivante. Many of the problems I encountered were due to drivers, not hardware limitations. They were still taming LLVM at the time. And you simply cannot expect the same performance and features from a mid-range embedded project as from desktop. There are very different power and area constraints. No one has done Mobile OpenCL right yet.

At least the Vivante GPUs have a straightforward, scalable, even desktop-like architecture. See Rob Clark's XDC slides http://www.x.org/wiki/Events/XDC2013/XDC2013RobClarkARMOpenSource/soc-graphics-update.pdf , Not a bag of hacks such as PVR (which look good in benchmarks but are a hell to work with), so there is hope of better drivers being developed, either the open source drivers we're working on, or through improvements in Vivante their own drivers.

xcb (the application, not the library) works nicely for multiple buffers.

Have you tried the Radeon (open source) drivers? The R400 (which is the "engineering" name for the R690M) is listed as supported on http://www.x.org/wiki/RadeonFeature/

Does intel make an HD7850 counterpart? Your comment lacks a lot of perspective.

Full prick mode: Also I wouldn't say that they claim there's a open source driver for it. It is not like they market it that way with a big sticker on the box. There are a lot of missing features yet for the whole south islands series and there are a lot of bugs. This is /. you should know these things.

Nice mode again: It is one thing that your card is a year old, but you should have bought something older or done some more research. I went full ghetto (in early 2010) and bought a 4670 and have had no problems with the setup. And it was cheap, the kind of cheap where you don't care that you are using a potentially slower open source driver.

And this would be a possible roadmap for X12:
X12 Development
Reading that list also makes a big argument against X11, and it seems to me that Wayland will be the place where lots of things will be better.

I'll be generous and say there are probably all of 50 generic display device drivers written specifically for X11, probably the same for Apple, and maybe double-triple that for Windows drivers. It isn't exactly a large playing field for development efforts to just pick up from nothing, which is also why 99% of drivers are written by the manufacturer of the device.

You could always look into http://www.x.org/wiki/Development for guidance, but in the end code is king. X Development is not simple, but neither is graphics development in general, which is why every card on the planet has a large set of incompatible surfaces that all get crushed together behind huge drivers in order to spit out a more or less coherent systems interface that a display server will interoperate with.

X11 supports touch, as does Wayland of course.

The amazing GUI you saw in that video is built on Qt, and can be run on any platform supported by it with some minimal effort.

"theme based icon recoloring" is implemented in the GUI toolkits.
"1/4 sizing screens" is a job for the compositor, in either system.

The biggest user-visible difference between Wayland and X11 will be tear-free display in all circumstances, provided the application's developer has half a clue.

The biggest differences for developers will be the sane (for today's requirements) architecture and vastly simplified API (a big deal in itself).

mille, as long as Hasbro doesn't kill it (I presume that's why there's no "bornes" in the name). At one point, it was one of my favorite toys for "compiling!" xmille (and the accompanying README) if you want a GUI.

mille, as long as Hasbro doesn't kill it (I presume that's why there's no "bornes" in the name). At one point, it was one of my favorite toys for "compiling!" xmille (and the accompanying README) if you want a GUI.

This page is your friend: http://www.x.org/wiki/RadeonFeature

Don't buy a 7xxx (Southern Islands) or (I assume) a 8xxx (Sea Islands) card, since they don't have open source 3D drivers for Linux; a 6xxx graphics card is the best bet (Northern Islands). For integrated graphics, I suppose the 2012 A series trinity should work, since it is based on the well-supported Northern Islands GPU.

At one point in time, even until recently the 4650(?) card had the most value/performance/usefulness under linux with the open source drivers. I am not sure if this is still the case. Something to see... Any way I have no proof, take it with salt. I have a 4670 and it runs ok for what I have done so far on Linux. It was cheap 3 years ago, should still be cheap. I have never installed the proprietary Linux/ATI driver, nor wanted to.

If you talk about ATI and say "until they open-source their drivers", I must assume you're talking about ATI's closed source Catalyst driver?

Have you tried the open source Radeon driver (preferably an up-to-date version) with your card? That driver has made great strides in the last few years, currently supports a long list of cards (likely including a 2 year old card), and is under active development. "nothing has ever changed" does not apply to that driver IMHO.

Beside that, there may be user-configurable options @ play. For example: I recently had an old Radeon AGP card where the difference between "locks up a few seconds after starting 3D game" and "runs totally stable" was made by forcing the card into AGP 4x mode. Took some time to figure out that was the problem, but once known, it's easy to make that setting in your Linux distro of choice.

Well, AMD is looking good too, with currently shipping Fusion parts for laptops all being Evergreen or Northern Islands, both supported by the open source xorg Radeon driver, with a few exceptions such as full screen antialiasing, which seems to be getting close but currently requires the Catalyst driver. See here for the current xorg driver state. Notice that everything you need for 2D and 3D graphics is there, up to but not including Southern Islands. Just taking a quick look around, it looks like the latest budget AMD laptops are Trinity, which is Northern Islands, which should work fine with the current Xorg driver. But definitely google the specific chipset. Power management... good question. I'm getting solid results with Ivy Bridge, I haven't tried AMD's laptop parts recently.

Here is some info regarding out of box support with the open source driver

28 Mar 2012: 6.14.4: Trinity APU support, 2D tiling on R6xx+, KMS tiling for r1xx-r2xx, lots of bug fixes
2 Nov 2011: 6.14.3: Llano APU support, KMS page flipping fixes, vdpau/XvMC support, tiling fixes

I must admit though, I run an ATI 4670 in my tower which coincidentally has been recommended as the best performing with open source drivers - pretty good for a cheap video card I bought in early 2010 and am still happy with. No setup. It just works. I bought an old card, even at that time, explicitly to have open source 3d. As to this article: I have loaded a live disc on my laptop w/ Llano (to verify the above a while back) but I still run Windows 7 on it to play games like Torchlight and now Torchlight 2. I didn't try anything in the way of 3d while booted into Linux on Llano.

I'd like to see more vanilla versions of this software.

Well sure.

Here's the protocol extension: http://www.x.org/releases/X11R7.5/doc/randrproto/randrproto.txt

Here's the xlib API:
http://xcb.freedesktop.org/manual/group__XCB__RandR__API.html

Here's the command line tool:
http://linux.die.net/man/1/xrandr

And here are a bunch of GUI wrappers:
http://christian.amsuess.com/tools/arandr/
http://wiki.lxde.org/en/LXRandR

Which would you like?

Open Source Software has become almost as bad as the commercial counter parts in wanting to wrap everything up as one big GUI package. I don't want a bunch of bologna to download and run to configure dual monitors if I want to use a very lightweight window manager, or setup an embedded solution such as a kiosk.

Some times yes, but this isn't one of those cases. It's one of the nice really well designed parts, and not only that but any of those tools will work with any system. They modify the monitor layout, X sends a RANDR XEvent to the window manager and everything just works.

At the time, it was the prettiest of all. I mean it was so much better than XT or Athena.

If by "XT" you mean "Xt", it had no look-and-feel; it wasn't a toolkit, the "t" in "Xt" standing for "toolkit" nonwithstanding. The full title is "X Toolkit Intrinsics", or just "the Intrinsics", as per the documentation; as the documentation says:

The Intrinsics are a programming library tailored to the special requirements of user interface construction within a network window system, specifically the X Window System. The Intrinsics and a widget set make up an X Toolkit.

The Athena Widgets were a widget set using the Xt Intrinsics; I'm not sure looking even remotely pretty was a goal of that widget set.

Motif was also implemented as a widget set atop the Xt Intrinsics (and there was an OPEN LOOK widget set, OLIT, as well, in addition to Sun's XView port-and-OPEN LOOKification of SunView atop Xlib).

However, AMD/ATI is a PR stunt. The drivers just wrap non-free software and can't be utilised at all on truly free software platforms.

Seriously? What do you think this is about? What's the licence on this that makes you think it's non-free? You seriously don't think this licence cuts it?

http://www.x.org/wiki/Development/X12 Even this page on X.org lists a lot of great reasons why X11 is outdated and needs to replaced, yet I don't know of any serious project to create a new, modern X. All X development is focused around fixing and extending X11. I guess X11 has become so big and so universal that there's no real desire to tear it down and start from scratch.

The closed drivers have serious quality issues with major regressions seemingly every other release.

The open drivers are making great strides, but the performance isn't there yet for newer cards. If you are using a pre-HD series card, you'll find pretty decent performance that often beats the closed driver.

Based on the progress I've seen over the last year, I would expect the performance for this new series of cards to be acceptable in a year or so for the simple fact that as they finish the code for older cards, much of the code base will help improve performance for newer ones.

http://www.x.org/wiki/RadeonFeature

Ah yes, the great myth of myths. The Open Source version with zero 3D acceleration, OpenCL support and much more are great! The proprietary version with all support SUCK! This is getting very old.

The closed drivers have serious quality issues with major regressions seemingly every other release.

The open drivers are making great strides, but the performance isn't there yet for newer cards. If you are using a pre-HD series card, you'll find pretty decent performance that often beats the closed driver.

Based on the progress I've seen over the last year, I would expect the performance for this new series of cards to be acceptable in a year or so for the simple fact that as they finish the code for older cards, much of the code base will help improve performance for newer ones.

http://www.x.org/wiki/RadeonFeature

Before anyone jumps on the band wagon and says that we all have perfectly usable user space desktop apps for 28 years in the UNIX world, let me say that it is actually very important that now even Microsoft starts to understand that modularity is the way to go while designing complex systems. Moving various operating system components to the user space is just a logical conclusion of the research done during the last four decades. Look at the direction of modern OSii development, from MINIX to GNU. Started by GNOSIS, KeyKOS, EROS and Coyotos this trend seems to suggest that it is much more natural and reliable to design a secure capability-based system when all of the services are separated from each other. Now when even Microsoft is going in that direction - and it is not a trivial change for them, trust me - we can expect Apple and other OS vendors to follow which is a Good Thing. After all, even if people like you and me are using secure operating systems we still don't want to get spammed and dossed by all of the legacy machines out there. It turns out that the rumors that Microsoft is starting to take the latest research in operating systems seriously turned out to be true. This is good news for everyone.

It's all command-line anyway; how much resolution do you really need?

You never heard of Xorg, Freedesktop, or KDE?

X11 is a protocol, X.Org is an implementation of it. The protocol specfication is here: http://www.x.org/releases/X11R7.5/doc/x11proto/proto.html As you can see, the protocol is pretty bloat for something that is mostly just managing your display buffer these days. The protcol commands for drawing arcs were all the rage in the 80's but are not at all used these days. Then there are all the extensions such as SHM, Composite, xrandr, XAA and probably a dozen more. All these specifications that has to be implemented creates a very bloated piece of software with lots of features almost noone ever uses.

You can get information on the status of the open radeon driver here: http://www.x.org/wiki/RadeonFeature