OSNews

Yeah. IIRC, that was one of the reasons they forked the code to begin with. I guess it was harder to maintain than they bargained for.

Xfree was virtually stagnant, thats why the fork happened. Xorg is not standing still, since every release is now including significant improvements. Thats the difference from the Xfree days.

That's been a project management issue for 7.5, I gather - my impression is that nobody really took charge of making that release happen. They've since made a bunch of changes to their release process, with the aim of making future releases a bit more predictable...

It has only been 13 months since 7.4. This is X after all.

Don't know what distro you are on about, but the newer X releases have been a breeze to compile by hand, with the modular build system.

You are not obliged to install the latest release. You can wait for a point release if you think it's going to break anything.

Doesn't mean anything if it's a point release or not when it comes to Linux. A good majority of the issues with new versions of X.org screwing up installs relate to packaging issues by the Linux vendors, not X.org itself. 7.5 may work like a breeze but 7.5.1 may break everything if the packagers are careless, I've seen this happen more than once with X, the kernel, and GNOME just to name a few. That's a big reason you don't update immediately or use a rolling release system in a production setting, you just don't know what bugs the distro-specific patches and packaging has created or unearthed in the code.

Doesn't mean anything if it's a point release or not when it comes to Linux. A good majority of the issues with new versions of X.org screwing up installs relate to packaging issues by the Linux vendors, not X.org itself. 7.5 may work like a breeze but 7.5.1 may break everything if the packagers are careless, I've seen this happen more than once with X, the kernel, and GNOME just to name a few. That's a big reason you don't update immediately or use a rolling release system in a production setting, you just don't know what bugs the distro-specific patches and packaging has created or unearthed in the code. "

To be fair, that's true of other platforms too. I was under the impression that it's a good rule of thumb in general to never be a first-adopter when reliability is important. I think our internal IT department stages and tests Windows patches too, for exactly that reason. So, that's not really an X-specific gripe, but it's true of software in general.

And the original point still stands: no-one's standing behind you with a gun to your head, demanding that you install the new X server.

I am not sure what your setup is specifically, but xrandr has worked pretty well for a while. Either use the command line program xrandr or your desktop environment's control panel for displays. The article mentions new features in the latest release for fancier transforms than just rotations and flips.

I have a dual landscape-portrait monitor setup, both nvidia and ati accelerated drivers refuse to work with xrandr.

I would not mind trading compiz glitz for proper multidisplay behavior. Ever since the days of xinerama it has been a mess in x.org (nee xfree) land...

You may be in for a surprise as the ATI drivers are improving a great deal, both the open and proprietary.

I am finding the ATI drivers really stable and fast in this new release.

Actually, the ATI proprietary drivers now support xrandr and the open source drivers are quite good, 3d performance could still improve, but other than that the do pretty good.

... So what do you want from Xorg?
Once you use binary drivers, for better or worse, you accept the if vendor A doesn't want to support feature X, you're screwed. *

- Gilboa
* I'm using the nVidia binary drivers on a number of machines. Never-the-less I don't blame Xorg for my own hardware purchasing decisions...

On the other hand, once you use FOSS drivers, you accept that if the project doesn't want to support a feature, or moans that they need more devs, you're screwed. Well... unless you happen to be competent to add the feature yourself. And are in the position to devote the substantial amount of time that it would require. And then get your patches cleaned up and accepted by the project... assuming you don't want to maintain your own fork forever.

But then again, if you need a feature not supported by your driver, isn't it easier to get a different card than to do all that... regardless of whether the driver is open or closed source? Balanced against the cost of a new card, how much do you want to work for? 50 cents an hour?

And if you absolutely have to have all hardware features supported, you're best off running Windows, as a general rule.

There are many good reasons for running FOSS drivers. But I've always found the whole "at the mercy of" argument to be a bit contrived. In general, I've found proprietary drivers to be more feature complete than the FOSS ones.

Edited 2009-10-28 19:34 UTC

I never intended to open the open vs. close drivers argument.

Unless I misunderstood something - the OP blamed Xorg for a feature missing from nVidia's binary drivers. He should have pointed the finger @nVidia. It's that simple.

- Gilboa

Fair enough.



In my lesser experience, the closed/binary drivers usually have better 3D accelaration... and next-to-nothing else. Things like xrandr are usually better supported or only supported in the open drivers. I think that's the case with kernel-based mode setting even now: if either nVidia or ATI's binary drivers support Kernel mode-setting, it's news to me.

Now, whose fault that is is a completely separate question.

Only if there is no new version of Windows since the card became obsolete. If a new version of Windows requires a new driver, then the OEM sometimes won't bother to write a new driver for cards they no longer sell.



The proprietary drivers for Linux often aren't in any way feature complete.

For example, video card manufacturers will often have a Linux binary driver that: has abysmal 2D hardware acceleration performance; doesn't support R&R; often has trouble resuming from suspend; and doesn't support the use by Linux of video decoder features.

The lack of support for using the cards video decoders and acceleration is interesting, because the owner of the card in the Linux machine has presumably paid for any royalties associated with the video codecs via having paid for the card itself. By not supporting such features in their Linux binary drivers, considering that a user of their card who is running Linux has paid for the card and therefore its features, the video card OEM could presumably be sued for failing to deliver a fully working product.

This is especially interesting when you consider that for years Linux kernel developers have been begging for programmining information (specifications) so that they could write hardware drivers for Linux and thereby relieve the OEMs of the need to do it themselves.

http://kerneltrap.org/Linux/Linux_Driver_Project
http://www.desktoplinux.com/news/NS6669895837.html
http://www.linuxdriverproject.org/twiki/bin/view

Edited 2009-11-01 22:51 UTC

NVidia drivers don't support XRANDR. Well, it supports a subset of XRANDR 1.1, but not the rotatey stuff you want. You'll recall that 90% of the driver code is shared with Windows, and XRANDR support would conflict with their TwinView feature. Blame the driver vendor, not the server.

I might be wrong but I have the impression that even the Linux drivers do support screen rotation, but you have to specify the options in xorg.conf file, and those options are specific to Nvidia drivers. I have no idea why they don't just support XRANDR properly.