On Thu, Nov 25, 2010 at 04:21:38PM +0100, Laurent Pinchart wrote: > On Thursday 25 November 2010 10:38:05 Clemens Ladisch wrote: > > ALSA has PCM and MIDI devices, and several types of mixer controls. > > (It also has hardware dependent and timer devices, but I don't think > > these would need topology information.) So we need at least these: > > MEDIA_ENTITY_TYPE_NODE_ALSA_PCM > > MEDIA_ENTITY_TYPE_NODE_ALSA_MIDI > > MEDIA_ENTITY_TYPE_SUBDEV_ALSA_CONTROL > I agree about PCM and MIDI, but I'm not sure about controls. If controls are > part of an entity, the entity will be reported through the media controller > API. If information about that entity can be queried through existing APIs > (ALSA, V4L, ...) those APIs should be used. For instance, on the V4L side, > V4L2 sub-devices are mapped to entities and also have a device node which can > be used to enumerate the controls supported by the subdev. The media > controller only reports the entity -> major:minor mapping to let applications > find the device and query it directly. For audio we don't currently have a sensible API for associating controls with any sort of map of how the device is laid out, userspace has to play guessing games. > I think we will need a new ioctl in the media controller API to report > advanced information about an entity. This could be used to report controls > implemented by an ALSA element if ALSA doesn't provide a way to do that > directly. Another use case, which make me think that such an ioctl would be > needed, is to report UVC extension units type (16-byte GUID) to userspace. That seems reasonable. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
