I don't really understand the question about KMS being a work in progress. What I said was that the acceleration code only includes code paths for KMS.KMS is work in progress?
Having the ability to disable KMS and fall back to UMS is handy if a problem with KMS is discovered on a specific system, but the developers would much rather spend their time dealing with KMS issues than duplicating effort to maintain UMS code paths with DRI1 and memory management in the userspace code rather than kernel. When KMS was first launched it only worked on a small set of systems (like all new things) but a year later it is the default for most new distro releases and problems are becoming relatively rare.There's a lot of discussion and topics of disabling KMS for various reasons including getting a black screen on bootup.
KMS should be almost completely independent of kernel changes AFAIK -- it's really the memory management and the code that was already in the kernel which is most sensitive to kernel updates.If there's major revisions of the kernel, is KMS particularly effected?
We were talking about the open drivers, so that's fine -- at least I assumed you were talking about the open drivers because of the reference to hardware acceleration. The fglrx driver had hardware acceleration for Evergreen when the family was launched.I guess that's more open source driver related but for me, I'm wondering about ...