> > I can't see any advantages you get ... > > One of the advantages of v4l2 (especially for serious image processing) > is that it is not limmited to the arbitrary minor number ranges - you > therefore can't extract the base name from the minor number as v4l1 > does. Hmm, looks like I've missed that part of the v4l specs until today. IMHO it is a very bad idea as long as devfs is optional. Creating special files is the job of /sbin/MAKEDEV, not the job of the admin. The different device types need fixed minor number mappings. > > v4l2 drivers are supported to be backward compatible to v4l, so they have > > to interpret VIDIOCGVBIFMT anyway. And I can't see any advantages v4l2 > > has here, so why support two different ways to do exactly the same? > > Actually, only the compatibility layer is supposed to interpret > VIDIOCGVBIFMT, Ok, was meant from the applications point of view. For a application it makes no difference whenever the driver itself or some compatibility layer handles the ioctl. Of course it can be the compatibility layer too. But I still don't see the point in adding the v4l2 vbi API. > although nobody has implemented it yet (in fact, I have > never seen an application actually USE VIDIOCGVBIFMT!). I suspect it would'nt be in the kernel if nobody uses it. Someone must have mailed the patch, and the one probably uses it ... Gerd
