Message-ID: <465F3361.106@free.fr>
Date:	Thu, 31 May 2007 22:43:13 +0200
From:	Thierry Merle <thierry.merle@...e.fr>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
CC:	video4linux-list@...hat.com, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver



Mauro Carvalho Chehab a écrit :
> Em Ter, 2007-05-29 às 21:04 +0200, Thierry Merle escreveu:
>   
>> Mauro Carvalho Chehab a écrit :
>>     
>>>   
>>>   
>>>       
>>>>> Hi Mauro and Markus,
>>>>> Just to summ up what I understood we need:
>>>>>
>>>>> What do we need in userspace, only for v4l (dvb is not concerned):
>>>>> - colorspace translations
>>>>> - filters that be done in hardware if the selected hardware can, 
>>>>> otherwise software plugin
>>>>> - decompression algorithm like stk11xx or usbvision (the decompression 
>>>>> algorithm is in kernelspace since it is of linear complexity but shall 
>>>>> be moved to userspace)
>>>>>       
>>>>>           
>>> Yes. The first focus, IMO, should be the last one.
>>>
>>>   
>>>       
>> OK, so we must open the V4L2 API to add a custom pixel format.
>>     
> I don't think we need to change the API. The API already exports the
> format, as a fourcc-like info. We just need to add newer codes as
> they'll be added into kernel.
>
>   
>> While brainstorming, I thought it would be funny to create userspace 
>> drivers like FUSE based projects do.
>> Applications would see nothing but a new device driver to access, all 
>> decompression algorithm would be in userspace.
>> The path from the application to the v4l2 kernel driver:
>> [Application]<->[/mnt/video0 (created by FUSE-like userspace 
>> lib)]<->[/dev/video0 (created by kernel v4l2 driver)]
>> There are limitations that I don't know, but this would be transparent 
>> for the applications.
>>     
>
> This seems to be an interesting approach.
>
>   
Interesting but impossible to do for ioctl calls.
When the application does a ioctl(fd_of_mnt_video0,VIDIOC_G_FMT,&arg) 
for example, there is no way for the userspace helper to catch this ioctl.
The application could only open/read from the userspace helper's file 
/mnt/video0.
ioctl would still have to be done on the kernel device driver.
I thought also about a /proc interface for decompression algorithms (a 
helper would listen on a /proc file and write on another /proc file) but 
/proc is not designed for that kind of thing.
A separate library seems to be the simplest solution.
>>> Yes, it is possible. In fact, some devices currently work by generating
>>> a common audio and video stream. The driver may just send the packet
>>> as-is, leaving to the userspace API the function to de-merge and
>>> synchronize audio and video.
>>>   
>>>       
>> So we have a userspace lib that will demux/uncompress device driver output.
>> This lib will know each device driver particularities to know how to 
>> demux/uncompress in a a/v format that will be understood by the application.
>>     
>
> Yes. However, we should try to do loose coupling whenever possible, to
> keep maintainership of the "library"(*) as simple as possible.
>
> (*) With this approach, it seems that it will turn into a helper daemon,
> instead of just a library.
>
> Cheers,
> Mauro
>
>   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists