Arch Linux

KMS is enabled without any options in menu.lst. It just needs to be enabled in config of kernel26.

To disable it, add 'nomodeset' in menu.lst, in kernel options.

It is harmeless.

PS.: With vga=xxx framebuffer, X has issues, if KMS is enabled. It should be removed.

libdrm should be be built with --enable-radeon-experimental-api.
I 'm sure that KMS works with mesa 7.6 (I don't know if it works with 7.5, I don't use it right now)
I'm sure that KMS works with xf86-video-ati 6.12.99 (I don't know if it works with 6.12.4).

Nevertheless, it would be nice to have it enabled, because if someone wants to try KMS, if it's not enabled in the stock arch kernel, he/she has to rebuild the whole kernel just for Radeon KMS.

It would be nice to have opportunity to enable KMS without recompiling the whole kernel.

A discussion is taking place in arch-dev-public mailing list, check this out: http://mailman.archlinux.org/pipermail/arch-dev-public/2009-September/013355.html

Ah, good discussion :). It sounds like there are plenty of ways to turn off KMS if it's in the config file but no way to turn it on if it isn't.

i need this too, i already use ATI KMS since kernel 2.6.29.

Having ATI KMS enabled by default is a bad idea, it's a even staging driver. We even have it disabled on intel by default, but there's at least a module option to enable it.

Until there is an option to enable it with it being disabled by default, this won't be enabled.

@Thomas: I don't think that there is a problem.

Assume that the kernel26 is built with Radeon KMS support.

For now, if someone with ATi card (R1xx to R5xx) + xf86-video-ati 6.12.x + Mesa 7.5 installs it and reboots, he has no KMS.
In order to have KMS enabled on boot, we need:

1)Libdrm built with --radeon-experimental-api --> or KMS won't be enabled on boot. This libdrm's code produced by the --enable-experimental-api option won't be enabled if KMS isn't enabled on boot.
2)xf86-video-ati 6.13 using no.(1) (coming soon)
3)mesa 7.6 (coming soon) --> that means ati-dri 7.6, libgl 7.6 etc

When 1,2 and 3 pass to extra, oops, we have KMS enabled on boot. It is stable, but we don't have powersaving controls yet.
To disable it (so --> no KMS on boot), we have to add "nomodeset" in kernel options in menu.lst.

If it is disabled, the stability of the system is the same as it was before, there is no issue (like Intel's driver, which needs care, with UXA)

KMS is enabled long before and ati or drm code is executed, namely when the kernel is booted.

That's what I mean as "on boot" ;)

It could even be started really early if "drm radeon" modules are included in the MODULES array in mkinitcpio.conf when we create a new initrd for the kernel.

More info: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/gpu/drm/radeon/Kconfig;h=2168d67f09a6ff0b047800c27e8ec7916063775c;hb=74fca6a42863ffacaf7ba6f1936a9f228950f657

Having this enabled by default is pain for anyone not running experimental code.

What do you mean by "pain" exactly ?

According to this message, their systems won't work anymore. That is unacceptable. The situation with intel is better: You have it disabled by default, and can enable it with an option.

I could actually create this situation for radeon with a simple kernel patch, but I don't know if I should.

What he says is that:

"...Choose this option if you want kernel modesetting enabled by default,
and you have a new enough userspace to support this. Running old
userspaces with this enabled will cause pain...."

Old userspaces ...? That means kernel older than .30 and old Mesa,libdrm,xf86-video-ati, old TTM code. Then, it could cause pain, because we hadn't KMS aware Mesa and xf86-video-ati. TTM code inside the kernel wasn't mature enough.

Question: do you have an R1xx to R5xx Ati card ? If you had, you'd know that there is no such issue. I've running with my R5xx card a .31 kernel built with KMS. I have it disabled, not just because there is any problem (except for lacking Radeon powersaving) but because I had to stick with Mesa 7.6/7.7, versions which aren't in [extra] yet.

An Nvidia or Intel user shouldn't be affected by Radeon KMS.

It's not a big issue. A kernel built this way though would allow any R1/2/3/4/5xx Radeon user to use KMS without having to recompile the whole kernel for that.

---------

An info on something you'd want to know:

ConnorBehan wrote this here:
http://aur.archlinux.org/packages.php?ID=24072

"...
Rawhide kernel:
CONFIG_DRM_RADEON_KMS=n means the module is built with kms support but modprobe radeon does not turn it on. You need modprobe radeon modeset=1 instead.
CONFIG_DRM_RADEON_KMS=y means the module is built with kms support, modprobe radeon turns it on and modprobe radeon modeset=0 turns it off.

Vanilla kernel 2.6.31:
CONFIG_DRM_RADEON_KMS=n means the module is not built with kms support at all and modeset isn't even an option.
CONFIG_DRM_RADEON_KMS=y means the module is build with kms support, modprobe radeon turns it on and modprobe radeon modeset=0 turns it off.
..."

But if you want to be really sure that everything is OK, I thought this: enable it after Mesa 7.6, xf86-video-ati 6.13 enter extra. So both sides (users and devs) are happier.

Yes I am quite sure that's how it is. What's wrong with packaging the kernel so that it's disabled by default but overridable with modeset=1? I would be very happy if you make such a kernel patch or ship the kernel with an /etc/modprobe.d/radeon.conf file.

Hey thanks for putting this in testing! I'm compiling the userspace now.