From owner-freebsd-multimedia Sat Feb 6 17:28:43 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA18250 for freebsd-multimedia-outgoing; Sat, 6 Feb 1999 17:28:43 -0800 (PST) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from pagesz.net (nina.pagesz.net [208.194.157.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18228 for ; Sat, 6 Feb 1999 17:28:28 -0800 (PST) (envelope-from rhh@pagesz.net) Received: from stealth.dummynet. (juana-7.pagesz.net [208.213.126.7]) by pagesz.net (8.8.7/8.8.7) with ESMTP id UAA00816; Sat, 6 Feb 1999 20:28:25 -0500 Received: (from rhh@localhost) by stealth.dummynet. (8.9.1/8.8.8) id UAA29204; Sat, 6 Feb 1999 20:29:02 -0500 (EST) (envelope-from rhh) Date: Sat, 6 Feb 1999 20:29:01 -0500 From: Randall Hopper To: Luigi Rizzo Cc: Roger Hardiman , multimedia@FreeBSD.ORG Subject: Re: fxtv Message-ID: <19990206202901.A21811@pagesz.net> References: <19990116174134.A2712@pagesz.net> <199901170730.IAA03371@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901170730.IAA03371@labinfo.iet.unipi.it>; from Luigi Rizzo on Sun, Jan 17, 1999 at 08:30:01AM +0100 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo: |Randall Hopper: |> That again leads me back to your idea of "reporting the problem" to the |> application. It'd sure be nice to be able to tell the user in plain |> English (or Italian :-) why frames captures are failing. Sure beats |> getting them to turn on driver debugs and deciphering streams of "a058a018 |> 10a38c8b" register dumps. |> |> Anyone with some time on their hands? :-) | |i can do the commit (it is really a few lines), but i have no idea how |to report errors -- just haven't thought on a suitable mechanism; since |you have an application, perhaps you can suggest a mechanism (e.g. |one ioctl that reports the last error and number of errors since |the last call ?) I've been passively thinking about this. (To recap for others: the issue is TV users with the problem that no frames are being captured wondering "why?" --and the application having no more clue than they do.) It seems to me that the application needs to be able to specify a timeout (maximum delay) for a frame capture. This would apply to both single-frame capture requests as well as continuous captures. If the timeout is exceeded, the app must be signaled. The driver can continue to retry a single-frame capture on failure (as it does now IIRC) ...until the timeout expires, but once it does, the driver throws up its hands and signals the application: "sorry, capture failed". A signal (wakeup) seems to make the most sense. For continuous capture, this is a natural since it doesn't otherwise issue signals. You got a signal? It failed. However, for single-frame captures, a signal currently means a frame was captured successfully. So we could either: 1) Have the driver issue a different signal (BT848_SFAILSIGNAL?) for both single- and continuous- captures if a capture fails -- i.e. the timeout is exceeded during a capture. 2) Alternatively, we could continue to use the same signal, and for single-capture mode, require the application to query the driver (via a new API) to find out whether the signal was issued because a frame was captured successfully or failed (timed out). Whichever we decide, the application will then know when something failed. For keeping track of errors so the app can query this and tell the user what is going on, we might just consider using a cheap ring-buffer of encountered errors. New errors get inserted into head, with the head increment bumping the tail up if necessary to guarentee the latest errors are in the buffer. A "get error queue" ioctl() could pop all the entries on this list, and reset tail = head. Just keep 128-256 errors or something a cheap query like BT848_REEPROM. Any thoughts? Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message