From owner-freebsd-multimedia Tue Mar 18 15:16:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA09528 for multimedia-outgoing; Tue, 18 Mar 1997 15:16:41 -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 PAA09518 for ; Tue, 18 Mar 1997 15:16:38 -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 PAA16218; Tue, 18 Mar 1997 15:16:39 -0800 (PST) Message-Id: <199703182316.PAA16218@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: Randall Hopper , multimedia@freebsd.org Subject: Re: latest bt848 code In-reply-to: Your message of "Tue, 18 Mar 1997 15:55:04 MST." <199703182255.PAA19630@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Mar 1997 15:16:38 -0800 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Okay, I will fix the driver this weekend. >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. > *bt848 = 0x3; > *bt848 = 0xc0; bit 0 chroma overflow bit 1 luma overflow bit 7 video preset bit 6 device in h-lock The above just resets the status bits . Writing a one to the bit clears the condition. In the case of *bt848 = 0xc0 the card , the card resets the video signal upon the next video frame. Amancio >From The Desk Of Steve Passe : > hi, > > >From The Desk Of Randall Hopper : > > > I'll do some tests later to verify that brightness/contrast/etc. do in fa ct > > > keep their values across stops/starts when the driver handle is held open . > > > > > > > The driver does keep the brightness/constrast/etc.. values while the > > the device is open. I have a modified version of dtv which moves down > > the screen and it does not lose brightness nor contrast. > > we're past that problem now, fxtv was doing close/open for every > redraw. now I'm looking at what can bee done to save state between the > last close and the next (1st) open. > > In particual open DOES NOT seem to set METEOR_DEV_MASK (it contains > whatever it was at the point of the last close) BUT the open seems to > reset the actual input device (haven't figured out where yet). So > it needs to be fixed so that either the input device is only reset > by attach (which does set METEOR_DEV_MASK) or if the input device > must be reset by the 1st open call, METEOR_DEV_MASK should be set to > reflect the input. > > The reason for the above requested fix is that xtvr needs to have an > accurate idea of what the true input is. It does this by doing an > METEORGINPUT ioctl. Since this returns the value from the previous open, > if that input wasn't the same as what open resets it to it gets confused. > > Question: > > what does this code in open() do: > > /* dump_bt848(bt848); */ > *bt848 = 0x3; > *bt848 = 0xc0; > > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD >