Hello Gerd,
> > 2) It only supports on tea6420 at adress 0x98, while my
> > "Multimedia eXtension boards" has two tea6420s at
> > adresses 0x98 and 0x9a.
>
> Thats easy to fix I think.
Sure, but it has to be done, though.
> > 3) It does not support to exactly specify which input should be
> > connected to an output.
>
> Hmm, the v4l interface allows to select a input only...
Sorry about being unprecise. The tea6420 has 5 stereo inputs
and 4 stereo outputs. In my case, I have two cascaded tea6420s
to provide 8 different inputs (Tuner, Camera, external MPEG,
AUX1, AUX2, AUX3, external Radio, CD-Rom) to two ouputs
(one output to line, one output to cd-rom).
(Perhaps this does not make sense to you, but it's really
like that... 8-)
A little ascii-art from my documentation:
+--------+ +--------+
Tuner--|1 1|-----------|1 1|--CD
CD-----|2 2|-----------|2 2|
Radio--|3 9a 3|- AUX3--|3 98 3|--Line
CAM----|4 4|- AUX2--|4 4|
MPEG---|5 | AUX1--|5 |
+--------+ +--------+
At the end, when v4l2 asks me to switch a channel, I have to
do the following for example: switch the Camera-Audio to line-out
means switching input 4 to ouput 1 on the tea6420 #1 and
switching input 1 to output 3 on tea6420 #2.
The MXB is really complicated on this topic because it
features so many different audio sources.
> > I don't think it is a good solution to keep the driver so
> > close to video4linux or bttv. The tea6420 (just like any other
> > i2c-chipset) can be used in different environments and should
> > be kept separated from other things.
>
> Might be true for the tea6420 as it does just switching, but
> is'nt for most others. There are i2c chips which do audio
> processing (nicam/fm-stereo/sap decoding), for them it makes
> absolutely no sense to use them in another environment than
> TV / video4linux. Thats why I decided to simply pass throuth
> the ioctls instead of inventing yet another interface for
> every different chip.
Hmm, you are certainly right somehow. Adding another abstraction
layer is plenty of work, although things would be much ... cleaner.
But because of the fact that we all have only limited time,
things are like they are. 8-)
> It has also the advantage that bttv
> doesn't need to know any details about the helper chips.
>
> One not-yet solved problem is to find a nice way to pass
> around configuration informations like "this board has the
> tuner on input #2" or "this board has chip foo at addr bar".
With saa7146-based hardware, the same problems are present --
but even worse, because the saa7146 does not even now
inputs -- it only knows two data streams. The analog video
input has to be decoded first by a saa7111 for example.
Here is a short describtion of how I am trying to solve
the problem:
I decided to do write a two layer driver: the lower layer
handles all pci-device registration stuff and handles the
main v4l2-stuff that is similar in every hardware, e.g.
mode switching (pal/ntsc/secam), interrupt-based capturing,
overlay clipping etc.
In addition, you can register so-called 'extensions', for
example the extension for the "Multimedia eXtension Board".
These extensions register themselves to the core-driver
and describe what stuff they support (via v4l2_capability).
When an saa7146 is found, a probe function for each extension
is called. Commonly, the extension checks for existing i2c-slaves
and tries to determine if the hardware is present.
The extension can attach to any v4l2-ioctl and perform
specific action before or after the core-driver handles
them. (It can even prevent the core-driver from handling
ioctls.)
I hope you get the idea.
For bttv this would mean, that there would be one extra
extension for every available bt8x8-based card out there,
which would check and perform the specific calls to some
ioctls.
> One not-yet solved problem is to find a nice way to pass
> around configuration informations like "this board has the
> tuner on input #2" or "this board has chip foo at addr bar".
With this construction, you could get rid of the problem
because there is one module for each hardware, describing
exactly what has to be done.
> Gerd
CU,
Michael.
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
