lkml.org 
[lkml]   [2010]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
    Laurent Pinchart wrote:
    > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote:
    >> TYPE_EXT describes entities that represent some interface to the
    >> external world, TYPE_INT those that are internal to the entire device.
    >> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems
    >> to be an even more meaningless name.)
    >
    > SUBDEV comes from the V4L2 world, and I agree that it might not be a very good
    > name.
    >
    > I'm not sure I would split entities in internal/external categories. I would
    > create a category for connectors though.

    I'm not disagreeing, but what is actually the distinction between types
    and subtypes? ;-)

    >> * Entity properties
    >>
    >> There needs to be a mechanism to associate meta-information (properties)
    >> with entities. This information should be optional and extensible, but,
    >> when being handled inside the kernel, doesn't need to be more than
    >> a read-only blob. I think that something like ALSA's TLV format (used
    >> for mixer controls) can be used here. (I'm not mentioning the X-word
    >> here, except to note that the "M" stands for "markup".)
    >
    > I've been thinking of adding a new ioctl for that. It's something we need to
    > draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers
    > would find it useful as well.

    I'm imagining a "read-the-properties" ioctl that just returns the
    entity's blob.

    >> EXT_SPEAKER also includes headphones; there might be made a case for
    >> having those as a separate subtype.
    >
    > Shouldn't headphones be represented by an EXT_JACK_ANALOG ?

    Headphone jacks are jacks; there are also USB headphones.

    >> EXT_BROADCAST represents devices like TV tuners, satellite receivers,
    >> cable tuners, or radios.
    >
    > There's clearly an overlap with V4L here.

    These come from the USB audio spec. Video devices are indeed likely to
    be more detailed than just a single audio source. :)

    >> INT_CONTROLS may have multiple independent controls (this is USB's
    >> Feature Unit); INT_EFFECT may have multiple controls that affect one
    >> single algorithm.
    >
    > I'd describe this as a feature unit/processing unit then.

    I was aiming for more descriptive names, but I agree that the original
    names might be more useful.

    > Should we have an AUDIO category ?

    Probably not, because there are combined audio/video jacks, any maybe
    other entities.

    >> * Entity specifications
    >>
    >> While TYPE_DEVICE entities can be identified by their device node, other
    >> entities typcially have just a numeric ID.
    >
    > In V4L2 sub-devices have (or rather will have once the media controller
    > patches will be integrated) device nodes as well, so exposing that information
    > is required.

    USB and HDA entities already have numeric IDs.

    >> For that, it would be useful to make do without separate identification and
    >> let the driver choose the entity ID.
    >
    > How would drivers do that ? What if you have two instances of the same chip
    > (a video sensor, audio mixer, ...) on the same board ?

    Then those would get different IDs; USB descriptors always describe the
    entire device.


    Regards,
    Clemens


    \
     
     \ /
      Last update: 2010-12-14 14:35    [W:2.486 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site