[linux-dvb] Re: Can video_ioctl2() be unlocked?

hermann pitton hermann-pitton at arcor.de
Thu Oct 19 02:53:41 CEST 2006

Am Mittwoch, den 18.10.2006, 23:34 +0200 schrieb Hans Verkuil:
> On Wednesday 18 October 2006 17:18, Laurent Pinchart wrote:
> > Mauro,
> >
> > > > > We've also started a project to have a userspace library. This
> > > > > way, handlers for newer palettes and similar stuff can go there
> > > > > and be used in the future by any V4L-aware app.
> > >
> > > It is on a very early stage currently. I'm sure you can help a lot
> > > on improving it if you want :)
> >
> > Why hasn't this been announced on the v4l mailing list ?
> >
> > > > Where can the code be found ? Who is the maintainer ? Who are the
> > > > developers ? Where can I find the specs ?
> > >
> > > It is currently together with v4l-dvb tree. it is under v4l2-apps.
> > > Hans did most of the stuff there, including the library.
> >
> > Why was the design stage kept private ?
> Basically because there isn't a real v4l2 library. All I did was to 
> setup a very rudimentary v4l2 library that only contains the frequency 
> tables that are currently in vl42 apps. To quote the README in 
> v4l2-apps: 'This code is still in its infancy and is not yet suitable 
> for general use. However, it is a start.' I do not have time in the 
> foreseeable future to continue work on this. Volunteers are welcome. 
> And part of that work is to make a real design and work out what is 
> needed.
> Much more useful already are the test utilities v4l2-ctl and qv4l2. The 
> first is a command line utility that can be used to query and set v4l2 
> properties, controls, etc. And qv4l2 is a GUI app that does a similar 
> job, but uses a GUI and is ideal for real-time testing. It was used for 
> testing the extended controls API.
> v4l2-ctl was based on ivtv code and qv4l2 is derived from v4l2-ctl in 
> turn.
> And to put in my 5 cent in this discussion: private ioctls might be 
> unavoidable sometimes, but 1) they should be discussed on the ML, 2) it 
> is a good idea to keep them experimental for a few months at least (or 
> even longer) to check whether it works out, and 3) they always must be 
> documented in the v4l2 spec, even if they are specific to only one 
> driver. We have a wonderful v4l2 spec and it should be kept up to date. 
> And for me undocumented APIs effectively do not exist.
> And before you mention that the extended control API isn't documented 
> either: it's almost done, I only need to do a bit of proofreading to 
> check whether I didn't miss anything. :-) It should be in the next 
> version of the v4l2 spec.
> But in any case, this is something that you deal with as it appears. And 
> I know that some of the currently ivtv-private ioctls will be in this 
> problematic area, so I may well be the first person whose going to have 
> to deal with it.
> Regarding Mauro's new framework for the ioctls: the proof of the pudding 
> is to actually convert an existing driver of at least medium complexity 
> to the new code and see how it goes. I'm not convinced of the concept 
> either, but then I haven't had the time to investigate it closely.
> You made some good points regarding the implications of this concept, 
> however until the first 'real-life' driver is converted as a test case 
> I personally won't be spending any time on it (or be stressed by it :-) 
> since I consider it to be pretty much draft code. I certainly won't be 
> converting ivtv to the new framework. Sorry Mauro! :-) But this 
> definitely would not be a reason for me to refrain from integrating the 
> ivtv driver into the kernel as the advantages far outweigh the 
> disadvantages. Not only for me as maintainer, but also for the 
> end-users who are finally free of all the configuration problems as 
> ivtv becomes part of the big distros.
> Mauro, if you want people to really look into it and get a good 
> evaluation of the code, then you first need to convert an existing 
> driver to the framework (and apologies in case you've already done that 
> in one of your hg trees and I missed it), do memory footprint tests, 
> see how much code is saved, get a feeling how it behaves when new 
> ioctls are added (private or otherwise), see how it interacts with i2c 
> drivers (which all use the ioctl mechanism), etc. The vivi.c driver is 
> NOT a representative example.
> Well, that's enough for one evening I think :-)
> Regards,
> 	Hans


just my one cent.

Those discussions should also be send over to the DVB ML,
since there will hardly be hardware in the future _not_ using digital
video and that is already the main feature on most products.

Compared to it cams and encoders are minor issues ...


More information about the linux-dvb mailing list