Date: Sat, 16 Jan 1999 17:41:34 -0500 From: Randall Hopper <aa8vb@pagesz.net> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: duane@denton.com, multimedia@FreeBSD.ORG Subject: Re: fxtv Message-ID: <19990116174134.A2712@pagesz.net> In-Reply-To: <199901161830.TAA02503@labinfo.iet.unipi.it>; from Luigi Rizzo on Sat, Jan 16, 1999 at 07:30:53PM %2B0100 References: <19990116123615.B11467@pagesz.net> <199901161830.TAA02503@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo: |Randall, i experienced similar problems for a long time on all |systems i have with a bt848. The reason is something i strongly |believe to be a bug in the bt848 driver: | | when for any reason the DMA engine on the Bt848 experiences an | underrun, the interrupt handler in the bt848 driver notices the | problem and decides _not_ to invoke a wakeup() on the sleeping | process. | |If you have this problem you should notice because with full screen |captures you don't have one field and the channel numbers and other |msgs remain partly visible (on the lines corresponding to the missing |field). | |The reason i think this is broken behaviour of the driver is that the |interrupt handler should call wakeup() even in case of errors, just |report the problem to the application in case it bothers to check. That sounds reasonable to me. Then the application could decide whether it wanted to (for example) try N times for a good frame before accepting a dirty one, print an operation failed message, or just take the first frame that comes along. |DMA overruns are easy, especially when (as in my case) one is dumping |to the video RAM of some slow card. Makes sense. In Duane's case though, he's running a 66MHz mem bus and a VRAM video card; shouldn't be a problem AFAIK unless there's some other device on the bus stealing a lot of bandwidth. Alternatively, we may have a marginal signal. 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? :-) 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?19990116174134.A2712>