I know this is verbotten...but man, its so much easier to write a ring-0 driver in "das Vindows". Althought I have to admit since I've been stuck playing Linux with a company that thinks "gnu" means "abc" (ain't been copywrited, yet) I have had fun. ----- Original Message ----- From: "Michael Hunold" <hunold@xxxxxxxxxxxxxx> To: <video4linux-list@xxxxxxxxxx> Cc: "Stelian Pop" <stelian@xxxxxxxxxx> Sent: Tuesday, October 07, 2003 1:22 PM Subject: Re: intermodule communication > 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. > > > -- > video4linux-list mailing list > Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-list >
