[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
> 

Hi,

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 ...

Cheers,
Hermann







More information about the linux-dvb mailing list