From owner-freebsd-multimedia  Tue Mar 18 11:10:28 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id LAA18497
          for multimedia-outgoing; Tue, 18 Mar 1997 11:10:28 -0800 (PST)
Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA18485
          for <multimedia@freebsd.org>; Tue, 18 Mar 1997 11:10:23 -0800 (PST)
Received: from ct.picker.com by whqvax.picker.com with SMTP;
          Tue, 18 Mar 1997 14:09:36 -0500 (EST)
Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1)
	id AA12267; Tue, 18 Mar 97 14:09:33 EST
Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4)
	id OAA16082; Tue, 18 Mar 1997 14:06:46 -0500
Message-Id: <19970318140646.02069@ct.picker.com>
Date: Tue, 18 Mar 1997 14:06:46 -0500
From: Randall Hopper <rhh@ct.picker.com>
To: Steve Passe <smp@csn.net>
Cc: Amancio Hasty <hasty@rah.star-gate.com>,
        "Louis A. Mamakos" <louie@TransSys.COM>, multimedia@freebsd.org,
        Randall Hopper <rhh@ct.picker.com>
Subject: Re: latest bt848 code
References: <199703181823.KAA14137@rah.star-gate.com> <199703181851.LAA16713@Ilsa.StevesCafe.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.65
In-Reply-To: <199703181851.LAA16713@Ilsa.StevesCafe.com>; from Steve Passe on Tue, Mar 18, 1997 at 11:51:46AM -0700
Sender: owner-multimedia@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Steve Passe:
 |Amancio said:
 |>Also this weekend I will look into the problem with contrast, color
 |>saturation values being forgotten by the driver.
 |> ...
 |>>From The Desk Of "Louis A. Mamakos" :
 |>...
 |>> One that that I have noticed is that the state of brightness,
 |>> contrast, etc, seems to be lost whenever the frame capture starts up
 |>> again after an expose, resize, etc.
 |
 |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'll reverify this behavior later this evening with the 3/16 rev of the bt
driver, but I believe I saw the problem with it as well.

BTW Steve, when you get a few minutes, you might add some code to xtvr so
that it re-queries the current driver params and updates display on an
EnterNotify event for your top level shell.  I've added similar code to the
0.3 rev of fxtv I'm working on.  Found this approach in the xmix source and
it seems a pretty reasonable way for apps to share control of driver
parameters.

Randall