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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
- Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
