[Prev][Next][Index][Thread]

Re: QCAM 0.3 now available.

> Scott Laird wrote:
> > I'm about to place the next version of qcam on my ftp site 
> > (ftp://ftp.nas.com/laird/qcam-0.3.tar.gz).  This is mostly a clean-up 
> > release, with a lot of small bugs fixed and a lot of small changes to 
> > the library code.
> > 
> 	I was having a major performance hit with 0.3 - I finally realized
>   that it was probing ports first.  -p 0x378 makes it faster now.

Hmm, if you look in the code, the check for -p on the command line is 
disabled if anyone other than root tries to use it.  I don't like the 
idea of random users sending random values to I/O ports.

The right way to set the port is via the qcam.conf file, which is 
currently installed in /usr/local/etc.  If you look at the sample 
included with 0.3 you should see all of the options.  This is the easy 
way to change the default brightness and everything.

>   But 0.3 still runs a bit slower than 0.2.  
>   Here are the best results of .2 and .3
> 
> 0.2:
> 0.94user 0.02system 0:00.96elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
> 
> 0.3:
> 1.00user 0.01system 0:01.01elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
> 

These differences are fairly minor.  How repeatable are they?

There were a lot of minor changes made between 0.2 and 0.3.  There's 
one extra call to qc_reset that should take ~10 ms, and a few code 
changes that might account for some of the rest.  I wouldn't be 
suprised if the changes to the qcam.conf file account for a bit of the 
difference -- I added a bunch of comments and that may have slowed 
startup by a few milliseconds. 

By and large, I don't think the amount of time the program takes to 
start is a big thing.  If you're running qcam, you're probably either 
experimenting (when a couple of ms won't be noticable) or running a web 
page (when it still won't matter).  Performance doesn't get really 
important until you start running something like xqcam, where you're 
trying to do 20 fps, and adding 10ms to each scan loses big.  

Not that I want to write (or support) slow code.  I just think there 
are more important things to deal with right now.  You're free to 
disagree.  I'm more accepting of other people's opinions when they 
include a patch with them :-).

> > Also, the beginnings of bidirectional support are in place.  Read the 
> > readme (or qcam-lib.c) for more details.
> > 
> 	Also, I've set my port to both EPP and ECP.  I've noticed that
>   0.3 sometimes hangs and says:
> 
> <fuz><root></usr/local/qcam-0.3> qcam-simple -p 0x378 -x 3
> 20 -y 240 -B 6 > /dev/null
> Qcam not found
> Can't get I/O permission: I/O error
> Command had non-zero exit status 1
> 

Like I said, the -p switch is ignored if anyone other than root uses 
it.  What seems to be happening is the autoprobe missed the camera for 
some reason (more later), and the program aborted.  I don't like the 
error message -- I need to take a closer look at the code for that.

My autoprobe code works by listening to each parallel port in turn, 
waiting to find the "warble" produced by an idle QuickCam.  This isn't 
the way Connectix's software seemd to find it -- they send a reset to 
the camera and wait to see if it responds like a QuickCam.  Anyone 
who's tried putting a QuickCam on LPT2 when they have a printer on LPT1 
should understand the problem with this.  It drives my poor Deskjet 
nuts.  I've tried to use a non-destructive probe routine, and it 
usually works, but it will fail from time to time.

Ideally, people will use the autoprobe to find their QuickCam and then 
edit their qcam.conf file to hold the right value.  If qcam reports 
"QuickCam detected at 0x..." then it's using the autoprobe code, not a 
hard-wired address, and you should edit your config file.  I really 
don't like the idea of using a destructive probe routine, as it seems 
to screw up too many things (i.e. my printer).

> <fuz><root></usr/local/qcam-0.3> probeqcam
> QuickCam not found on 0x378
> QuickCam not found on 0x278
> QuickCam not found on 0x3bc
> 
> weird... next time I reboot, I'll try turning off EPP and ECP - maybe thats
> the problem...
> 

If the software gets interrupted for some reason the camera may get 
left in the middle of a scan.  The autoprobe code can't find the camera 
when it's in this state, because it's not "warbling" like it normally 
does.  It doesn't really matter under normal circumstances, because the 
first thing the program does is reset the camera, but it kills the 
autoprobe code.

Of course, it's possible I've missed something here.  When "probeqcam" 
stops working, try running qcam (with a fixed port address) and then 
run probecam again and see if it works.


Scott
-- 
Scott A. Laird   |  "But this goes to 18,446,744,073,709,551,615"
scott@laird.com  |                - Nigel on his new 64-bit computer
Follow-Ups: References: