34 lines
1.4 KiB
ReStructuredText
34 lines
1.4 KiB
ReStructuredText
.. -*- coding: utf-8; mode: rst -*-
|
|
|
|
.. _media-controller-intro:
|
|
|
|
Introduction
|
|
============
|
|
|
|
Media devices increasingly handle multiple related functions. Many USB
|
|
cameras include microphones, video capture hardware can also output
|
|
video, or SoC camera interfaces also perform memory-to-memory operations
|
|
similar to video codecs.
|
|
|
|
Independent functions, even when implemented in the same hardware, can
|
|
be modelled as separate devices. A USB camera with a microphone will be
|
|
presented to userspace applications as V4L2 and ALSA capture devices.
|
|
The devices' relationships (when using a webcam, end-users shouldn't
|
|
have to manually select the associated USB microphone), while not made
|
|
available directly to applications by the drivers, can usually be
|
|
retrieved from sysfs.
|
|
|
|
With more and more advanced SoC devices being introduced, the current
|
|
approach will not scale. Device topologies are getting increasingly
|
|
complex and can't always be represented by a tree structure. Hardware
|
|
blocks are shared between different functions, creating dependencies
|
|
between seemingly unrelated devices.
|
|
|
|
Kernel abstraction APIs such as V4L2 and ALSA provide means for
|
|
applications to access hardware parameters. As newer hardware expose an
|
|
increasingly high number of those parameters, drivers need to guess what
|
|
applications really require based on limited information, thereby
|
|
implementing policies that belong to userspace.
|
|
|
|
The media controller API aims at solving those problems.
|