From owner-freebsd-multimedia  Sat Oct 11 15:19:34 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA14627
          for multimedia-outgoing; Sat, 11 Oct 1997 15:19:34 -0700 (PDT)
          (envelope-from owner-freebsd-multimedia)
Received: from red.juniper.net (red.juniper.net [208.197.169.254])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA14622
          for <multimedia@freebsd.org>; Sat, 11 Oct 1997 15:19:31 -0700 (PDT)
          (envelope-from pst@juniper.net)
Received: from base.juniper.net (base.juniper.net [208.197.169.208])
	by red.juniper.net (8.8.5/8.8.5) with ESMTP id PAA27795;
	Sat, 11 Oct 1997 15:19:00 -0700 (PDT)
Received: (from pst@localhost) by base.juniper.net (8.8.7/8.7.3) id PAA03889; Sat, 11 Oct 1997 15:18:59 -0700 (PDT)
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
cc: multimedia@freebsd.org
Subject: Re: quickcam performance...
References: <199710091519.QAA13337@labinfo.iet.unipi.it>
From: Paul Traina <pst@juniper.net>
Date: 11 Oct 1997 15:18:58 -0700
In-Reply-To: luigi@labinfo.iet.unipi.it's message of 9 Oct 97 15:19:31 GMT
Message-ID: <7yzpogndt9.fsf@base.juniper.net>
Lines: 27
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: owner-freebsd-multimedia@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

luigi@labinfo.iet.unipi.it (Luigi Rizzo) writes:

> 
> Hi,
> 
> I am trying to use vic with the quickcam on the parallel port using
> /dev/qcam, and performance is just horrible. I don't remember it so bad
> when using the user-space library on a much slower system, so there
> must be something wrong...
> 
> Is there any known performance problem with /dev/qcam , or some
> configuration problem on my side ? I think I am using basic
> (unidirectional) parallel port to access the camera, as I was with the
> user-space library... and I am running 2.2.1

The problem is that the qcam won't generate an interrupt defining when
a start of frame is available (the hardware just isn't there, the right
pin wasn't used on the damn parallel port).  Therefore the driver spins
in the kernel.  This sucks, and is why I abandoned further development on it.

I think the only sane approach to a kernel driver is to do a timer based
wakeup.  Unfortunately, I just don't have time to mess with the thing these
days.

Sorry,

Paul