Re: Success/failure?

On Tue, 2 Jan 1996, Scott Laird wrote:

> In message <Pine.LNX.3.91.960102125912.136H-100000@hamjudo.hamjudo.com>, Paul H
> aas writes:
> >On Tue, 2 Jan 1996, Scott Laird wrote:
> > 1) The first 6 pixels on the first scan line are usually very wrong.  The
> >first 6 pixels on following scan lines are sometimes a little light.
> There's something odd with the first 8 pixels on each line for me --

You're right, 8 pixels are corrupted.  Pixels 7 and 8 weren't as far off 
as 1 through 6.  
> > 2) At 80x60 6 bpp, every 4th pixel is darker than its neighbors.  Other 
> >resolutions are fine, likewise 4bpp is fine.
> I haven't noticed this, but I might have just not noticed.  It the
> effect very pronounced? 

It depends on the image.  I can make them stand out by making pictures of a
plain sheet of paper with the camera adjusted to get a mostly gray image. 

> There are a number of timing issues, and I
> don't have a very good feel for when I need to put delays in the
> system.  I guess I'll try adding a 100us pause before every I/O access
> and see if it fixes anything.

The picture went mostly white for me when I tried it.  There was a bit of
picture left at the top of the image, but not enough to see if the problem
was still there.  My usleep(100) seems to sleep for 10 milliseconds. It may
be due to my old kernel.  An 80x60x4Bpp image took about 100 seconds.  I
added 2 usleep(100) per pixel, 4800 pixels.  I think the image is stored in
the CCD until read.  The CCD doesn't remember forever.  Try it on your 
system with a presumably better resolution timer.

> Hmm, try something like this (untested).  You might be better off with
> a cron job taking pictures instead of a picture-on-demand system.

Well I want to give the users the ability to move stuff in the field of 
view of the camera, so they should get instant gratification.  Or at 
least as instant as my ISDN line will allow.

I think I will write a qcam server process that gets started at boot time and
can run as root (no SUID needed this way).  The single process will prevent
simultaneous access to the camera hardware.  I've crudely modified your
program to use shared memory.