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 _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
