After making patches to the kernels to get the color support two time
and facing the prospect of doing it again I packaged colorkit code
into LKM. So, now it should work with almost any kernel as long as the
interfaces do not change much. There are no new patches to the kernel,
all patching is done at a run time. The code is in 

ctpa01:/pub/ivanenko/macbsd/video_lkm.tar.gz

I also put precompiled object video_lkm_combined.o in the same
directory (compiled with Feb.8 headers) I do not use the new fancy
configuration files, I load the module in rc.local Look at the load
target in Makefile and modify your /etc/rc.local accordingly. If you
have the new init files, put appropriate entry into /etc/lkm.conf

There is no new functionality in the code, so if the previous versions
of colorkit code did not work for you it is highly unlikely that the
LKM version will. On the other hand, if you have the kernel customized
in other parts, you have no new patches to apply. It should be
easier to add more functionality to the module then to the kernel.

Here are some technical details:
The are 4 source files:
video_lkm.c --- load/unload calls and general setup
video_lkm_misc.c --- and
video_lkm_asm.s  --- Additions to the system required by the driver
video_lkm_module.c --- The driver code itself.

video_lkm.h --- All definitions not related to graphics driver
grfioctl_extra.h --- all graphics definitions

So, 
video_lkm_misc.c and partially video_lkm.c correspond to all old 
  patches to nubus.c and macrom.c
video_lkm_asm.s is a patch to macromasm.s
video_lkm_module.c is combined from the patches to grf.c and grf_mv.c
grfioctl_extra.h is an addition to grfioctl.h

Here is how it works:

When the module is about to be loaded all kernel initialization
finished so I rely on grf_cd list to extract the information about the
devices. First, I load new traps and few low memory variables, then 
search grf_cd device list and load the driver. I replace the ioctl()
and driver functions with my own and get the equivalent of colorkit
grf driver. 

However, there are few sticky points:
1) There is no place in grf_softc structure to save the pointer to the
new data. I had to build the parallel list in memory just for the
driver (DCE).
2) Nubus adress space is not mapped into its own place 0xF9000000, I
had to do it myself.
3) I am trying to guess which grf driver corresponds to console (ite),
I am not sure if that code is correct. I have to call itecninit() to
reset ite driver after changing the mode, unfortunately this function
have (mostly harmless) side effects.

There is no way to unload the driver once it it there although I put
in some code to do this. In addition to the bugs in the ROM driver
iteself, there is no way to make sure that the driver leave the card
in a usable state after close.

I thought about making the completely new device (in one of LKM
slots) or adding another grf device but decided against it. I could
not find a way to instruct X server to use something else then grf0,
so I modified grf0.

Sorry, the source is not in the Kernel Normal Form (yet).

Enjoy,

	Taras.