From patchwork Fri Aug 28 09:16:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 255981 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7C67C433E6 for ; Fri, 28 Aug 2020 09:17:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 840C32086A for ; Fri, 28 Aug 2020 09:17:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598606227; bh=IBVeh1zZx2EXVnY8k4/KBmTXmlSvBkhFzMjL+yHXBoo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=onsvh3qfJqvoy+s4/c8sJtx+pCDI/9lGqSQUgyXrbhaeHR+wrdGyk7NBcI8qbMQ5D uQXvJnPOs1Qiumx5ddwuMnx8O6MFCBz3wGzHQXH/GfmbiqXA//eKLuT1Nrlu91YGNG VxGfCM2Nk6j+ugSEtoSlW86f/sx5jqJCY6IYgcUU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728825AbgH1JQ6 (ORCPT ); Fri, 28 Aug 2020 05:16:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:48540 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728444AbgH1JQy (ORCPT ); Fri, 28 Aug 2020 05:16:54 -0400 Received: from mail.kernel.org (unknown [95.90.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2EB31208FE; Fri, 28 Aug 2020 09:16:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598606213; bh=IBVeh1zZx2EXVnY8k4/KBmTXmlSvBkhFzMjL+yHXBoo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SaEHHr49V5B5ntZjzcgf9tyQrDbYvKNTQwlowVmIQAijvkRK/AJ3AH+FqENYdFt+l YtjBHDfuvvRxO297CzfX/h1Fctd+vTMrMXTVGoASQmyTX9yskbEv75/yjaGp9Q7A9k CJ3hB3exaiWWeG5mnFyn2iSjq+Id1QPxNGKQXZiI= Received: from mchehab by mail.kernel.org with local (Exim 4.94) (envelope-from ) id 1kBaV9-0047AD-8f; Fri, 28 Aug 2020 11:16:51 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Jonathan Corbet , Hans Verkuil , Sakari Ailus , linux-media@vger.kernel.org Subject: [PATCH v11 2/4] media: open.rst: remove the minor number range Date: Fri, 28 Aug 2020 11:16:48 +0200 Message-Id: X-Mailer: git-send-email 2.26.2 In-Reply-To: References: MIME-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org minor numbers use to range between 0 to 255, but that was changed a long time ago. While it still applies when CONFIG_VIDEO_FIXED_MINOR_RANGES, when the minor number is dynamically allocated, this may not be true. In any case, this is not relevant, as udev will take care of it. So, remove this useless misinformation. Acked-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/open.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/open.rst b/Documentation/userspace-api/media/v4l/open.rst index 7f1ff8a77059..4928f636c576 100644 --- a/Documentation/userspace-api/media/v4l/open.rst +++ b/Documentation/userspace-api/media/v4l/open.rst @@ -26,11 +26,10 @@ helper functions and a common application interface specified in this document. Each driver thus loaded registers one or more device nodes with major -number 81 and a minor number between 0 and 255. Minor numbers are -allocated dynamically unless the kernel is compiled with the kernel -option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers -are allocated in ranges depending on the device node type (video, radio, -etc.). +number 81. Minor numbers are allocated dynamically unless the kernel +is compiled with the kernel option CONFIG_VIDEO_FIXED_MINOR_RANGES. +In that case minor numbers are allocated in ranges depending on the +device node type. The device nodes supported by the Video4Linux subsystem are: From patchwork Fri Aug 28 09:16:49 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 255980 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF475C433E6 for ; Fri, 28 Aug 2020 09:17:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A5CEB2086A for ; Fri, 28 Aug 2020 09:17:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598606246; bh=hCRKkX8H1GiLYwiP8iInIB+ponsSmkNMZyCyyIGT9qs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=hbAuM3/F8vnFWvcZob9a1YG7fZOaNE7gfR9ra4Iqk4OS42RU2tvnyks2638sYHURg OQNI0V3bjFVr4Z66E7uyP7VM5fiTKdgW5soCQYLkU31PRZhx4puVI3yt2TBZUmayuW QDnldKKrJXU8h3XpbSCupjvZ7HNRSLfxo0sZZM68= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728548AbgH1JRL (ORCPT ); Fri, 28 Aug 2020 05:17:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:48536 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726010AbgH1JQy (ORCPT ); Fri, 28 Aug 2020 05:16:54 -0400 Received: from mail.kernel.org (unknown [95.90.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 29380208D5; Fri, 28 Aug 2020 09:16:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598606213; bh=hCRKkX8H1GiLYwiP8iInIB+ponsSmkNMZyCyyIGT9qs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q/cwwjqaMdhre6++jGtL32s+UeiqJMKI8VGpYPrPtkTbvXJ4TSj8o/1K8fKlfFrMV Jpb6EV0LSwV8v3bIa932t896QaX2KseU1f8LvxGj+yPzZI3rWa7qTAiL05gMVO1nRG UIJKC64gD76Cyti2yI8RPXoOnvaw3n4x0DrN+K38= Received: from mchehab by mail.kernel.org with local (Exim 4.94) (envelope-from ) id 1kBaV9-0047AF-9f; Fri, 28 Aug 2020 11:16:51 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Jonathan Corbet , linux-media@vger.kernel.org Subject: [PATCH v11 3/4] media: docs: add glossary.rst with common terms used at V4L2 spec Date: Fri, 28 Aug 2020 11:16:49 +0200 Message-Id: X-Mailer: git-send-email 2.26.2 In-Reply-To: References: MIME-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Add a glossary of terms used within the media userspace API documentation, as several concepts are complex enough to cause misunderstandings. Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/glossary.rst | 216 ++++++++++++++++++ Documentation/userspace-api/media/index.rst | 3 + 2 files changed, 219 insertions(+) create mode 100644 Documentation/userspace-api/media/glossary.rst diff --git a/Documentation/userspace-api/media/glossary.rst b/Documentation/userspace-api/media/glossary.rst new file mode 100644 index 000000000000..54451553311c --- /dev/null +++ b/Documentation/userspace-api/media/glossary.rst @@ -0,0 +1,216 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later + +.. For GPL-2.0, see LICENSES/preferred/GPL-2.0 +.. +.. For GFDL-1.1-or-later, see: +.. +.. Permission is granted to copy, distribute and/or modify this document +.. under the terms of the GNU Free Documentation License, Version 1.1 or +.. any later version published by the Free Software Foundation, with no +.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. +.. A copy of the license is included at +.. Documentation/userspace-api/media/fdl-appendix.rst. + +======== +Glossary +======== + +.. note:: + + The goal of this section is to standardize the terms used within the media + userspace API documentation. This is Work In Progress. + +.. Please keep the glossary entries in alphabetical order + +.. glossary:: + + Bridge Driver + A :term:`device driver` that implements the main logic to talk with + media hardware. + + CEC API + **Consumer Electronics Control API** + + An API designed to receive and transmit data via an HDMI + CEC interface. + + See :ref:`cec`. + + Device Driver + Part of the Linux Kernel that implements support for a hardware + component. + + Device Node + A character device node in the file system used to control and + transfer data in and out of a Kernel driver. + + Digital TV API + **Previously known as DVB API** + + An API designed to control a subset of the :term:`Media Hardware` + that implements digital TV (e. g. DVB, ATSC, ISDB, etc). + + See :ref:`dvbapi`. + + DSP + **Digital Signal Processor** + + A specialized :term:`Microprocessor`, with its architecture + optimized for the operational needs of digital signal processing. + + FPGA + **Field-programmable Gate Array** + + An :term:`IC` circuit designed to be configured by a customer or + a designer after manufacturing. + + See https://en.wikipedia.org/wiki/Field-programmable_gate_array. + + Hardware Component + A subset of the :term:`media hardware`. For example an :term:`I²C` or + :term:`SPI` device, or an :term:`IP block` inside an + :term:`SoC` or :term:`FPGA`. + + Hardware Peripheral + A group of :term:`hardware components ` that + together make a larger user-facing functional peripheral. For + instance, the :term:`SoC` :term:`ISP` :term:`IP block ` + and the external camera sensors together make a camera hardware + peripheral. + + Also known as :term:`peripheral`. + + I²C + **Inter-Integrated Circuit** + + A multi-master, multi-slave, packet switched, single-ended, + serial computer bus used to control some hardware components + like sub-device hardware components. + + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf. + + IC + **Integrated circuit** + + A set of electronic circuits on one small flat piece of + semiconductor material, normally silicon. + + Also known as chip. + + IP Block + **Intellectual property core** + + In electronic design a semiconductor intellectual property core, + is a reusable unit of logic, cell, or integrated circuit layout + design that is the intellectual property of one party. + IP Blocks may be licensed to another party or can be owned + and used by a single party alone. + + See https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core). + + ISP + **Image Signal Processor** + + A specialized processor that implements a set of algorithms for + processing image data. ISPs may implement algorithms for lens + shading correction, demosaicing, scaling and pixel format conversion + as well as produce statistics for the use of the control + algorithms (e.g. automatic exposure, white balance and focus). + + Media API + A set of userspace APIs used to control the media hardware. It is + composed by: + + - :term:`CEC API`; + - :term:`Digital TV API`; + - :term:`MC API`; + - :term:`RC API`; and + - :term:`V4L2 API`. + + See :doc:`index`. + + MC API + **Media Controller API** + + An API designed to expose and control the relationships between + multimedia devices and sub-devices. + + See :ref:`media_controller`. + + MC-centric + :term:`V4L2 hardware` device driver that requires :term:`MC API`. + + Such drivers have ``V4L2_CAP_IO_MC`` device_caps field set + (see :ref:`VIDIOC_QUERYCAP`). + + See :ref:`v4l2_hardware_control` for more details. + + Media Hardware + Subset of the hardware that is supported by the Linux Media API. + + This includes audio and video capture and playback hardware, + digital and analog TV, camera sensors, ISPs, remote controllers, + codecs, HDMI Consumer Electronics Control, HDMI capture, etc. + + Microprocessor + Electronic circuitry that carries out the instructions of a + computer program by performing the basic arithmetic, logical, + control and input/output (I/O) operations specified by the + instructions on a single integrated circuit. + + Peripheral + The same as :term:`hardware peripheral`. + + RC API + **Remote Controller API** + + An API designed to receive and transmit data from remote + controllers. + + See :ref:`remote_controllers`. + + SMBus + A subset of I²C, which defines a stricter usage of the bus. + + SPI + **Serial Peripheral Interface Bus** + + Synchronous serial communication interface specification used for + short distance communication, primarily in embedded systems. + + SoC + **System on a Chip** + + An integrated circuit that integrates all components of a computer + or other electronic systems. + + V4L2 API + **V4L2 userspace API** + + The userspace API defined in :ref:`v4l2spec`, which is used to + control a V4L2 hardware. + + V4L2 Device Node + A :term:`device node` that is associated to a V4L driver. + + The V4L2 device node naming is specified at :ref:`v4l2_device_naming`. + + V4L2 Hardware + Part of the media hardware which is supported by the :term:`V4L2 API`. + + V4L2 Sub-device + V4L2 hardware components that aren't controlled by a + :term:`bridge driver`. See :ref:`subdev`. + + Video-node-centric + V4L2 device driver that doesn't require a media controller to be used. + + Such drivers have the ``V4L2_CAP_IO_MC`` device_caps field unset + (see :ref:`VIDIOC_QUERYCAP`). + + V4L2 Sub-device API + Part of the :term:`V4L2 API` which control + :term:`V4L2 sub-devices `, like sensors, + HDMI receivers, scalers, deinterlacers. + + See :ref:`v4l2_hardware_control` for more details. diff --git a/Documentation/userspace-api/media/index.rst b/Documentation/userspace-api/media/index.rst index 70a3f3d73698..7f42f83b9f59 100644 --- a/Documentation/userspace-api/media/index.rst +++ b/Documentation/userspace-api/media/index.rst @@ -35,6 +35,9 @@ Please see: mediactl/media-controller cec/cec-api gen-errors + + glossary + fdl-appendix drivers/index From patchwork Fri Aug 28 09:16:50 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 255979 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, INCLUDES_PATCH, MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0728C433E2 for ; Fri, 28 Aug 2020 09:17:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7B1D420C56 for ; Fri, 28 Aug 2020 09:17:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598606253; bh=qf3s74BFMfzPaXEhkWfFmaoIcsmrt/xu5Ve7JjjrqSI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=1UXaTzQW1ywc7A6XDafYJ5+E6XuMqt95lFJgY9RixG7YwFZjJ5T3abJApTY69nFV4 FZABzy/gDC9veVRIvXF/hiG5afFs+mOkUtZKzv0nk5E4Hj0l/f63IV1cscau7fBYd/ n9iggmyXa0GflO+4+cV+/o91tUTQiXDwbxTxAkws= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728912AbgH1JRK (ORCPT ); Fri, 28 Aug 2020 05:17:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:48546 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728548AbgH1JQy (ORCPT ); Fri, 28 Aug 2020 05:16:54 -0400 Received: from mail.kernel.org (unknown [95.90.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3D68520C56; Fri, 28 Aug 2020 09:16:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598606213; bh=qf3s74BFMfzPaXEhkWfFmaoIcsmrt/xu5Ve7JjjrqSI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o/uh8mxaO6aCUHIiw2fwZiZV736BMezCvVZ65ayjQd+uNMxyLAfU1Wnnke7NimkcA JQwQYJ0gDv34xBMFZlJvL3TtZzLXKFS3l0DYmV2BPolWYsMIfobj6knnDaF602uTJS eMwJpIuapVR7lg5zsX0f3IVpajA3zGxemaSiEKvM= Received: from mchehab by mail.kernel.org with local (Exim 4.94) (envelope-from ) id 1kBaV9-0047AH-Ap; Fri, 28 Aug 2020 11:16:51 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Jonathan Corbet , Hans Verkuil , Sakari Ailus , linux-media@vger.kernel.org Subject: [PATCH v11 4/4] media: open.rst: document mc-centric and video-node-centric Date: Fri, 28 Aug 2020 11:16:50 +0200 Message-Id: <99929cf3d951ff9dbe0e70e9380dfb2c13408869.1598606093.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: References: MIME-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org When we added support for omap3, back in 2010, we added a new type of V4L2 devices that aren't fully controlled via the V4L2 device node. Yet, we have never clearly documented in the V4L2 specification the differences between the two types. Let's document them based on the the current implementation. Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/open.rst | 59 +++++++++++++++++-- 1 file changed, 53 insertions(+), 6 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/open.rst b/Documentation/userspace-api/media/v4l/open.rst index 4928f636c576..d20f98969294 100644 --- a/Documentation/userspace-api/media/v4l/open.rst +++ b/Documentation/userspace-api/media/v4l/open.rst @@ -13,6 +13,53 @@ Opening and Closing Devices *************************** +.. _v4l2_hardware_control: + +Controlling a hardware peripheral via V4L2 +========================================== + +Hardware that is supported using the V4L2 uAPI often consists of multiple +devices or peripherals, each of which have their own driver. + +The bridge driver exposes one or more V4L2 device nodes +(see :ref:`v4l2_device_naming`). + +There are other drivers providing support for other components of +the hardware, which may also expose device nodes, called V4L2 sub-devices. + +When such V4L2 sub-devices are exposed, they allow controlling those +other hardware components - usually connected via a serial bus (like +I²C, SMBus or SPI). Depending on the bridge driver, those sub-devices +can be controlled indirectly via the bridge driver or explicitly via +the :ref:`Media Controller ` and via the +:ref:`V4L2 sub-devices `. + +The devices that require the use of the +:ref:`Media Controller ` are called **MC-centric** +devices. The devices that are fully controlled via V4L2 device nodes +are called **video-node-centric**. + +Userspace can check if a V4L2 hardware peripheral is MC-centric by +calling :ref:`VIDIOC_QUERYCAP` and checking the +:ref:`device_caps field `. + +If the device returns ``V4L2_CAP_IO_MC`` flag at ``device_caps``, +then it is MC-centric, otherwise, it is video-node-centric. + +It is required for MC-centric drivers to identify the V4L2 +sub-devices and to configure the pipelines via the +:ref:`media controller API ` before using the peripheral. +Also, the sub-devices' configuration shall be controlled via the +:ref:`sub-device API `. + +.. note:: + + A video-node-centric may still provide media-controller and + sub-device interfaces as well. + + However, in that case the media-controller and the sub-device + interfaces are read-only and just provide information about the + device. The actual configuration is done via the video nodes. .. _v4l2_device_naming: @@ -109,7 +156,7 @@ Related Devices Devices can support several functions. For example video capturing, VBI capturing and radio support. -The V4L2 API creates different nodes for each of these functions. +The V4L2 API creates different V4L2 device nodes for each of these functions. The V4L2 API was designed with the idea that one device node could support all functions. However, in practice this never worked: this @@ -119,17 +166,17 @@ switching a device node between different functions only works when using the streaming I/O API, not with the :ref:`read() `/\ :ref:`write() ` API. -Today each device node supports just one function. +Today each V4L2 device node supports just one function. Besides video input or output the hardware may also support audio sampling or playback. If so, these functions are implemented as ALSA PCM devices with optional ALSA audio mixer devices. One problem with all these devices is that the V4L2 API makes no -provisions to find these related devices. Some really complex devices -use the Media Controller (see :ref:`media_controller`) which can be -used for this purpose. But most drivers do not use it, and while some -code exists that uses sysfs to discover related devices (see +provisions to find these related V4L2 device nodes. Some really complex +hardware use the Media Controller (see :ref:`media_controller`) which can +be used for this purpose. But several drivers do not use it, and while some +code exists that uses sysfs to discover related V4L2 device nodes (see libmedia_dev in the `v4l-utils `__ git repository), there is no library yet that can provide a single API