lkml.org 
[lkml]   [2007]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-31 22:43    [W:4.253 / U:0.584 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site