[linux-dvb] Re: Can video_ioctl2() be unlocked?
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
> 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
> 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 :-)
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