In the mailing list discussion that followed, it looked like Linus' request wouldn't be immediately acted upon due to legal issues with Nouveau surrounding some unknown microcode/firmware that is a critical part of the initialization process for newer graphics cards. However, this microcode ended up being pulled out of the driver itself and now relies upon it being loaded as firmware, which ended up in a Nouveau pull request just a day later. Now NVIDIA customers of the Linux 2.6.33 kernel and later can benefit from the mainline DRM with kernel mode-setting and when using the yet-to-be-released xf86-video-nouveau DDX driver and eventually its Gallium3D driver for providing 3D support.
This essentially spells the end of the xf86-video-nv driver, which was never good and should have died off long ago. Something is likely to happen to this driver in 2010 once Nouveau reaches a prime state on the Linux desktop. There's a few possibilities that we discussed in the aforementioned posting, but we sought comments from NVIDIA regarding this recent Nouveau work and what their plans are going forward. Below is Andy Ritger's response, who leads NVIDIA's Unix graphics team.
As of right now, our plan remains the same: neither help nor hinder nouveau, provide basic modesetting and 2D acceleration support in the nv driver, and invest the majority of our engineering effort in the NVIDIA proprietary driver.
This really isn't any different from when we interviewed Andy Ritger in October. "With the nv driver, we've always tried to provide something minimal that just works out of the box and requires the least maintenance. For that reason, feature set in the nv driver has stayed pretty slim. The guys working on nouveau have done a really incredible job so far. However, our policy remains the same: we won't try to hinder their efforts, but we have no plans to help them."
Of course, Andy just mentions this is what their plans are "right now", but we will see if and how it evolves. At least they are not looking to hinder any Nouveau efforts through the ctx_voodoo microcode uncertainty at this point.