v4l2loopback and kernel-3.7

v4l2loopback and kernel-3.7

[forum::für::umläute]

hi all,

i'm currently maintainer of the "v4l2loopback" device [1], a virtual
video device that allows applications to share video-streams via the
v4l2 API (each device being V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT).

now (unfortunately for someone maintaining a driver) i have not been
following development of the linux-kernel very closely (mainly using
debian unstable kernels myself), but some of my users do.
it seems that with newer kernel-versions the functionality for
video-output modules have been somehow removed from the kernel (3.7.1
has been confirmed to make troubles, whereas 3.6.10 still works).

i'd like to inquire, what happened in/to the mainstream kernel, and
what's the supposed way to proceed for a virtual video device like mine.
(i naively ask the question here, as i'm a bit afraid of kernel-dev
mailing list :-))

what's more, if the v4l2-taskforce would be interested to take over a
kernel-module that - to my knowledge - is currently the only feasible
way on linux to exchange live video streams between applications, we
might talk about that :-)

fgasdmr
IOhannes




[1] https://github.com/umlaeute/v4l2loopback/

Re: v4l2loopback and kernel-3.7

[forum::für::umläute]

On 2013-01-24 16:59, forum::für::umläute wrote:
> hi all,

just in case: please CC me, as i'm not subscribed to this list (yet).

gfadmsr
IOhannes

> 
> i'm currently maintainer of the "v4l2loopback" device [1], a virtual
> video device that allows applications to share video-streams via the
> v4l2 API (each device being V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT).
> 
> now (unfortunately for someone maintaining a driver) i have not been
> following development of the linux-kernel very closely (mainly using
> debian unstable kernels myself), but some of my users do.
> it seems that with newer kernel-versions the functionality for
> video-output modules have been somehow removed from the kernel (3.7.1
> has been confirmed to make troubles, whereas 3.6.10 still works).
> 
> i'd like to inquire, what happened in/to the mainstream kernel, and
> what's the supposed way to proceed for a virtual video device like mine.
> (i naively ask the question here, as i'm a bit afraid of kernel-dev
> mailing list :-))
> 
> what's more, if the v4l2-taskforce would be interested to take over a
> kernel-module that - to my knowledge - is currently the only feasible
> way on linux to exchange live video streams between applications, we
> might talk about that :-)
> 
> fgasdmr
> IOhannes
> 
> 
> 
> 
> [1] https://github.com/umlaeute/v4l2loopback/

Re: v4l2loopback and kernel-3.7

[Hans Verkuil]

On Thu January 24 2013 16:59:36 forum::für::umläute wrote:
> hi all,
> 
> i'm currently maintainer of the "v4l2loopback" device [1], a virtual
> video device that allows applications to share video-streams via the
> v4l2 API (each device being V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT).
> 
> now (unfortunately for someone maintaining a driver) i have not been
> following development of the linux-kernel very closely (mainly using
> debian unstable kernels myself), but some of my users do.
> it seems that with newer kernel-versions the functionality for
> video-output modules have been somehow removed from the kernel (3.7.1
> has been confirmed to make troubles, whereas 3.6.10 still works).
> 
> i'd like to inquire, what happened in/to the mainstream kernel, and
> what's the supposed way to proceed for a virtual video device like mine.
> (i naively ask the question here, as i'm a bit afraid of kernel-dev
> mailing list :-))

In 3.7 the vfl_dir field was added to struct video_device. For output
devices this has to be set to VFL_DIR_TX. For devices that do both
capture and output it has to be set to VFL_DIR_M2M (memory-to-memory).
Otherwise the v4l2 core will assume that it is a capture device and
disable any output support.

> 
> what's more, if the v4l2-taskforce would be interested to take over a
> kernel-module that - to my knowledge - is currently the only feasible
> way on linux to exchange live video streams between applications, we
> might talk about that :-)

Personally I am all for that, but I know Mauro has (had?) reservations
about it. Looking at the code it would also be a fair amount of work
to get it ready for inclusion in the kernel.

Frankly, I wonder if much of the functionality isn't already part of the
mem2mem_testdev driver.

Regards,

	Hans