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.94user 0.02system 0:00.96elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
> 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
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 A. Laird | "But this goes to 18,446,744,073,709,551,615"
firstname.lastname@example.org | - Nigel on his new 64-bit computer