RAQCOP = IPCop + Cobalt Raq, Cobalt Raq Firewall Applicance Software, Velociraptor Software Upgrade.

I have been spending a lot of time getting to know exactly how the display is set up and as we have gathered, it is really nothing out of the ordinary. Basically an HD44780 compatible display with the winamp wiring scheme as it were using only 14 pins out of 16 possible on parallel LCD displays. Usually, 15 and 16 are for the backlight but they can be configured to get power and ground from pin 1 and 2 with 100 ohms worth of resistance typically recommended and the stock Gen III LCD uses this scheme. The actual display is a Goldentek GC-162F1-YSL1A which has little info available on it except it uses the Samsung KS0066U chip in it plus a display driver companion chip. The actual character map is unknown at this time as these displays often have extra characters, Kanji or something else. BTW, most if not all displays are parallel, if they are usb, serial or i2c, they usually do that with a converter board attached to the parallel display. Most any of them could be used by removing the extra board.

I had been playing with LCDProc and the display sometimes would spit out garbled text. LCD4Linux has a lot steeper learning curve and as of yet I hadn't configured it right for this but it did load the display. I think I was trying to load graphic widgets to a character display which is a no no. The third non Cobalt LCD driver method used in my tests is a simple Perl program that members of the French ipcop users forums have come up with years ago and needs no external driver at all. It works but uses at least 5% cpu cycles constantly. It also needs to be tweaked for a 16x2 display to be really useful. Franck who is also one of the IPCop devel team explained that the LCDProc driver sends the two bytes that make a command too quickly and we know these types of displays are not that fast. I cannot dispute that but I also think a character mapping issue may be part of if not THE problem as lcdproc uses char maps in the HD44780 driver and when the server starts, instead of 16x2 and the 0x378 port showing up in the text which is the lpt port the Gen III raqs use, it reads 06x2 and 0x278. When the lcdproc client starts, it sometimes overcomes it and starts showing good useable text through the screens. There must be a mismapped character in the 256 character table that when the right conditions are present, throws it out of whack. This is but one theory. Now on to VFD.

I picked up a Matrix Orbital 16x2 Parallel VFD display which is really a Noritake VFD and since the thing only uses 150ma, they only use 14 pins ever. I soldered in a 14 pin header and plugged it into to raq panel board. I decided to see how LCDProc would handle this, when the LCDProc server started, I still got the bogus 06x2 and 0x278 but when the lcdproc client started, it cleared up and has not garbled on me yet and I have been running it for four days. Is this because the VFD displays are much faster and less timing sensitive or is it because the VFD's have some differences in available characters. The usual upper and lower case letters and numbers 0 through 9 as well as western symbols such as ! # % and so forth on this device are mapped in the same place as the standard HD44780 char map. Now I need to get some acrylic lenses to make the VFD the color I want, basically Rose will filter it to show as white text but it is also possible to use neutral as many home theaters use which leaves the aqua color or lunar white as the industry calls it or you can make it show green, blue or yellow with the right color filters. The naked display with no filter is extremely bright so I put a tinted film on it so it doesn't fry my retina. If I take a piece of pink poly antistatic and put in front, the text turns white. I like the white text for mine so now I need real acrylic rose colored material.

I also have an OLED (Sometimes referred to as PLED or Polymer displays) green display coming. These are also many times faster than the character lcd displays and like the VFD, use the same 14 pins as the raqs are equipped for and like the VFD are self illuminating and need no backlight like LCD displays do. These types of displays are what is called large molecule displays which are usually just alphanumeric character displays and not graphical and the reason they are usually green or red is that green and red OLED material has a much longer life than blue organic material but blue is getting better. My Norelco Spectra shaver has one of these displays and pictures do not show how sharp the dots really are. The main problem for us 16x2 character display users is that many manufacturers of these large molecule mono color displays are discontinuing work with this. Sure Electronics seems to be one of the few that still sells them and on ebay as well and they are about 20 bucks a piece. The big players that have survived and not gone belly up such as Sony, Osram and so forth have moved the r&d to actual multicolor graphical displays such as TV. They need to get the blue life up but as it is now, a set could last five years before it loses it's blue color. Barring the life issue, they would be superior to LCD as far as trueness of color, contrast and best of all, SPEED! This will also make it possible to have a large display that rolls up like a poster and maybe even a pda will be shaped like a pocket pen with a roll out screen. All nice but not important to raq lovers.

As far as the Cobalt kernel lcd driver and the panel utilities that people keep copying for the last six years is that they are needlessly complex and outdated for IPCop and are geared towards a web server, not a firewall. The showip I have with 1.4.18 is pretty static and boring. The menus alone have dozens of perl scripts and the lcd program binaries use several separate binaries for various functions. If need be, we need a looping script that displays rotating screens with vital info. What I do like about lcdproc is that to run just the server and the lcdroc client only, takes two binaries, one for the server and one for the client and a config file for each plus the driver for the lcd display. LCD4Linux uses one binary and one config file. All driver options and widgets are compiled in with compiling options. Both of these can be made to have a button menu as well. I do have the actual button ports written down when we get to that stage. I at least want to be able to reboot or shut down from the lcd as a minimum. Things like changing the ip and such I'm not so sure is a good idea on a firewall appliance.

In a nutshell, LCDProc seems to run ok with a VFD display right now as it is. More info is needed for the stock LCD and we do have a few options that DO work. My first goal of just getting IPCop to run and function well on these units was the easy part. Doing something really cool with the display has been proving to be a much longer learning process but we have a display and buttons so we should use them.