Thread: [libvidcap-devel] question about v4l2 interface

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Is there any plan to develop a v4l2 interface? Most of the cameras I
have use v4l2 now days.

Hi Rory,

On Thu, Jun 19, 2008 at 8:13 PM, Rory Petty <ror...@gm...> wrote:
> Is there any plan to develop a v4l2 interface? Most of the cameras I
> have use v4l2 now days.

I haven't looked in-depth at the differences between v4l and v4l2
lately, but as I recall there was not a clear benefit in using the
additional stuff that v4l2 provides over v4l for what libvidcap was
trying to accomplish.  All those v4l2 devices are backwards compatible
with v4l, so using the older v4l API actually allows for somewhat more
device support than using v4l2.

Is this different than your understanding? Are there features in v4l2
that might benefit libvidcap?

Thanks,
Pete

On Fri, Jun 20, 2008 at 8:53 PM, Rory Petty <ror...@gm...> wrote:
> Peter,
>
> Thanks for the reply. I have a camera that has an empia 2760 chip and
> is supported as a UVC device under linux using the uvcvideo kernel
> module. From what I can tell however, it only shows up as a V4L2
> device. For example, I cannot get it to show up using either
> vidcaptester or simplegrab, as it provides the error can't find device
> /dev/video0. I also tried several other utilities such as xawtv,
> tvtime and camstream and none of them can see the video device.
> However, I can see the video fine without any configuration using
> ekiga or skype. From my reading of various forums, people seem to
> indicate this is because the uvc video project is only implementing a
> v4l2 interface. Any ideas how i can get a v4l2 device to show up in a
> program like vidcaptester using only v4l? I know there is a v4l2 to
> v4l compatibility layer, but my understanding is that it does not
> implement all the mappings and that the code is getting pretty stale.

That makes sense. I suppose one way to go would be to write a v4l2
source api backend for libvidcap. In other words, write sapi_v4l2.c.
Alternatively, it seems like it would be possible to extend the
existing sapi_v4l.c to first attempt to use the v4l2 interfaces and
then fallback to v4l if there are no v4l2 devices available. Offhand,
I'm not sure which approach would be better.

I am not going to have the bandwidth to work on this myself anytime
soon (or even later), but patches are welcome.

Thanks,
Pete