From owner-freebsd-multimedia  Tue Oct  7 20:00:43 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA12801
          for multimedia-outgoing; Tue, 7 Oct 1997 20:00:43 -0700 (PDT)
          (envelope-from owner-freebsd-multimedia)
Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA12789
          for <multimedia@FreeBSD.ORG>; Tue, 7 Oct 1997 20:00:39 -0700 (PDT)
          (envelope-from rhh@ct.picker.com)
Received: from ct.picker.com by whqvax.picker.com with SMTP;
          Tue, 7 Oct 1997 20:57:05 -0400 (EDT)
Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1)
	id AA16633; Tue, 7 Oct 97 20:56:58 EDT
Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4)
	id UAA04408; Tue, 7 Oct 1997 20:50:57 -0400
Message-Id: <19971007205057.36136@ct.picker.com>
Date: Tue, 7 Oct 1997 20:50:57 -0400
From: Randall Hopper <rhh@ct.picker.com>
To: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br>,
        Amancio Hasty <hasty@rah.star-gate.com>
Cc: multimedia@FreeBSD.ORG
Subject: [video] tuner input format issues
References: <199710051045.HAA11860@gaia.coppe.ufrj.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81
In-Reply-To: <199710051045.HAA11860@gaia.coppe.ufrj.br>; from Joao Carlos Mendes Luis on Sun, Oct 05, 1997 at 07:45:33AM -0300
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Jonny, your patches applied without a hitch.  Thanks.

As I was merging them in though, several issues related to format selection
occurred to me.  

First, I'm assuming that selecting anything but NTSC/M, NTSC/J, or PAL/M on
a non-NTSC tuner isn't really a valid thing to do.  Similarly for selecting
the three above types on, say, a Temic or Philips PAL tuner.  And is
anything but SECAM valid on a Philips SECAM tuner?

Seems what we need is a driver ioctl to return the supported input formats
for the installed tuner.  Apps like Fxtv could use this to suppress GUI and
resource file selection of these invalid input formats.  Some other
tuner-specific info would be useful in the return struct for this new
"tuner capabilities" ioctl as well: max capture geometry (640x480 or
768x576) and max FPS (30 or 25).  The latter two would let fxtv get rid of
these hard-coded FIXME values that are input-format specific.

I'd add this ioctl myself if I knew all the input-format capabilities of
each tuner.  If you know (Jonny, or anyone), fill me in and I'll cook the
driver patch.

Second, I disabled the selectability of the "AUTO" input format.  I think
we need some driver and app mods to support this.  If we can assume that a
particular tv card only supports one max res and max fps limit across all
its inputs (i.e. either 640x480x30 or 768x576x25, never both regardless of
input or selected input format), then we just need a way to query this max
res and max fps from the driver so we can set up the appropriate transfer
size and capture limitations in the app dynamically before engaging AUTO
input format selection.  If the above assumption isn't valid, some
different driver changes would be needed.

Randall