1.. Permission is granted to copy, distribute and/or modify this 2.. document under the terms of the GNU Free Documentation License, 3.. Version 1.1 or any later version published by the Free Software 4.. Foundation, with no Invariant Sections, no Front-Cover Texts 5.. and no Back-Cover Texts. A copy of the license is included at 6.. Documentation/userspace-api/media/fdl-appendix.rst. 7.. 8.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections 9 10.. _media-controller-intro: 11 12Introduction 13============ 14 15Media devices increasingly handle multiple related functions. Many USB 16cameras include microphones, video capture hardware can also output 17video, or SoC camera interfaces also perform memory-to-memory operations 18similar to video codecs. 19 20Independent functions, even when implemented in the same hardware, can 21be modelled as separate devices. A USB camera with a microphone will be 22presented to userspace applications as V4L2 and ALSA capture devices. 23The devices' relationships (when using a webcam, end-users shouldn't 24have to manually select the associated USB microphone), while not made 25available directly to applications by the drivers, can usually be 26retrieved from sysfs. 27 28With more and more advanced SoC devices being introduced, the current 29approach will not scale. Device topologies are getting increasingly 30complex and can't always be represented by a tree structure. Hardware 31blocks are shared between different functions, creating dependencies 32between seemingly unrelated devices. 33 34Kernel abstraction APIs such as V4L2 and ALSA provide means for 35applications to access hardware parameters. As newer hardware expose an 36increasingly high number of those parameters, drivers need to guess what 37applications really require based on limited information, thereby 38implementing policies that belong to userspace. 39 40The media controller API aims at solving those problems. 41