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.
|