added vfork capability to insight-serv

but the software still uses the frontend to do everything.  The software
captures two cameras, but only sends one (three times).  This is pretty
stupid lol.
renamed trip... to tripledisplayfromwebsock, pt 1

the new name gives a better impression of the temporary nature of the
utility (which will definitely be merged into a 'displayandsave' binary
soon)
renamed trip... to tripledisplayfromwebsock, pt 2

actually changed the Makefile and .gitignore
added support for 2 cameras to triple...

now it supports either 2 or 3 cameras (adding support for just 1 would
be easy enough, but I haven't).  also updated makeall.sh with the new
name
removed a bunch of old code from tripledisplay...

including ALL normalization code.  this will almost certainly become the
new "displayandsave" binary as it is MUCH simpler than the old binary.
a new "pipe through" binary can be created to do normalization
does two seperate cameras now

but for some reason, it's not working.  it does NOT.  it appears to be a
problem with the linux code, however.
removed more dead code

the "scaleduploc" IplImage pointers have been removed.
frontend and backend now share global data!

data is on the heap and the front end passes the base address to the
backend as a parameter.  all global data must be accessed through
pointers.  this file has lots of debugging data when the program starts
up
removed most debug output from insight-serv
added fix to adc081s101 driver (init code)

added a fix to the ADC081S101 driver which puts the module into a
sensible state upon startup.  it's unclear why this worked before (!)
updated libero project to run APB at 40MHz

double the speed of previously (20MHz).  The clock subsystem still runs
at 20MHz (including most of the stonyman logic in stonyman.v)
added the start of my stonyman driver LKM code
updated dasblinkenlights to take GPIO# as argument

also, the default GPIO # is now 7 instead of 0.
updated the load and unload scripts for multi-cam
reverted insight-serv.c to before vfork code

reverted insight-serv.c to commit 64bc4d7.  This code does not have a
frontend and backend (no vfork).  Now, the "backend" (producer) is a
loadable kernel module.
added read in LKM and insight-serv uses LKM

added the read function in the stonyman driver LKM (stonyman.h/c).
insight-serv now uses ioctl to start capture and reads from the device
file (/dev/stonymanX).

THERE IS NO CONCURRENCY PROTECTION.  The LKM will almost certainly find
an inconsistent state after a short time running this.

Also, unfortunately, I've changed insight-serv.c to stream data in a
"comet" like format, meaning that there is no way to close the socket
connection and data just streams forever!
added spinlocks to the stonyman driver LKM

spinlocks were added in stonyman.c to protect some of the shared image
buffer metadata (shared between stonyman_read and stonyman_interrupt).
the code is still pretty inefficient and only supports one camera.
removed 2 useless debug msgs from insight-serv
added seperate irq for capture finish

updated libero project as well as the stonyman driver LKM to support
this change.  also fixed a bug in stonyman.v wherein the bit twiddling
times were too long (due to wrong constants being used).
added a simple uclinux LKM to probe GPIO IRQ(s)

the prober app actually expects that the GPIO line is tied to the AFULL
line of a camera's pixel FIFO.  Therefore, in order to trigger the
interrupt, the prober starts a camera capture.  The IRQ number is
printed out by printk after the probe is complete.