From owner-freebsd-multimedia  Tue Mar 24 10:38:16 1998
Return-Path: <owner-freebsd-multimedia@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA08992
          for freebsd-multimedia-outgoing; Tue, 24 Mar 1998 10:38:16 -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 KAA08873
          for <multimedia@freebsd.org>; Tue, 24 Mar 1998 10:37:57 -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 MAA05132;
	Tue, 24 Mar 1998 12:37:10 -0600 (CST)
Date: Tue, 24 Mar 1998 12:37:10 -0600 (CST)
From: Jim Lowe <james@miller.cs.uwm.edu>
Message-Id: <199803241837.MAA05132@miller.cs.uwm.edu>
To: hasty@rah.star-gate.com, luigi@labinfo.iet.unipi.it, rhh@ct.picker.com
Subject: Re: Video ioctl interface
Cc: multimedia@FreeBSD.ORG
Sender: owner-freebsd-multimedia@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

[...LONG...]

> From: Randall Hopper <rhh@ct.picker.com>
> 
>  1) Are we sure it's really worth the effort at this point?

I am sorry I haven't gotten back to you sooner on this.  I think what we
need is to have a generic multimedia interface for both audio and video.
The interface must have the ability to change and have functionality added.
Today, we have separate audio, video capture, and mpeg encoders/decoders.
It would be nice to be able to present all different types of mm
hardware with a single interface. 

...plug on: Luigi and I are scheduled to talk about the current audio
and video interfaces for the Freenix track of Usenix, Thursday morning,
June 18th, in New Orleans, http://www.usenix.org/events/no98.  It would
be great if a group could get together during this event to discuss
multimedia issues.  Is there any interest in this?
:plug off...


> From: Randall Hopper <rhh@ct.picker.com>
>   
>  2) I'd like us convert to this model:
>   
>           Applications ->  Capture Library -> Capture Devices
>           Applications ->  Tuner   Library -> Tuner Devices
>> From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
>> 
>> this is a question of personal preference of course, but i am generally
>> against libraries unless they provide some significant functionality
>> (i.e. they do more than shuffling parameters), and function names are
>> reasonably short...

I agree with Luigi here.  I don't think we really need a library at
this time.  I think libraries have their uses, but we need a generic
extensible interface to the hardware.  Fopen() is nice, but there
are applications which still want to use open().

The library, with all its frills, can come once we have a reasonable
interface defined.  Actually, I suspect a library will be a natural
fall out once the interface is defined.  The model I would prefer:

                +--> Devices       <--> Device helper daemon(s), configuration.
                |                       [...move kernel bloat here...]
Applications <--+--> Libraries     <--> Library helper routines, daemon(s).
	        |
	        +--> Documentation <--> Doc helper routines, daemon(s).


>   
>  3) Generic, extensible interface.

I agree.

>   
>     No interfaces to explicitly open specific devices or set/get specific
>     parameters (e.g. contrast, brightness, hue, etc.) on a device.
>   
>     Have a generic interface to query which capture/tuner devices are
>     available, which parameters for each device are supported, and for each,
>     what their valid value ranges are.  E.g.:
>   
>         TUNERLIB_DEV    *TunerLib_GetInstalledTunerDevByIndex( i );
>         TUNERLIB_DEV    *TunerLib_OpenTunerDev( dev, i );
>   
>         TUNERLIB_PARAM  *TunerLib_GetParamByIndex( dev, i );
>         TUNERLIB_PARAM  *TunerLib_GetParamByName( dev, "CONTRAST" );
>         TUNERLIB_PRANGE *TunerLib_GetParamRange( dev, param );
>         TUNERLIB_PRANGE *TunerLib_SetParam( param, double value );
>         ...

Forgive me here, I am not trying to create a flame war, but it looks like
we might be trying to create something similar to what X does to a graphics
display, or what MVS did to IBM 360 architecture.  There must be
a better way to create an interface other than 1000 library calls,
each with 1000 different options, each with
really_long_names_that_I_cannot_remember_without_looking_at_the_include_files.

Maybe this can't be avoided in the long run, but there must be a better
way.  Does anyone have any ideas in this area?  Creating an interface
which resembles X is rather distasteful to me.

At a min, I think we should be able to have a multimedia set up program
which will initialize the multimedia devices for PAL, NTSC, MU_LAW, tuner
frequencies, etc...  This program could also run as a daemon connected
to a master multimedia device which would do software emulation of
functions which are not supported directly in hardware.  The alternative
to this approach would be to have support libraries which the applications
call as Randall suggests.  Maybe the best approach would be to have both.


>   
>      So all this stuff:
>   
>              #define BT848_SBRIG     _IOW('x', 38, int)  /* set brightness  */
>              #define BT848_GBRIG     _IOR('x', 38, int)  /* get brightness  */
	[...can go away...]

I agree that this stuff should be at a different level and somehow
have a mapping from a generic interface level to whatever the
particular card(s) can handle.

Here are some thoughts from a previous message that was bouncing
around between a few of us last October.   This ioctl definition
doesn't address the issue I brought up above.
-------------------------------------------------------------------
...
.../*
... * Multi-media ioctl interface definition (not to be confused with the
... * candy (m&m's).
... */
...#define MM_MAJOR_VERSION	1
...#define MM_MINOR_VESRION	0
...#define	MM_VERSION		((MM_MAJOR_VERSION << 16) | (MM_MINOR_VERSION))
...enum v0100_functions {
...	MMGHCAPS,	/* Get hardware capabilities */
...	MMGSCAPS,	/* Get software (emulation) capabilities */
...	MMSTART,	/* Start processing (go) */
...	MMGFORMAT,	/* Get format  */
...	MMSFORMAT,	/* Set format  */
...	MMGMICROCODE,	/* Retrieve microcode */
...	MMSMICROCODE,	/* Download microcode */
...	...
...};
...typedef v0100_functions	functions;
...
...struct	_mm_info	{
...	unsigned int	version;
...	functions	function;
...	unsigned 	size;
...	caddr_t		buffer;
...};
...typedef struct _mm_info mm_info;
...
...#define MM_W	 _IOW('M', 1, mm_info)
...#define MM_R	 _IOR('M', 1, mm_info)
...#define MM_WR _IOWR('M', 1, mm_info)
...#define MM	 _IO('M', 1)
...
...	mm_info	mm;
...
...	mm.version = MM_VERSION;
...	...
...	mm.function = MMGCAPS;
...	ioctl(f, MM_R, &mm);
...	... parse capabilities... [should be a library function]
...	
...	audio.format = MU_LAW;
...	mm.buffer = &audio.format;
...	mm.size = sizeof(audio.format);
...	mm.function = MMSFORMAT;
...	ioctl(f, MM_W, &mm);
...	...
...	mm.function = MMSMICROCODE;
...	mm.size = sizeof(dsp_microcode);
...	mm.buffer = dsp_microcode;
...	ioctl(f, MM_W, &mm);
...	...
...	mm.function = MMSTART;
...	ioctl(f, MM, &mm);
...
...Wouldn't the above work and give us the flexibility we need and still
...maintain the standard Unix ioctl type calls?  Of course, things would
...look better with a suitable library/API type interface to the ioctl
...calls.  Functions like:
...
...	mm_api	*mm;
...
...	mm = mm_open(device);
...	if(mm_get_format(mm) != MU_LAW)
...		(void)mm_set_format(mm, MU_LAW);
...	(void)mm_set_microcode(mm, buffer);
...	(void)mm_go(mm);
...	(void)mm_close(mm);
...
...Certainly a standard library could ``hide'' many of the backward
...compatibility issues and void kernel bloat in this area.

--------------------------------------------------------

I could go on about these issues, but this message is long enough and
overdue.  

I am really interested in starting some sort of discourse on this subject.
The Usenix conference would be one way for many of us to sit around a
table and hash this out.  We could also try and schedule something on
the Mbone.  Is everyone fairly well connected on the Mbone?

	-Jim

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