[lkml]   [2001]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [V4L] Re: [RFC] alternative kernel multimedia API

    On 26 Oct 2001, Gerd Knorr wrote:

    > > > I would like to see a detailed explanation of how the capabilities
    > > > differ from those of v4l2.
    > >
    > > The major difference is in increased flexibility and stability of
    > > kernel-user space interface.
    > >
    > > On the application side:
    > > * ability to utilize advanced driver features without explicit
    > > knowledge of their behaviour
    > > * wider compatibility without the need for recompile
    > what exactly is bad with the v4l2 controls?

    a) no way to use them to set non-integer data (like gamma tables)
    b) labels are limited to 32 chars, no way to provide "comment" fields.
    (I would like the driver to provide a short label and longer,
    user-readable and understable comment field).
    c) no way to present control dependencies.
    For example in ATI cards there are several ways you can control gamma:
    gamma table, gamma overlay setting, gamma setting in the decoder chip.
    same goes for brightness. I would rather expose all the controls and
    show their relationship then bundle them up in one control
    (as to why this is relevant to kernel and not only Xv see below)

    > > On the kernel side:
    > > * elimination of interfaced specific headers
    > Ok, you replace the '#define V4L2_CID_HUE 0x???' with the magic string
    > "HUE" then. The point is?

    ioctl are kernel specific. My scheme proposes a set of mmaped buffers and
    character stream. The plus is that I can make Xmultimedia extension that
    also presents a set of shared buffers and character stream. The
    application code will be exactly the same.

    Additionally nonone will need to include kernel headers to compile the
    application. Also magic string HUE is a bigger namespace then an
    integer number.

    > > On the driver side:
    > > * be compatible with a wide range of applications
    > ???
    > Sorry, but I don't see why your approach handles this better than v4l2.

    Since the application accesses the driver symbolically they only have to
    worry about agreeing on semantics. For example the driver can layout its
    control structs any way it likes (say, to mirror hardware registers) and
    the application will bind to them.

    Also, mmaped buffers + character device fits a larger category then just
    the devices mentioned in v4l2 specifications. Granted the specification
    can be extended, but the new driver will have to distribute not only its
    source but a patch to the kernel headers. The scheme will avoid this.

    > > * introduce support for new features without the need to modify
    > > kernel interfaces
    > Hmm. I don't like the idea to add new stuff that easily. People tend
    > to do quick&dirty hacks + crazy stuff with it, leading to more
    > incompatibilies between drivers and applications.

    And people will always be able to write a driver outside video4linux
    framework. In fact, plenty of drivers and applications are incompatible as
    is. The same is true about audio drivers.

    The compatibility is achived best by specifications that are clear and
    easy to implement. This proposal helps it by providing a well defined
    interface and by separating semantic meaning from actual interface.
    First the internal kernel library will insure that the control interface
    is standard across drivers. Secondly, the drivers are free to use whatever
    fields they want - no restriction their. Thirdly, the way the applications
    know they deal, say, with a grabber device is when the driver says it
    supports a certain INTERFACE_CLASS. Hence, to make sure the drivers
    behave, all we have to do is bar any driver which declares itself
    compliant with a certain INTERFACE_CLASS but isn't from entering the
    kernel. And the added advantage is that we can have many INTERFACE_CLASSes
    which vary in implementation difficulty, so that BASIC_GRABBER-YUV422
    would be very easy to implement (just expose the buffers) and something
    more advanced could be added later. This solves the conflict of people
    wanting to have _some_ driver and the time consumption of writing a driver
    that supports all features.

    > > The last point is the very important in my opinion. For example, in
    > > current specification, v4l2 has no support for TV-out in graphics cards.
    > > It has no support for setting complex parameters like gamma tables.
    > > Using memory-mapped buffers requires device specific ioctls.
    > Which device specific ioctls? They are common for _all_ v4l2 devices.

    Quote from :

    A common use for memory-mapped buffers is for streaming data to and from
    drivers with minimum overhead. Drivers will maintain internal queues of
    buffers and process them asynchonously. The ioctl commands for doing that
    are described in the device-specific documents. Memory-mapping can also be
    used for a variety of other purposes. Drivers can define hardware-specific
    memory buffer types if needed. Use V4L2_BUF_TYPE_PRIVATE_BASE and greater
    values for such buffer types.

    > > The goal is to create an interface that does not rely on structures
    > > defined in kernel headers for communication.
    > Why do you want to do that?

    * not elegant
    * kernel structures force a specific model onto a driver
    * can cause problems with different compilers
    * confuse applications when a driver does not implement a field

    Here is another way one may arrive at this kind of interface:

    Consider capability flags. Wouldn't it be nice to have the driver present
    them symbolically instead of bits ? Besides everything else you get around
    the issue of running out of bits when adding new ones.

    So you can query device and get a string of the form:


    However, this is hard to implement with ioctl's as they rely on fixed
    length structures. You would have to call first to find out the size of
    the buffer you need (which the driver would have to compute) and then the
    second time to get the data. Eeeks. Instead just make a device and let the
    application do something like:

    write: ?QUERY_CAPABILITY\n

    Much better, ha ? Now if you agree that this is nice we can use the same
    scheme for other things. For example the whole control (i.e. hue,
    etc) query can be done thru this device. No need for structs. Same goes
    for width,height,picture format etc.

    Now what is left are the structs describing the format of memory buffers.
    But the driver typically has this info in a struct itself. Instead of
    getting it via ioctl simply mmap the area - you'll be getting the exact
    same information yourself with less context switches.

    This gets rid of the structs.

    What is left of v4l now are synchronization ioctls. But we can replace
    them with read/writes on the control device. With the added benifit that
    we can select on it to wait for an event.

    Vladimir Dergachev

    > Gerd
    > --
    > Netscape is unable to locate the server localhost:8000.
    > Please check the server name and try again.
    > _______________________________________________
    > Video4linux-list mailing list

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:11    [W:0.031 / U:4.488 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site