> > 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
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
