I've been running a kernel absent of the cobalt lcd driver on a devel version of raqcop and running LCDproc instead. For those who don't know, the Hitachi HD44780 and compatible lcd and keypad chip is the most common one out there and the one in the Cobalts is an HD44780 compatible Samsung KS0066U chip connected via parallel with what is referred to as winamp wiring and the port address is 0x378 and the display is a common 16x2 with each block having 5x8 dots. I compiled lcdproc with the hd44780 driver and also with the enable menus options. I have had mostly good luck with it but sometimes after a while the screen starts spitting out nonsensical characters instead of numbers and letters. Usually restarting takes care of this. I tried different character maps but the default one holds up as good as any and is the most complete. We can tweak any timing issues and fine tune it at this point. A good example is that right now I have been running lcdproc for four hours with no hiccups. The menus still need to be mapped and actually created but to get the reboot and halt functionality, we will probably need lcdexec to also run as a client. LCDproc consists of two parts, the daemon itself or server as it really is and the lcdproc client as the most common. There are many clients for lcdproc and the build gives us lcdproc and lcdexec plus a few others. When things got garbled, I was restarting the daemon and the lcdproc client and making adjustments to the daemon configs. The solution may be on the client end, lcdproc itself, perhaps reloading occasionally or having it clear the screen.
Why am I looking outside of the Cobalt lcd driver and the horrific number of perl scripts needed to even have a prayer of getting some menu action? I think I just explained why. It is dependency hell with perl and related programs. LCDproc has the daemon binary and config file, lcdproc client binary and config file, one driver in userspace, NOT the kernel, and any startup scripts you may want. Each additional client has usually only two files, the binary and the config. By default, they all go in /usr/local which is not very crowded on ipcop. I tried LCD4Linux as well and even got it to start but it did weird things on the display. I even tried a null driver and tried to use the program to bind to /dev/lcd and the cobalt lcd driver but it stayed in twiddle land. The twiddle is the sweeping bar on the 2nd row while booting up. If this is absent and you just have the Cobalt and logo, it means that you are not using a kernel driver. Of course when it is present, it is an embedded driver that can only be skipped by giving the kernel command arguments which can be done in the rom menu of a nullmodem terminal. I can build with or without the embedded lcd driver with ease and you can easily exchange the vmlinux.bz2 and accompanying system.map in the /boot directory by sftp and reboot, no need to even change /lib/modules/2.4.x.
It looks like LCDproc is the most feasible and I pulled the cvs version and the latest hd44780 driver is indeed getting better. It is fun to watch the CPU histogram on the lcd while I am compiling on my devel machine.
The idea of LCDProc on a Cobalt is not new at all.
http://lists.omnipotent.net/pipermail/lcdproc/2003-February/007340.html
