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

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
> -- 
> Scott A. Laird   |  "But this goes to 18,446,744,073,709,551,615"
> scott@laird.com  |                - Nigel on his new 64-bit computer
> 
	Thanks Scott!
  David
-- 
David Chow
Georgia Institute of Technology, Atlanta Georgia, 30332
Internet:gt9351c@prism.gatech.edu, chow@cc.gatech.edu
References: