From owner-freebsd-multimedia Sat Oct 11 15:19:34 1997 Return-Path: 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 ; 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 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