From owner-freebsd-multimedia  Sun Mar  9 16:33:47 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id QAA24236
          for multimedia-outgoing; Sun, 9 Mar 1997 16:33:47 -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 QAA24231
          for <multimedia@freebsd.org>; Sun, 9 Mar 1997 16:33:44 -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 QAA00370; Sun, 9 Mar 1997 16:33:40 -0800 (PST)
Message-Id: <199703100033.QAA00370@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Steve Passe <smp@csn.net>
cc: multimedia@freebsd.org
Subject: Re: Anyone on the list who can check-in the bt848 driver? 
In-reply-to: Your message of "Sun, 09 Mar 1997 13:50:04 MST."
             <199703092050.NAA14728@Ilsa.StevesCafe.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 09 Mar 1997 16:33:39 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-multimedia@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi Steve,

You have a bug in xtvr such that it fails to call bktr_close when the
window closes this causes the driver to ignore further requests to 
initialize the hardware since the tuner open count never reaches 0.

This problem is easy to verify just place a debug printf statement on
bktr_open and bktr_close so you can track the open and close count.

I think is rather strange that xtvr fails to call bktr_close , the only
way that I can think of  that xtvr can do this is if the exit handler for
the process has been modified.

	Cheers,
	Amancio

>From The Desk Of Steve Passe :
> Hi,
> 
> > We should discuss with Jim Lowe and Mark Tinguely about divorcing 
> > the meteor ioctl structure from the BT848 . However if we do decide
> > to divorce the two of then I strongly suggest that we start thinking
> > about a video graphic library api and its respective implementation.
> 
> that was a rather brash comment on my part, after a little thought I
> realized that there must be applications that can use either card
> for their hardware component.  So we don't want to force
> them to change any code (except perhaps the open call, meteor vs bt).
> 
> Long term we do need to think about an api.  for now I will minimize
> my additions to ioctl_meteor.h, and demarcate them clearly
> with a #define.
> 
> --
> Steve Passe	| powered by 
> smp@csn.net	|            SMP FreeBSD
>