Hello Ladislav,
some video hardware v4l is dealing with is in fact only clever DMA engine
with (say) YUV data bus on one side and on board or system memory on the
other side. video decoding or encoding is done by separate chip controlled
typicaly by i2c bus. for such purposes there are currenly these files
include/linux/video_decoder.h
include/linux/video_encoder.h
include/linux/sonypi.h -- SONYPI_COMMAND_*
Yes.
my question is: wouldn't be usefull to create only one file instead of
duplicating in fact the same defines and structs under slightly different
names? I don't want add just another header file into kernel.
Yes.
motivation: I need some interface to comunicate with IndyCam which is camera
made by SGI with i2c driven picture paramaters setting (shutter, gain, red
saturation...) and SGI D1 video data bus connected to VINO video capture
device. VINO is able to run two independent DMA, one from IndyCam and one
from SAA7191 decoder.
The problem is that the various video decoders out have very different
features. Take for example the Philips series of saa711x decoder:
saa7110 (from which the "video_decoder.h" is basically derived) up to
saa7111, saa7113, saa7114. All these chipsets are basically the saa7110,
but the saa7114 has so much more features (internal scaler, color
correction, more inputs, automatic teletext slicer, ...) that it's hard
to put this under one API.
Of course it would make sense to have one common video deooder API and
have i2c slave drivers for the different chipsets which follow this API.
In practice, however, you cannot simply take capture hardware X and
connect it to video decoder Y. This whole stuff is heavily interwoven,
so your programming will depend on each other: change something in the
hardware, then you'll have to change it in the decoder driver too.
For example, my driver at drivers/media/video/hexium_gemini.c in
linux-2.6 has everything built in. It still uses the kernel I2C api for
transferring the actual data, but it does not have a dedicated driver
for the Samsung KS0127B video decoder.
I have some startup data that's written to the device at driver load,
then some configurations for the different video norms (pal, ntsc, ...).
Brightness, contrast, saturation is not handled by the video decoder,
but it does not matter wheter I handle this in my hardware upon a
video4linux-ioctl or if I send some small message to the i2c client.
I wrote drivers for both and now I stopped on interface
between IndyCam driver and VINO driver.
My 2 ¢: I would make this as simple as possible and not waste much time
in defining an API that's won't be used outside of your driver.
ladis
CU
Michael.
