Re: QCAM 0.3 now available. NEW AND IMPROVED PAGE!
Scott Laird wrote:
> 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.
YESS!!!!!! now the web version runs MUCH quicker!
I've also made many improvements on my page check it out! You can now
get over 2 fps! (need at least 28.8k modem)
also - you now only need one URL -> http://fuz.triadtech.com/cgi-bin/cam.pl
> 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?
These are the best numbers out of about 15 tries each.
> 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 :-).
thats okay.. I wasn't being critical - just observant :)
I only notice it when I'm pushing frames with my server - so you're
right it's not that big of a deal :)
> > > 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).
That make sense - no need to disrupt other devices. :;)
> 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
Georgia Institute of Technology, Atlanta Georgia, 30332