Five months ago according to
http://www.x.org/docs/AMD/
Just as the r5xx accel documentation applies to r3xx/r4xx for the most part, the r6xx/r7xx acceleration documentation still applies to evergreen as the 3D state registers did not change significantly as you can see:
http://cgit.freedesktop.org/xorg/dri...een_reg_auto.h
http://cgit.freedesktop.org/xorg/dri...eg_auto_r6xx.h
What did change were the shaders, which are well documented here:
http://developer.amd.com/documentati...s/default.aspx
Unfortunately, we haven't had time to review and release register specs for the DCE4 display blocks yet. DCE1 (r5xx) and DCE2 (early r6xx/rs690/rs740) are available here:
http://developer.amd.com/documentati...s/default.aspx
and here:
http://www.x.org/docs/AMD/
and most of DCE3 (later r6xx/rs780/rs880, r7xx) is in the rs780 docs here:
http://developer.amd.com/documentati...s/default.aspx
At this point atombios is fairly well documented by the various parsers and utilities that have been released.
The nvidia driver already does KMS (mode setting in the kernel). What it doesn't have is a framebuffer console driver, so it can't do the seamless switching thing that everyone seems to think 'KMS' means. Also, as I understood it, doesn't wayland rely on EGL rather than KMS/GEM specifically? Shouldn't nvidia supporting GL outside of X be enough?
Essentially, my point is that if we're going to ask the developers at nvidia to support things, we ought to ask for the actual things we want (EGL/fbdev etc) not implementation details from the open source drivers (KMS/GEM/TTM/DRI/mesa/gallium etc) which they will reject immediately, for obvious reasons.
See: http://www.nvnews.net/vbulletin/showthread.php?t=129253 especially post 5