Date: Tue, 18 Mar 1997 16:31:53 -0500 From: Randall Hopper <rhh@ct.picker.com> To: Steve Passe <smp@csn.net> Cc: multimedia@freebsd.org Subject: Re: latest bt848 code Message-ID: <19970318163153.31441@ct.picker.com> In-Reply-To: <199703182125.OAA18595@Ilsa.StevesCafe.com>; from Steve Passe on Tue, Mar 18, 1997 at 02:25:29PM -0700 References: <19970318140646.02069@ct.picker.com> <199703182125.OAA18595@Ilsa.StevesCafe.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Passe: |I have identified the basic problem as being that fxtv closes the device |and then re-opens it every time the window is moved!. If you happen |to have it open with another client (such as xtvr) at the time you move |the window nothing bad happens, as the open routine ends early. But if |no other clients are active the close completes, and the open reinitializes |the hardware. this is where all the tuner values are lost. so the question |why the close/open calls for every re-draw? (i merely put printf()s in the |driver in both open and close to show this behaviour, am about to go look at |the fxtv source) Back before the driver-hang bug-fix, I close/open-cycled the driver for each capture stop to try and reduce the frequency of the lock-ups. It seemed like it helped some. However, I ripped that hack out last weekend when the bug was fixed so the last-close-cleanup behavior you describe won't kick-in anymore. I'll do some tests later to verify that brightness/contrast/etc. do in fact keep their values across stops/starts when the driver handle is held open. Thanks for looking into it. Randy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970318163153.31441>