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.
-- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/video4linux-list
