Date: Sat, 6 Feb 1999 20:29:01 -0500 From: Randall Hopper <aa8vb@pagesz.net> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: Roger Hardiman <roger@cs.strath.ac.uk>, multimedia@FreeBSD.ORG Subject: Re: fxtv Message-ID: <19990206202901.A21811@pagesz.net> In-Reply-To: <199901170730.IAA03371@labinfo.iet.unipi.it>; from Luigi Rizzo on Sun, Jan 17, 1999 at 08:30:01AM %2B0100 References: <19990116174134.A2712@pagesz.net> <199901170730.IAA03371@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990206202901.A21811>