From owner-freebsd-multimedia  Tue Mar 18 15:38:32 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id PAA10909
          for multimedia-outgoing; Tue, 18 Mar 1997 15:38:32 -0800 (PST)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA10904
          for <multimedia@freebsd.org>; Tue, 18 Mar 1997 15:38:28 -0800 (PST)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id PAA16568; Tue, 18 Mar 1997 15:38:32 -0800 (PST)
Message-Id: <199703182338.PAA16568@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Steve Passe <smp@csn.net>
cc: Randall Hopper <rhh@ct.picker.com>, multimedia@freebsd.org
Subject: Re: latest bt848 code 
In-reply-to: Your message of "Tue, 18 Mar 1997 16:27:17 MST."
             <199703182327.QAA20034@Ilsa.StevesCafe.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 18 Mar 1997 15:38:31 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-multimedia@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

You can commit the changes . I don't have commit privileges nor do I want them.


Yes, I realize what you guys are trying to do.
If you wish to preserve information write it down to a file when the application
exits. During normal execution , is not a problem. I hate to preserve
state information such as the one that you guys are asking and no it is
not hard to implement, again is not a good practice to have at the driver
level. Actually, it would not surprise if some of you may get battery
back up for your favorite Bt848 based card to preserve its state between
power cycles 8)

All in all things are really shaping up 8)

	Have fun guys,
	Amancio

>From The Desk Of Steve Passe :
> Hi,
> 
> >From a driver point of view , when the device gets open the device
> >will be set to defaults values. Applications shouldn't depend
> >on keeping state information between close/open. In fact thats a
> >bad practice.
> 
> in general I agree, but in this case its nice if the TV comes up the
> way it was last set, just like a "real" Tv does.  thats the model
> I am trying to achieve.  If its a big pain to achieve don't worry
> about it.
> 
> I fixed the DEV_MASK problem in open:
> 
> 	bt848[BKTR_IFORM] = 0x69;
> +	bktr->flags = (bktr->flags & ~METEOR_DEV_MASK) | METEOR_DEV0;
> 
> you also have a redundant:
> 
> 	bktr->flags |= METEOR_OPEN;
> 
> in there.
> 
> Now xtvremote can determine the tuner type and channel that the card is
> currently set to.  the color controls ( hue, etc. ) can also be accurately
> read on startup, although they get reset to defaults by the 1st open.
> this I can live with , now that GINPUT now accurately reflects the open state
.
> 
> do you have commit privileges, or should I commit the setting of DEV_MASK
> in open?  I have to commit some new tuner code anyways (once someone
> confirms it works).
> 
> 
> --
> Steve Passe	| powered by
> smp@csn.net	|            Symmetric MultiProcessor FreeBSD
>