From owner-freebsd-multimedia  Tue Mar 18 13:25:54 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id NAA29966
          for multimedia-outgoing; Tue, 18 Mar 1997 13:25:54 -0800 (PST)
Received: from Ilsa.StevesCafe.com (sc-gw.StevesCafe.com [205.168.119.191])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA29949
          for <multimedia@freebsd.org>; Tue, 18 Mar 1997 13:25:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.7.5/8.6.12) with SMTP id OAA18595; Tue, 18 Mar 1997 14:25:29 -0700 (MST)
Message-Id: <199703182125.OAA18595@Ilsa.StevesCafe.com>
X-Authentication-Warning: Ilsa.StevesCafe.com: Host localhost [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 1.6.5 12/11/95
From: Steve Passe <smp@csn.net>
To: Randall Hopper <rhh@ct.picker.com>
cc: multimedia@freebsd.org
Subject: Re: latest bt848 code 
In-reply-to: Your message of "Tue, 18 Mar 1997 14:06:46 EST."
             <19970318140646.02069@ct.picker.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 18 Mar 1997 14:25:29 -0700
Sender: owner-multimedia@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

> |the problem is in fxtv:
> |
> | tvcapture.c:TVCAPTUREStart(), around line 458: here Randall is resetting
> |the color values each time.  I discussed this with him, he was doing it
> |because of warnings about the driver easily loosing state of many values.
> |If you remove these lines the problem goes away without any side-effects
> |(that I can see).
> |
> |Randall, have you attempted to deal with this yet in your source tree?
>
>I did a rev last week (0.0.2, http://multiverse.com/~rhh/fxtv) to permit
>not always setting all parameters on startup and with each capture
>(e.g. input device, etc.), but I too noticed that the driver seemed to be
>forgetting the brightness/contrast across starts (I didn't have hue and U/V
>sat in that version).  So I left the "changed" bit on for these two
>parameters even after they were registered with the driver so that the next
>start would re-register these values.

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)

--
Steve Passe	| powered by
smp@csn.net	|            Symmetric MultiProcessor FreeBSD