On Tue, Oct 07, 2003 at 07:22:50PM +0200, Michael Hunold wrote: [snip] > 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. I agree. However, I'm talking only about header defining ioctl like interface between (in sonypi case) drivers/char/sonypi.c and drivers/media/video/meye.c. > 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. yes, but there is no need to name the same thing differently and put it into separate files. your v4l driver knows what decoder is connected to your capture hardware and I'm proposing following simple thing (see diff -u include/linux/video_decoder.h include/linux/video_encoder.h before reading more). Imagine those files merged under name video_whatever.h where DECODER_GET_CAPABILITIES and ENCODER_GET_CAPABILITIES becomes WHATEVER_GET_CAPABILITIES. I hope it is clear that now we have one file less only by changing several identifier names. Then look at include/linux/sonypi.h header and you'll find that all SONYPI_COMMAND_* are only different names for what we already have (WHATEVER_SET_PICTURE could be used instead sonypi_camera_command in VIDIOCSPICT ioctl at line 986 in drivers/media/video/meye.c (2.4.22)) and we just have to add defines to query camera version and other specific stuff. In fact it doesn't mean any code change, just naming changes. > 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 could of course do the same, but there is also MooseCam and other products which could be connected to different capture devices and that would mean code duplication. > 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. I did so, but before even trying to push it into kernel it's always better to discuss eventual better solution than blindly add just another unsorted mess into kernel. I'd like to provide painless future nothing more. If you think above is silly idea and I'm missing something obvious just let me know. In case that you found it usefull I'm voluntering to create patch and send it here, but note that I need to know your opinion (and opinion of v4l maintainer(s)) first. regards, ladis
