From owner-freebsd-multimedia  Tue Mar  3 10:30:32 1998
Return-Path: <owner-freebsd-multimedia@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA27611
          for freebsd-multimedia-outgoing; Tue, 3 Mar 1998 10:30:32 -0800 (PST)
          (envelope-from owner-freebsd-multimedia@FreeBSD.ORG)
Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.139.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA27605
          for <multimedia@FreeBSD.ORG>; Tue, 3 Mar 1998 10:30:30 -0800 (PST)
          (envelope-from james@miller.cs.uwm.edu)
Received: (from james@localhost)
	by miller.cs.uwm.edu (8.8.5/8.8.5) id MAA07082;
	Tue, 3 Mar 1998 12:30:19 -0600 (CST)
Date: Tue, 3 Mar 1998 12:30:19 -0600 (CST)
From: Jim Lowe <james@miller.cs.uwm.edu>
Message-Id: <199803031830.MAA07082@miller.cs.uwm.edu>
To: hasty@rah.star-gate.com, luigi@labinfo.iet.unipi.it
Subject: Re: Video ioctl interface
Cc: multimedia@FreeBSD.ORG
Sender: owner-freebsd-multimedia@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
> Subject: Re: Video ioctl interface
> To: hasty@rah.star-gate.com (Amancio Hasty)
> Date: Tue, 3 Mar 1998 17:20:10 +0100 (MET)
> Cc: multimedia@FreeBSD.ORG, james@miller.cs.uwm.edu
> 
> not really new interface, but...

An extensible interface which can handle hardware Mpeg and
sychnronizing audio/video would really be nice.

> 
> I was trying to make vic use the brightness/contrast/etc controls which
> are available on the meteor&bt848 and ran across a few probolems in
> grabber-meteor.cc, ui-grabber.tcl, and also brooktree848.c !

I have some patches for vic which will allow access to the controls
for the meteor card.  Do you want these?  I sent them into vic@ee.lbl.gov
quite some time ago, but I don't think there has been a recent release of vic.

> 
> Problems related to brooktree848.c :
> 
>     some ioctl are questionably located in tuner_ioctl(), e.g.
>     BT848_SCSAT, BT848_SVSAT etc.  Some of them are duplicates of
>     the METEORxxx functions in video_ioctl(), but i do believe they
>     still belong to video_ioctl().
> 
>     My understanding from the driver code is that only a single open is
>     allowed on the video (grabber) section, while multiple open() are
>     possible for the tuner section. If we want to keep applications
>     using the grabber simple, one possibility is to
>     - give access to ALL ioctl() from /dev/bktr ;
>     - give access to all non-capture related options from /dev/tuner
>       (i.e. brightness, contrast, etc).
>     This would enable the development of control-panel applications
>     (much like xmixer etc.) to set the brightness etc, while still
>     making applications which want to implement their controls able to
>     do it without having to carry around two file handles.
> 

Yes, having the mixer (or control) capability would be a nice feature.
There is always the problem of when to reset back to default values, but
I suppose that could be solved by keeping an open count.  The audio
drivers seem to just leave whatever the last value of the mixer was.
I am not certain this is the correct thing to do.  It makes debugging
problems difficult if you don't have a common starting point.

As Amancio suggested, a common multimedia interface for these devices
would be very useful.  I will try and dig up that old frame work we
discuss some time ago and maybe we can work that into something
useful.  Do you think that old frame work is a reasonable starting
point?

	-Jim

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message