V4L2-library

v4l2-library@linuxtv.org

81 discussions

Alternative idea: make a library
by Thierry Merle 26 Jun '08

26 Jun '08

Hi all, Hans de Goede had the great idea to make something like we can find for arts, a library that traps open/close/ioctl and mmap calls, see his last message about it: http://marc.info/?l=linux-video&m=121296318123763&w=2 The idea is simple: - it works without modification of the application. The library traps the standard system calls to see if the application accesses a v4l device, intercepts compressed frames coming from the driver and uncompresses in userspace before transmitting them to the application. - it works without modification of the v4l driver. All the conversion job is masked by the library. You call the application using: LD_PRELOAD=v4l1-compat.so camorama for example. The code is working and can be adapted to any device that need some userspace frame decompression/conversion. The only disadvantage I saw is that an application that already uses the LD_PRELOAD mechanism for trapping these syscalls, this library will trap again these syscalls but in this case, it should link with a part of this library. Currently, this library does v4l2 driver to v4l1 application translation but the idea is here. I don't know if you share my point of view but this idea is simple and has a long-term existence as opposed as the initial one. Cheers, Thierry

3 11

[PATCH] v4l2_extension: fix the udev rule
by Thierry Merle 28 Mar '08

28 Mar '08

The helper daemon was no more loaded since the udev rule was not correct: Load the v4l2ext_helper daemon when the v4l2_extension kernel module loads, using udev. Signed-off-by: Thierry MERLE <thierry.merle(a)free.fr> --- 99-v4l2ext.rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -r 33d129e72857 -r 17c59c1e3e68 v4l2-apps/v4l2ext_helper/99-v4l2ext.rules --- a/v4l2-apps/v4l2ext_helper/99-v4l2ext.rules Fri Mar 28 21:44:02 2008 +0100 +++ b/v4l2-apps/v4l2ext_helper/99-v4l2ext.rules Fri Mar 28 22:35:16 2008 +0100 @@ -1,1 +1,1 @@ SUBSYSTEM=="v4l2_extension", ACTION=="ad -SUBSYSTEM=="v4l2_extension", ACTION=="add", RUN+="/usr/sbin/v4l2ext_helper" +KERNEL=="v4l2_extension", ACTION=="add", RUN+="/usr/sbin/v4l2ext_helper"

1 0

[PATCH] v4l2_extension: fix helperd_dev structure initialization
by Thierry Merle 28 Mar '08

28 Mar '08

Hello all, just a fix of the v4l2_extension driver: fix list and waitqueue initializations in order to avoid a NULL pointer reference when calling v4l2ext_hlp_send_cmd Thanks to Jiri for helping me to find the bug! Cheers, Thierry Signed-off-by: Thierry MERLE <thierry.merle(a)free.fr> --- v4l2_extension-hlp.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/linux/drivers/media/video/v4l2_extension/v4l2_extension-hlp.c Mon Mar 17 22:28:17 2008 +0100 +++ b/linux/drivers/media/video/v4l2_extension/v4l2_extension-hlp.c Fri Mar 28 21:44:02 2008 +0100 @@ -253,6 +253,10 @@ int v4l2ext_hlp_send_cmd(struct v4l2ext_ int v4l2ext_hlp_init(void) { + INIT_LIST_HEAD(&helperd_dev.commands); + INIT_LIST_HEAD(&helperd_dev.pcommands); + init_waitqueue_head(&helperd_dev.waitqueue); + return misc_register(&misc_device); }

1 0

[RFC] New V4L2 picture format
by Thierry Merle 18 Mar '08

18 Mar '08

Hello all, in order to decode compressed frames in userspace, we need to create a new picture format. The base driver would declare this pixel format when calling VIDIOC_ENUM_FMT in order to pass raw frames to the helper daemon. What about: #define V4L2_PIX_FMT_V4L2 v4l2_fourcc('V','4','L','2') Other FOURCC formats that already defined: http://wiki.multimedia.cx/index.php?title=Category:Video_FourCCs Please comment! Cheers, Thierry

2 1

Re: [V4l2-library] [RFC 1/1] v4l2_extension: helper daemon commands passing
by Thierry MERLE 11 Mar '08

11 Mar '08

Hi Laurent Le jeudi 06 mars 2008 à 23:30 +0100, Laurent Pinchart a écrit : > Hi Thierry, > > On Thursday 06 March 2008, Thierry Merle wrote: > > Laurent Pinchart a écrit : > > > On Monday 03 March 2008, Thierry Merle wrote: > > >> Jiri Slaby a écrit : > > >>> Here I would like to know if the the commands passing interface to the > > >>> helper daemon introduced in this patch is OK, or alternatively propose > > >>> some other idea ;). > > >> > > >> I have committed your patch as is > > >> http://linuxtv.org/hg/~tmerle/v4l2_extension/ > > >> Now will begin a driver enhancement. I will do that on usbvision because > > >> I know it. > > >> The first step will be to extend the supported video formats (2 > > >> sub-steps: 1-just enable hardware pixel format capabilities in > > >> usbvision, 2-allow the helper daemon to extend usbvision pixel format > > >> capabilities). > > > > > > I haven't followed v4l2_extension development closely, so I'm a bit > > > puzzled by this. Are the modifications you made to the usbvision module > > > for testing purpose only ? My understanding of v4l2_extension is that it > > > should work completely transparently and must not require any change to > > > v4l2 drivers. > > > > In fact I meant remove from usbvision the software decompression > > algorithm in order to put it in the helper daemon. > > I will restrict the list of supported pixel formats to the ones that the > > hardware can output without software decompression. > > That's the whole point of having userspace decompression. Those changes are > perfectly ok. > > > I hope that the sole modification for a standard base driver will be the > > add of v4l2ext_register/v4l2ext_unregister calls. > > I'm not very happy with that. Couldn't this be done automatically at the > videodev level ? As "v4l2ext" is a temporary solution, I'd hate seeing all > drivers being modified. This should be transparent to the driver itself, > otherwise we will have to modify them back again when v4l2ext will be > replaced by a real userspace library. > I will try to do that, in a second time; I do not see any blocking point, the v4l2ext_register can be done in video_register_device, for VFL_TYPE_GRABBER. Priority #1 is to uncompress a frame in userspace (I have a cruel lack of time these days). But rebemember that the base driver should be ioctl-v4l2 compliant, since each ioctl is hooked in order to call the helper daemon. There will be some effort to do for old webcam drivers. > Cheers, > > Laurent Pinchart > I hope I will be able to post to the right list at least one time :) Cheers, Thierry

1 0

Re: [V4l2-library] [again] v4l2_extension and helper daemon?
by Jiri Slaby 06 Mar '08

06 Mar '08

On 03/05/2008 10:39 PM, Thomas Kaiser wrote: > Jiri Slaby wrote: >> On 03/05/2008 10:24 PM, Thomas Kaiser wrote: >>> Hello Thierry >>> >>> I just looked at the last graf on >>> http://www.linuxtv.org/v4lwiki/index.php/V4L2UserspaceLibrary and I >>> think I don't find point 4 (prepare data for the v4l2 helper) in the >>> code.... >> >> Sorry, we are too slow with development, please be patient, however we >> finally moved forward in past few days. Thanks. > > Thanks for your answer! > Does this help me? > > I don't care how your development is going! I just asked a question. No, you didn't. > The answer should be "this is not implement, yet, but It's supposed to > work like ...., if you have time to do it, just do it! We are open for > volunteers" or something similar. We are open for volunteers! Well, you are in opensource world, volunteers are ever welcome, you don't need to ask.

2 6

[again] v4l2_extension and helper daemon?
by Thomas Kaiser 05 Mar '08

05 Mar '08

Hello Thierry I just looked at the last graf on http://www.linuxtv.org/v4lwiki/index.php/V4L2UserspaceLibrary and I think I don't find point 4 (prepare data for the v4l2 helper) in the code.... Regards, Thomas -- http://www.kaiser-linux.li

2 3

v4l2_extension and helper daemon?
by Thomas Kaiser 05 Mar '08

05 Mar '08

Hello Thierry I did extend my webcam driver to talk to the v4l2_extension module. Now, I can get the stream from my webcam through /dev/video1 (that one from v4l2_extension). How can I get the stream to the v4l2ext_helper daemon? When I start v4l2ext_helper the last call to v4l2ext_helper is v4l2ext_hlp_poll(). I think it is waiting for poll_wait to return? What should be the result of poll_wait after its return? "mask" will be zero, still. Any pointers, please. Thomas -- http://www.kaiser-linux.li

1 0

[Fwd: Re: [RFC 1/1] v4l2_extension: helper daemon commands passing]
by Thierry Merle 03 Mar '08

03 Mar '08

Argh, still confusing mailing-lists...

1 0

Re: [V4l2-library] [RFC 1/1] v4l2_extension: helper daemon commands passing
by Jiri Slaby 25 Feb '08

25 Feb '08

On 02/22/2008 09:25 PM, Thierry Merle wrote: > Jiri Slaby a écrit : >> Here I would like to know if the the commands passing interface to the >> helper daemon introduced in this patch is OK, or alternatively propose >> some other idea ;). >> > It is a good starting point. > All ioctls will be processed in the helper daemon via the process_ioctl > command. > read/write processings make less context switchings than ioctls. > Further, mmap will be required to pass the compressed/uncompressed frames. > > The point to think about is how to identify the base driver when we > reach the process_ioctl function. > The helper daemon must behave in a specific way for each base driver to > extend. I was thinking about yet another thing. Maybe the driver should pass to the ext layer, which conversions should be done. I mean for example vert./horiz. flip, image rotation, which has nothing to do with V4l, but some cameras might want this (stk11xx is good/bad example ;)). In this case no matter of chosen format, every frame must go through the daemon to process the conversion. So I was also thinking about passing to the ext layer in which (non-v4l = upside-down) formats the driver can emit frames (or layer can ask through v4l ioctl callbacks). Or just letting this on the base driver? > I see 2 solutions: > - identify the base driver at each request between the extended driver > and the helper daemon, > - instanciate a helper daemon for each base driver (that means > concurrent accesses to /dev/v4l2_extension) But how to distinguish the application accessing the node then? > Identify the base driver means the helper daemon must know its > capabilities, not only its name. Yes. But it must in any way, needn't it? (To not return yet enumered formats for example.) I don't know, both have their pros and cons.

2 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

V4L2-library