V4L2-library July 2007

v4l2-library@linuxtv.org

6 participants
5 discussions

[PATCH] v4l2_extension module
by Thierry Merle 10 Aug '07

10 Aug '07

Hello all, here is a first modification to provide the v4l2_extension module that does the clone device for a device driver. It does nearly nothing in fact, just creates a new device that clones the real device. - The first problem I encounter is in the video_open function, to call the open function of the base video driver. How to simulate the file opening for the base driver? This is mandatory to make the kernel create the private data for the base driver and use it in further calls. In a second patch I will show you how a driver should use this extension for usbvision as an example, but can be easily be done for other drivers. - A good idea would be to have this registering procedure be done in videodev but as it is coded it is impossible (cyclic dependency between v4l2_extension and videodev). Well, I am on vacation next week so I will not be able to respond to comments... be patient again :) Cheers, Thierry --

1 1

Linux Kernel To Have Stable Userspace Drive
by Alfonso Acosta 30 Jul '07

30 Jul '07

http://developers.slashdot.org/developers/07/07/22/0442236.shtml I haven't checked the specs for a while .. but the initial planned effort entailed coding a userspace driver and I though this could be of interest.

2 1

Question about the specs..
by Romain Beauxis 30 Jul '07

30 Jul '07

Hi all ! I wonder wether the extended device should be the default shown to user, and the pair basic+extended only available when asked ? No matter how this can be done, via udev or the kernel itself, I think in most of cases, e.g. basic webcam streaming, the end user will need only uncompressed data, so two different devices for the same hardware would make it more confusing .. ? Also, I guess we have to start a daemon project around this.. Should we do it here or anywhere else ? Romain -- They swapped my brother now, also, my sister too for a drink of wine, so they could drink and be merry, so they could drink and be merry.

2 1

[PATCH] usbvision and v4l2_extension
by Thierry Merle 20 Jul '07

20 Jul '07

Hello again, here is the simple patch that enables the usbvision driver to register the v4l2_extension module. Easy to do in other drivers that need to be extended... Cheers, Thierry -- diff -r 1a767efdb1d3 linux/drivers/media/video/usbvision/usbvision-video.c --- a/linux/drivers/media/video/usbvision/usbvision-video.c Wed Jun 27 21:08:03 2007 +0200 +++ b/linux/drivers/media/video/usbvision/usbvision-video.c Fri Jul 20 23:06:54 2007 +0200 @@ -82,6 +82,8 @@ #include <linux/kmod.h> #endif +#include "v4l2_extension.h" + #include "usbvision.h" #include "usbvision-cards.h" @@ -1755,10 +1752,12 @@ static int __devinit usbvision_register_ usbvision->nr,usbvision->vbi->minor & 0x1f); } // all done + v4l2ext_register(usbvision->vdev); return 0; err_exit: err("USBVision[%d]: video_register_device() failed", usbvision->nr); + v4l2ext_unregister(usbvision->vdev); usbvision_unregister_video(usbvision); return -1; } @@ -1840,6 +1839,7 @@ static void usbvision_release(struct usb up(&usbvision->lock); usbvision_remove_sysfs(usbvision->vdev); + v4l2ext_unregister(usbvision->vdev); usbvision_unregister_video(usbvision); if (usbvision->ctrlUrb) {

1 0

First comments about the V4L2 library specifications
by Luca Risolia 05 Jul '07

05 Jul '07

Hello, the project of the V4L2 library that you have proposed recently looks interesting, as I think it could solve some of the gaps in the V4L2 infrastructure in a reasonable and transparent way. I have looked at the specifications of the library and your comments about it. I have some concerns about the explicit mention of a lock for the device handled by the base driver when it is accessed from the extended driver. In this case, the base driver is already supposed to implement the correct locking schema for the devices it handles, no matter where they are accessed from. The extended driver should forward the system calls and give the result back without adding extra locks on those devices. This is how the original V4L2 core module works too; for instance, it's perfectly allowed to open a device twice. However, this does not mean that the extended driver cannot implement locks on the _virtual_ extended devices it handles, but these locks should not interfere with the base driver. Another minor issue at this stage of development is namespace for device entries. I think we should make clear to the users whether a given device node is related to the extend functionalities or not. A possible solution is to name the nodes with the pairs "/dev/extvideoX" and "/dev/videoX" (as opposite to "/dev/videoX" and "/dev/basevideoX"). Unfortunately, I do not have much time to actively code, but I will be keeping an eye on the development and send my comments when needed. Best regards Luca

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

V4L2-library July 2007