Patch Detail
Show a patch.
GET /api/patches/18767/?format=api
{ "id": 18767, "url": "https://patchwork.libcamera.org/api/patches/18767/?format=api", "web_url": "https://patchwork.libcamera.org/patch/18767/", "project": { "id": 1, "url": "https://patchwork.libcamera.org/api/projects/1/?format=api", "name": "libcamera", "link_name": "libcamera", "list_id": "libcamera_core", "list_email": "libcamera-devel@lists.libcamera.org", "web_url": "", "scm_url": "", "webscm_url": "" }, "msgid": "<20230629144915.597188-2-Alexander.Gordeev@opensynergy.com>", "date": "2023-06-29T14:49:15", "name": "[libcamera-devel,RFC,v8,1/1] virtio-video: Add virtio video device specification", "commit_ref": null, "pull_url": null, "state": "not-applicable", "archived": false, "hash": "bc92a0b82508185a770e01a472c5b544ee2f77af", "submitter": { "id": 167, "url": "https://patchwork.libcamera.org/api/people/167/?format=api", "name": "Alexander Gordeev", "email": "Alexander.Gordeev@opensynergy.com" }, "delegate": null, "mbox": "https://patchwork.libcamera.org/patch/18767/mbox/", "series": [ { "id": 3944, "url": "https://patchwork.libcamera.org/api/series/3944/?format=api", "web_url": "https://patchwork.libcamera.org/project/libcamera/list/?series=3944", "date": "2023-06-29T14:49:15", "name": "Virtio video device specification", "version": 8, "mbox": "https://patchwork.libcamera.org/series/3944/mbox/" } ], "comments": "https://patchwork.libcamera.org/api/patches/18767/comments/", "check": "pending", "checks": "https://patchwork.libcamera.org/api/patches/18767/checks/", "tags": {}, "headers": { "Return-Path": "<libcamera-devel-bounces@lists.libcamera.org>", "X-Original-To": "parsemail@patchwork.libcamera.org", "Delivered-To": "parsemail@patchwork.libcamera.org", "Received": [ "from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 4DEDEBDB1D\n\tfor <parsemail@patchwork.libcamera.org>;\n\tThu, 29 Jun 2023 15:08:06 +0000 (UTC)", "from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id A70C061E3A;\n\tThu, 29 Jun 2023 17:08:05 +0200 (CEST)", "from repost01.tmes.trendmicro.eu (repost01.tmes.trendmicro.eu\n\t[18.185.115.121])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id F109160386\n\tfor <libcamera-devel@lists.libcamera.org>;\n\tThu, 29 Jun 2023 16:49:47 +0200 (CEST)", "from 104.47.7.175_.trendmicro.com (unknown [172.21.201.179])\n\tby repost01.tmes.trendmicro.eu (Postfix) with SMTP id 8BAF410000E14; \n\tThu, 29 Jun 2023 14:49:47 +0000 (UTC)", "from DEU01-BE0-obe.outbound.protection.outlook.com (unknown\n\t[104.47.7.175])\n\tby repre01.tmes.trendmicro.eu (Trend Micro Email Security) with\n\tESMTPS id 4593510004D80; Thu, 29 Jun 2023 14:49:46 +0000 (UTC)" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1688051285;\n\tbh=D7Rk5CPHC6SCtmLGjQeTQ0rUx65h3IJv6uG5Wzg72JM=;\n\th=To:Date:In-Reply-To:References:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=IdopSoRkI1pd2Nbs6IXmkMDq6jpxveP56cJKhI2+vjTNgQIjgkgbKp65DGMRnmQze\n\tuTd5CjsQSxZV9ytB7x0iP1OfagkO5Qv3NQvwpTsJnNItCHS17b68gx5vk0vdW5pkm5\n\tNzQzPsUdmxNzHJXf/VmXOKQq4XYwTNc+3j5+tOFZQ7kDgXgBpDeNsoc8KUF0FCjeL0\n\tBnkosysaoQTuqwph+i+86iWaEqZ7R+Cmm0exPBYJVE3kvq4rnqUuN9Xd57gtvHbMoG\n\tud1qN/jOm1qbk9YS1eESd/84m/FAB+u17Orlvr1htiZEry4NIID2oe3dhgTii50cJr\n\tuica7sbCVjEjw==", "v=1; a=rsa-sha256; c=simple/simple; d=opensynergy.com;\n\ts=TM-DKIM-20210503141657; t=1688050187;\n\tbh=D7Rk5CPHC6SCtmLGjQeTQ0rUx65h3IJv6uG5Wzg72JM=; l=98722;\n\th=From:To:Date;\n\tb=vjKA2nZseqXdae8d91MTGb2AbE8OtHD8lYuIiaO2/lTeYIltUg2sazFtVVqwmJpvV\n\t/bluHy1tOu2PjkCqTMG4c3wQlNs4j1jMszkgTggGaOSTVtCVOjfMBh408iTdtS7DtE\n\ttZWiKQRbCMQ2/mjrTsuintipx45WtA9IWCOUMrCVDp/REmHA3NyL/OVdCgWd5ocxFo\n\ttJ15Yn8pmKpxi0C2/0FE8aM6uH014ShmnVNC84RdmEuLIEoA26MhADYlJYATnyNQUZ\n\trdrqUGazwDIh3B+Ti0ltJiXluIXh1OrIA6n6Y9QDW6dwH6mjkjnuKe9T59NNRm3zg4\n\tb9XSbc0bd1Uyw==" ], "Authentication-Results": "lancelot.ideasonboard.com; dkim=pass (2048-bit key; \n\tunprotected) header.d=opensynergy.com\n\theader.i=@opensynergy.com\n\theader.b=\"vjKA2nZs\"; dkim-atps=neutral", "X-TM-MAIL-RECEIVED-TIME": "1688050186.284000", "X-TM-MAIL-UUID": "67ba779a-7ef0-4973-ab45-034f566b2728", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n\tb=kIO/vaBj7K8S1eGsr8D0zEuznmiaAUAClkp8d87f2LqZjMkZE1gjMTfyGlmuE2+HdDq196VFBPj/esrmMTlZKp3o+1wEf3YinBqxsBRJ7+gKqix2ho7QzlAU0lj93p++l8SwX6loiO7Re61B/3+Snw0bmKnQTVPKdTYKSVRHjZV+xMmtq/yR2LdwxEAANF59HDoYHUZ7Ar5gS61Hugmd8mudCEVmdY77osOw//A0pNCc47dYkxr8EEpglcFD1aJycUglkM/6Ghs+YBC89MezjI3URYsTUd93U01kvnmj4Ce4o+rVSFsTMN/0bkQsp4v4DQsM1PwPjlpE8zQqG583cg==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n\ts=arcselector9901;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n\tbh=vm6xbAoQPsIrgmO78jjuAW5OKo56mVRoA3eMUKX8pKk=;\n\tb=BHmgsSVHbXsiS0efCDAp+CvDHf5tYHRQCHxe1suEh54f0Uiln3Gho8LXdS/ZLakLh+0MPFvS2IBUWomfR45vKBiGFzPnvgLBFOwJfIxYHVQK4bdT/58ejWm9sgtLC9jQTB5zgghFpIPQfwMpPpApSh9gB5HDAjGjfLkbtBkFEe4mjPLBQYR0a5tDpFVqemWEApRrtOOxVxV+8d8GYIwYbqtAsOHBLDfYTHwvMxjRGIE37WViOQmgKeVy5/xA0O5BLV1OEI9dDkHp4lxAESws5iQXEQez6ZWWDTA2jzMTLv4h5o/5dnUQy0AlJJ8YUXoIXRut1Kn237M7IYRcShRCzw==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass (sender ip is\n\t217.66.60.4) smtp.rcpttodomain=chromium.org\n\tsmtp.mailfrom=opensynergy.com; \n\tdmarc=pass (p=quarantine sp=quarantine pct=100) action=none\n\theader.from=opensynergy.com; dkim=none (message not signed); arc=none", "X-MS-Exchange-Authentication-Results": "spf=pass (sender IP is 217.66.60.4)\n\tsmtp.mailfrom=opensynergy.com; dkim=none (message not signed)\n\theader.d=none;dmarc=pass action=none header.from=opensynergy.com;", "Received-SPF": "Pass (protection.outlook.com: domain of opensynergy.com\n\tdesignates 217.66.60.4 as permitted sender)\n\treceiver=protection.outlook.com; \n\tclient-ip=217.66.60.4; helo=SR-MAIL-03.open-synergy.com; pr=C", "To": "virtio-comment@lists.oasis-open.org,\n\tvirtio-dev@lists.oasis-open.org", "Date": "Thu, 29 Jun 2023 16:49:15 +0200", "Message-Id": "<20230629144915.597188-2-Alexander.Gordeev@opensynergy.com>", "X-Mailer": "git-send-email 2.34.1", "In-Reply-To": "<20230629144915.597188-1-Alexander.Gordeev@opensynergy.com>", "References": "<20230629144915.597188-1-Alexander.Gordeev@opensynergy.com>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "X-EOPAttributedMessage": "0", "X-MS-PublicTrafficType": "Email", "X-MS-TrafficTypeDiagnostic": "VI1EUR05FT045:EE_|FRYP281MB2505:EE_", "Content-Type": "text/plain", "X-MS-Office365-Filtering-Correlation-Id": "f2ca3bd2-17d0-4427-3cfd-08db78b01298", "X-MS-Exchange-SenderADCheck": "1", "X-MS-Exchange-AntiSpam-Relay": "0", "X-Microsoft-Antispam": "BCL:0;", "X-Microsoft-Antispam-Message-Info": "+2myTRgzn/DRiJ29wUjs4ubBr+reZx5xL/T1gBiAWhjJ2+7edImsRKjCPOyNwq1BPN6IoS1DYpVYU7oODsYWBzmClYKCFeLExvYGLEsigVmwcMrAdsZO7tn69V2nPhRd8RvkexQosT9r8iCIsqjlZz+BSJufylvHSQBp8ZZaFt5H1kwSU1Ga0lEXU09Drt0Pb+jmrDC3PjAoiKrMzREPGH42/t+PV9IzOLH2o2ZucFb4XC55ry3PcvWAkfxyXrFQcs+FvwMctbxYx/vdPu2xpjcPkc4EIFoR2d8tnLk0XEC3m0c8TyTsStylrD3Om4fq4YkLLeOSwU9G+25lTDezoop7f3KDAzw6XAqSS1Vvjm7CevJY7VpI3vSnrjDQTOFT1rLnrE4mgBryQN2MsR20tfxoPEKhG6LYdVryhctcD0DGay1lF8ry2CSwOqYhilqCkI6fx+WUDUREphHfvXZDhVuTnX4XFPfih/I6s76jskTi/CJBKKNIlWbuPB4HsW/akZPA1saO244uGZOHMx4a2C8n9iUJlsZ+LpWl8vU1LfQdZB1gQd+v5anBS+W3sh/j1jRXb/BD53CzQQDCOSXzndRpnz4hhLVY5BOgji9unPdDMWj1X98A8F3qRw0TG9ZUMco0BG9RwHO3MBn7+iAakXTEvx4SWIx2QBEZjI0Ri4b7I6ygjAWsk5S7QUKpXpHkHf9YSor+IsLO1BbWeTnEy+npjc1WnzRnQe76xbviF/TXEvVSS9hoNS7v/Fo5uewR834Vtk/+eJB+TWsvDFDt6Q==", "X-Forefront-Antispam-Report": "CIP:217.66.60.4; CTRY:DE; LANG:en; SCL:1; SRV:; \n\tIPV:NLI; SFV:NSPM; H:SR-MAIL-03.open-synergy.com;\n\tPTR:InfoDomainNonexistent; CAT:NONE;\n\tSFS:(13230028)(39840400004)(396003)(346002)(136003)(376002)(451199021)(36840700001)(46966006)(26005)(82310400005)(4326008)(36860700001)(8936002)(36756003)(2616005)(478600001)(1076003)(42186006)(336012)(54906003)(186003)(2906002)(83380400001)(70206006)(7416002)(47076005)(40480700001)(81166007)(30864003)(5660300002)(70586007)(86362001)(8676002)(316002)(41300700001)(36900700001)(559001)(579004);\n\tDIR:OUT; SFP:1102; ", "X-OriginatorOrg": "opensynergy.com", "X-MS-Exchange-CrossTenant-OriginalArrivalTime": "29 Jun 2023 14:49:42.3663\n\t(UTC)", "X-MS-Exchange-CrossTenant-Network-Message-Id": "f2ca3bd2-17d0-4427-3cfd-08db78b01298", "X-MS-Exchange-CrossTenant-Id": "800fae25-9b1b-4edc-993d-c939c4e84a64", "X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp": "TenantId=800fae25-9b1b-4edc-993d-c939c4e84a64;\n\tIp=[217.66.60.4]; \n\tHelo=[SR-MAIL-03.open-synergy.com]", "X-MS-Exchange-CrossTenant-AuthSource": "VI1EUR05FT045.eop-eur05.prod.protection.outlook.com", "X-MS-Exchange-CrossTenant-AuthAs": "Anonymous", "X-MS-Exchange-CrossTenant-FromEntityHeader": "HybridOnPrem", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "FRYP281MB2505", "X-TM-AS-ERS": "104.47.7.175-0.0.0.0", "X-TMASE-Version": "StarCloud-1.3-9.1.1011-27722.000", "X-TMASE-Result": "10--44.068100-4.000000", "X-TMASE-MatchedRID": "29kHMs2vf06UP+0hdpOx0icOunEIf0eXTY6J9vkpk6+EnIovOLzQ+rHq\n\tN6eNokKxnQvVnz410DyLO9h/kZ7mQnkHMxUIdlxL+DE5zr5ahdzc7b6k5+X69zAsn09lQFCFm7W\n\tYZnTau36ijVoxG5GMcAfoZhqt/FSE2J61hi7qqbLWcxHsnT13T+A4l73CwysLkZ43711Uirfnq/\n\tQ0Vm6yzXjkOsl2UmOSiOO4tRkG+50b0MvbS2k7/SHbUYHbu3LPFST1Kl560HX3cndh37T/SWkZM\n\td34UMmmHVL/xxFlcltDINA8M9Ne0U2x0FxidoSmemm/1TaRdd3PpNF1bfHUnMgRXD+03JOE6nse\n\tNNR95gbeUtu7e4i/MP0c497MJh22inAJQ2S8fPTU0ho7mxaK+EhlNcVMkCtB510322JqPPF2Hgl\n\tepQYR/W2J/qwPCeB5W214Tu6s6eS3Pvji3GoaojGcfhF8jWqlUCpvN72sC4R5omhgu+tgnMz6kc\n\tLfmLH3r8zCvZgwym6WVFu85nRfAUJaLSnVzhpREJb5gExl9kglvNm7AvH7hYvXantxmoFYVvBNm\n\tpZsnvlHngKZrA8SBaEXOzL3efiA0ViwfaeIJ4KheJ4X7s7Smid8voqopKNvlueiTveeZGBse4/F\n\thkHD/oWDRBq0nZN4umYnNOnJWHt5R4388c4pswh6+YU9lqNBET56SaIP1M+m5Tj2KN9Ra0Vts87\n\tAfIN/Z4mX9LDz21dRZsCH1yqIuaGHUXYlpMs0s8RQjMiI1+dvhljR6nu+BLUZmn0aeRTzgLSnwL\n\t6izcygrS5V6+bXIU4neQgXlTIqgJ1EY96rSXwRLjqoJJt/9Ye8/oJiio9KA3+iPIxcfrYMSiYZT\n\tF5wqnGDuy8y1qkuImxnQvgkai0i4mJ41W/O+n7cGd19dSFd", "X-TM-Deliver-Signature": "CF01657AA1081B49FF34430C112864C2", "X-TM-Addin-Auth": "cKncH1VmxLBk1dbuUQjWfXkE472IXuvd+1bRf4lqi4Z6cRxwiZVW0d9W330\n\tKFXJXewxHgf4Xij+QaxFJyMzj861NX7bh3ImlPdDg65OiG4iS19amJxJRb3pIQY71VJUUSpXGac\n\tG/cJGzDGRE/NA5P3VECPWse15do9J0f0/3hz9DpInl2VlPQzk0nBEFST+xq6md9bZn+lO2Aet0N\n\t4ttgef1tE5jZfvAKegWMrRWJ0PDn/EjBcYC3JonWqmGO3guEVGOtBVnybepOKqAcJaMArHuoGEp\n\tXcCrSgO3UYWf5qHx0HdEjD6YToz7CxcN1N0X.MDZjze4FW3TZooMs8FcBgfHU22hKLr5kbIRdS/\n\tukCuVIrREO3KGHbcplgU5vsatewkGT+ERTa54vQ3vl1FA4SfQvHsDo0hctq5TI73KkxE3z1S44Z\n\teLYzj5Rgiw1u2fRWgftRw2fahzp84STCbYjw2vyxFj68hsvgGyTyENZ8rdew93Fmhk3WdVFQVc0\n\t1gA9OlK0M84q4J7jqk2oBFTTzAX09JHiXQpyiDi11tw0gaFCrRlhIBOL2X4WstlNutvGEJW8/cu\n\tQLyz5olGSzieCOPVrTaOAX0j6C7GRquok+VzUE26mVDcFq0zcUiZocnzw/I4fq5bZeXE+ATx83L\n\tSUSA==", "X-TM-Addin-ProductCode": "EMS", "X-Mailman-Approved-At": "Thu, 29 Jun 2023 17:08:04 +0200", "Subject": "[libcamera-devel] [RFC PATCH v8 1/1] virtio-video: Add virtio video\n\tdevice specification", "X-BeenThere": "libcamera-devel@lists.libcamera.org", "X-Mailman-Version": "2.1.29", "Precedence": "list", "List-Id": "<libcamera-devel.lists.libcamera.org>", "List-Unsubscribe": "<https://lists.libcamera.org/options/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=unsubscribe>", "List-Archive": "<https://lists.libcamera.org/pipermail/libcamera-devel/>", "List-Post": "<mailto:libcamera-devel@lists.libcamera.org>", "List-Help": "<mailto:libcamera-devel-request@lists.libcamera.org?subject=help>", "List-Subscribe": "<https://lists.libcamera.org/listinfo/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=subscribe>", "From": "Alexander Gordeev via libcamera-devel\n\t<libcamera-devel@lists.libcamera.org>", "Reply-To": "Alexander Gordeev <Alexander.Gordeev@opensynergy.com>", "Cc": "Albert Esteve <aesteve@redhat.com>, hmazur@google.com,\n\t\"Michael S . Tsirkin\" <mst@redhat.com>,\n\tDaniel Almeida <daniel.almeida@collabora.com>,\n\tMarcin Wojtas <mwojtas@google.com>, libcamera-devel@lists.libcamera.org, \n\tbgrzesik@google.com, Andrew Gazizov <andrew.gazizov@opensynergy.com>, \n\tEnric Balletbo i Serra <eballetb@redhat.com>,\n\tGustavo Padovan <gustavo.padovan@collabora.com>,\n\tKeiichi Watanabe <keiichiw@chromium.org>, zyta@google.com,\n\tlinux-media@vger.kernel.org,\n\tAlexander Gordeev <Alexander.Gordeev@opensynergy.com>,\n\talex.bennee@linaro.org, \n\tmikrawczyk@google.com, Matti.Moell@opensynergy.com,\n\tAlexandre Courbot <acourbot@chromium.org>,\n\tCornelia Huck <cohuck@redhat.com>, bag@semihalf.com, srosek@google.com,\n\tEnrico Granata <egranata@google.com>", "Errors-To": "libcamera-devel-bounces@lists.libcamera.org", "Sender": "\"libcamera-devel\" <libcamera-devel-bounces@lists.libcamera.org>" }, "content": "Add the specification of the video decoder and encoder devices, which\ncan be used to provide host-accelerated video operations to the guest.\n\nSigned-off-by: Alexander Gordeev <Alexander.Gordeev@opensynergy.com>\nCo-authored-by: Keiichi Watanabe <keiichiw@chromium.org>\nCo-authored-by: Alexandre Courbot <acourbot@chromium.org>\n---\n conformance.tex | 4 +\n content.tex | 1 +\n device-types/video/description.tex | 2040 +++++++++++++++++++++\n device-types/video/device-conformance.tex | 22 +\n device-types/video/driver-conformance.tex | 16 +\n introduction.tex | 21 +\n 6 files changed, 2104 insertions(+)\n create mode 100644 device-types/video/description.tex\n create mode 100644 device-types/video/device-conformance.tex\n create mode 100644 device-types/video/driver-conformance.tex", "diff": "diff --git a/conformance.tex b/conformance.tex\nindex 01ccd69..d719eda 100644\n--- a/conformance.tex\n+++ b/conformance.tex\n@@ -34,6 +34,7 @@ \\section{Conformance Targets}\\label{sec:Conformance / Conformance Targets}\n \\ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},\n \\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or\n \\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.\n+\\ref{sec:Conformance / Driver Conformance / Video Driver Conformance},\n \n \\item Clause \\ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.\n \\end{itemize}\n@@ -61,6 +62,7 @@ \\section{Conformance Targets}\\label{sec:Conformance / Conformance Targets}\n \\ref{sec:Conformance / Device Conformance / SCMI Device Conformance},\n \\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or\n \\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.\n+\\ref{sec:Conformance / Device Conformance / Video Device Conformance},\n \n \\item Clause \\ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.\n \\end{itemize}\n@@ -152,6 +154,7 @@ \\section{Conformance Targets}\\label{sec:Conformance / Conformance Targets}\n \\input{device-types/scmi/driver-conformance.tex}\n \\input{device-types/gpio/driver-conformance.tex}\n \\input{device-types/pmem/driver-conformance.tex}\n+\\input{device-types/video/driver-conformance.tex}\n \n \\conformance{\\section}{Device Conformance}\\label{sec:Conformance / Device Conformance}\n \n@@ -238,6 +241,7 @@ \\section{Conformance Targets}\\label{sec:Conformance / Conformance Targets}\n \\input{device-types/scmi/device-conformance.tex}\n \\input{device-types/gpio/device-conformance.tex}\n \\input{device-types/pmem/device-conformance.tex}\n+\\input{device-types/video/device-conformance.tex}\n \n \\conformance{\\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}\n A conformant implementation MUST be either transitional or\ndiff --git a/content.tex b/content.tex\nindex d2ab9eb..90708d7 100644\n--- a/content.tex\n+++ b/content.tex\n@@ -765,6 +765,7 @@ \\chapter{Device Types}\\label{sec:Device Types}\n \\input{device-types/scmi/description.tex}\n \\input{device-types/gpio/description.tex}\n \\input{device-types/pmem/description.tex}\n+\\input{device-types/video/description.tex}\n \n \\chapter{Reserved Feature Bits}\\label{sec:Reserved Feature Bits}\n \ndiff --git a/device-types/video/description.tex b/device-types/video/description.tex\nnew file mode 100644\nindex 0000000..760df7f\n--- /dev/null\n+++ b/device-types/video/description.tex\n@@ -0,0 +1,2040 @@\n+\\section{Video Device}\n+\\label{sec:Device Types / Video Device}\n+\n+The virtio video encoder and decoder devices provide support for\n+host-accelerated video encoding and decoding. Despite being different\n+device types, they use the same protocol and general flow.\n+\n+\\subsection{Device ID}\n+\\label{sec:Device Types / Video Device / Device ID}\n+\n+\\begin{description}\n+\\item[30]\n+ encoder device\n+\\item[31]\n+ decoder device\n+\\end{description}\n+\n+\\subsection{Virtqueues}\n+\\label{sec:Device Types / Video Device / Virtqueues}\n+\n+\\begin{description}\n+\\item[0]\n+ commandq - queue for driver commands and device responses to these commands\n+\\item[1]\n+ eventq - queue for device delayed responses to commands and standalone\n+ device events\n+\\end{description}\n+\n+\\subsection{Feature bits}\n+\\label{sec:Device Types / Video Device / Feature bits}\n+\n+\\begin{description}\n+\\item[VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES (0)]\n+ Guest pages can be used as the backing memory of resources.\n+\\item[VIRTIO_VIDEO_F_RESOURCE_NON_CONTIG (1)]\n+ The device can use non-contiguous guest memory as the backing memory of\n+ resources. Only meaningful if VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES is also\n+ set.\n+\\item[VIRTIO_VIDEO_F_RESOURCE_VIRTIO_OBJECT (2)]\n+ Objects exported by another virtio device can be used as the backing memory\n+ of resources.\n+\\item[VIRTIO_VIDEO_F_RESOURCE_DYNAMIC (3)]\n+ The device supports re-attaching memory to resources while streaming.\n+% TODO this flag is not used anywhere at the moment.\n+% Might be necessary with Android.\n+\\end{description}\n+\n+\\devicenormative{\\subsubsection}{Feature bits}{Device Types / Video Device / Feature bits}\n+\n+The device MUST set at least one of VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES or\n+VIRTIO_VIDEO_F_RESOURCE_VIRTIO_OBJECT, since the absence of both bits would\n+mean that no memory can be used at all for resources.\n+\n+The device MUST NOT set VIRTIO_VIDEO_F_RESOURCE_NON_CONTIG unless it also sets\n+VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES.\n+\n+\\drivernormative{\\subsubsection}{Feature bits}{Device Types / Video Device / Feature bits}\n+\n+The driver MUST negotiate at least one of the\n+VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES and VIRTIO_VIDEO_F_RESOURCE_VIRTIO_OBJECT\n+features.\n+\n+If VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES has been negotiated, but not\n+VIRTIO_VIDEO_F_RESOURCE_NON_CONTIG, the driver MUST use physically\n+contiguous memory for all the buffers it allocates.\n+\n+\\subsection{Device configuration layout}\n+\\label{sec:Device Types / Video Device / Device configuration layout}\n+\n+The video device configuration space uses the following layout:\n+\n+\\begin{lstlisting}\n+struct virtio_video_config {\n+ le32 caps_length;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{caps_length}]\n+ is the minimum length in bytes that a device-writable buffer must have\n+ in order to receive the response to VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS, see\n+ \\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.\n+\\end{description}\n+\n+\\devicenormative{\\subsubsection}{Device configuration layout}{Device Types / Video Device / Device configuration layout}\n+\n+The device MUST set the \\field{caps_length} field to a value equal to\n+the response size of VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS.\n+\n+\\subsection{Supported parameters}\n+\\label{sec:Device Types / Video Device / Supported parameters}\n+\n+\\subsubsection{Supported coded formats}\n+\\label{sec:Device Types / Video Device / Supported parameters / Supported coded formats}\n+\n+The following coded formats are defined:\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_CODED_FORMAT_MPEG2 1 /* MPEG-2 Part 2 (V4L2_PIX_FMT_MPEG2) */\n+#define VIRTIO_VIDEO_CODED_FORMAT_MPEG4 2 /* MPEG-4 Part 2 (V4L2_PIX_FMT_MPEG4) */\n+#define VIRTIO_VIDEO_CODED_FORMAT_H264 3 /* H.264 (V4L2_PIX_FMT_H264) */\n+#define VIRTIO_VIDEO_CODED_FORMAT_HEVC 4 /* HEVC aka H.265 (V4L2_PIX_FMT_HEVC) */\n+#define VIRTIO_VIDEO_CODED_FORMAT_VP8 5 /* VP8 (V4L2_PIX_FMT_VP8) */\n+#define VIRTIO_VIDEO_CODED_FORMAT_VP9 6 /* VP9 (V4L2_PIX_FMT_VP9) */\n+\\end{lstlisting}\n+\n+The above constants have two usages:\n+\\begin{enumerate}\n+\\item As bit numbers, used to tell the driver which coded formats are\n+supported by the device, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.\n+\\item As values, used to designate the coded format when working with\n+stream parameters, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.\n+\\end{enumerate}\n+\n+The coded formats and the expected data units per buffer are documented in\n+\\hyperref[intro:V4L2]{V4L2 header} and\n+\\hyperref[intro:V4L2 compressed]{V4L2 compressed formats documentation}.\n+\n+\\subsubsection{Supported raw formats}\n+\\label{sec:Device Types / Video Device / Supported parameters / Supported raw formats}\n+\n+The following raw formats are defined:\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_RAW_FORMAT_ARGB8888 1 /* DRM_FORMAT_ARGB8888 / V4L2_PIX_FMT_ABGR32 */\n+#define VIRTIO_VIDEO_RAW_FORMAT_BGRA8888 2 /* DRM_FORMAT_BGRA8888 / V4L2_PIX_FMT_ARGB32 */\n+#define VIRTIO_VIDEO_RAW_FORMAT_RGBA8888 3 /* DRM_FORMAT_RGBA8888 / V4L2_PIX_FMT_BGRA32 */\n+#define VIRTIO_VIDEO_RAW_FORMAT_NV12 4 /* DRM_FORMAT_NV12 / V4L2_PIX_FMT_NV12 */\n+#define VIRTIO_VIDEO_RAW_FORMAT_YUV420 5 /* DRM_FORMAT_YUV420 / V4L2_PIX_FMT_YUV420 */\n+#define VIRTIO_VIDEO_RAW_FORMAT_YVU420 6 /* DRM_FORMAT_YVU420 / V4L2_PIX_FMT_YVU420 */\n+#define VIRTIO_VIDEO_RAW_FORMAT_YUYV 7 /* DRM_FORMAT_YUYV / V4L2_PIX_FMT_YUYV */\n+\\end{lstlisting}\n+\n+The above constants have two usages:\n+\\begin{enumerate}\n+\\item As bit numbers, used to tell the driver which raw formats are\n+supported by the device, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.\n+\\item As values, used to designate the raw format when working with\n+stream parameters, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.\n+\\end{enumerate}\n+\n+The layouts of raw formats are documented in \\hyperref[intro:DRM formats]{DRM}\n+and \\hyperref[intro:V4L2]{V4L2} headers, as well as in\n+\\hyperref[intro:V4L2 RGB]{V4L2 RGB} and\n+\\hyperref[intro:V4L2 YUV]{planar YUV} formats documentation.\n+\n+\\subsubsection{Supported stream parameters}\n+\\label{sec:Device Types / Video Device / Supported parameters / Supported stream parameters}\n+\n+The following stream parameters are defined:\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_PARAM_CODED_FORMAT 1\n+#define VIRTIO_VIDEO_PARAM_RAW_FORMAT 2\n+#define VIRTIO_VIDEO_PARAM_CODED_RESOURCES 3\n+#define VIRTIO_VIDEO_PARAM_RAW_RESOURCES 4\n+#define VIRTIO_VIDEO_PARAM_CROP 5\n+#define VIRTIO_VIDEO_PARAM_BITRATE 6 /* Same as V4L2_CID_MPEG_VIDEO_BITRATE */\n+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_MPEG2 7\n+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_MPEG4 8\n+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_H264 9\n+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_HEVC 10\n+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_VP8 11\n+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_VP9 12\n+\\end{lstlisting}\n+% TODO acourbot: See b/241492607 (fractional frame rates??)\n+\n+The above constants have two usages:\n+\\begin{enumerate}\n+\\item As bit numbers, used to tell the driver which stream parameters are\n+supported by the device, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.\n+\\item As values, used to designate the stream parameters when working with\n+them, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.\n+\\end{enumerate}\n+\n+\\subsection{Device Initialization}\n+\\label{sec:Device Types / Video Device / Device Initialization}\n+\n+\\begin{enumerate}\n+\\def\\labelenumi{\\arabic{enumi}.}\n+\\item\n+ The driver reads the feature bits and negotiates the features it needs.\n+\\item\n+ The driver sets up the commandq and the eventq.\n+\\item\n+ The driver reads the \\field{caps_length} field of the configuration\n+ space and prepares a buffer of at least that size.\n+\\item\n+ The driver sends that buffer on the commandq with the\n+ VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS command.\n+\\item\n+ The driver receives the response from the device, and parses its capabilities.\n+\\end{enumerate}\n+\n+\\subsection{Device Operation}\n+\\label{sec:Device Types / Video Device / Device Operation}\n+\n+The commandq is used by the driver to send commands to the device and to\n+receive the device's responses via used buffers. The eventq is used by the\n+device to send the device's delayed responses to commands and standalone\n+device events.\n+\n+The driver can create new streams using the\n+VIRTIO_VIDEO_CMD_STREAM_CREATE command. Each stream has two resource\n+queues (not to be confused with the virtio queues) called INPUT and\n+OUTPUT, when the direction of the data flow matters. The INPUT queue accepts\n+driver-filled input data for the device (coded data for a decoder;\n+input frames for an encoder), while the OUTPUT queue receives resources to be\n+filled by the device as a result of processing the INPUT queue (decoded raw\n+frames for a decoder; encoded data for an encoder).\n+\n+These same queues can be also called CODED and RAW, when their content matters.\n+The CODED queue is used to transfer compressed video data (INPUT for a decoder;\n+OUTPUT for an encoder), while the RAW queue is used to transfer raw frames\n+(OUTPUT for a decoder; INPUT for an encoder).\n+\n+The INPUT and OUTPUT queues are effectively independent, and the driver\n+can fill them without caring about the other queue. In particular there\n+is no need to queue input and output resources in pairs: one input\n+resource can result in zero to many produced output resources.\n+\n+A resource is a set of memory buffers that contain a unit of data that\n+the device can process or produce. Most resources will only have one\n+buffer (like coded data and single-planar raw frames), but frames using a\n+multi-planar format can have several.\n+\n+Parameters allow the driver to configure the stream for the decoding or\n+encoding operation. The parameters can be obtained and configured using\n+VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS. Available parameters depend on\n+the device type and are detailed in section\n+\\ref{sec:Device Types / Video Device / Supported parameters / Supported stream parameters}.\n+\n+Before resources can be submitted to a queue, backing memory must be\n+attached to them using VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING.\n+The exact form of that memory is negotiated using the feature flags.\n+\n+In the case of a decoder device, the decoded frames are made available\n+on the OUTPUT queue in presentation order.\n+\n+Resources are queued to the INPUT or OUTPUT queue using the\n+VIRTIO_VIDEO_CMD_RESOURCE_QUEUE command. The device sends a delayed response\n+to this command when an input resource has been fully processed and can be\n+reused by the driver, or when an output resource has been filled by the\n+device as a result of processing.\n+\n+The device can detect stream-related events that require intervention\n+from the driver and signals them on the eventq, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events}.\n+One example is a dynamic parameters change while decoding a stream, which\n+may require the driver to reallocate the backing memory of its output\n+resources to fit the new resolution.\n+\n+% RESET and DRAIN have essentially the same outcome: all the input\n+% resources queued before the command are released, there are no related\n+% output resources in the decoder/encoder, the dequeued output resources\n+% can't be used as a reference by the device. So the other requirements should\n+% be reasonably similar.\n+% Use-case: playback in a loop from second 1 till the end of file.\n+\n+% TODO put some examples in the comments\n+\n+\\subsubsection{Device Operation: Command Virtqueue}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+\n+This section details the commands that can be sent on the commandq by\n+the driver, as well as the responses that the device will write.\n+\n+Different structures are used for each command and response. A command\n+structure starts with the requested command code, defined as follows:\n+\n+\\begin{lstlisting}\n+/* Device */\n+#define VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS 0x100\n+\n+/* Stream */\n+#define VIRTIO_VIDEO_CMD_STREAM_CREATE 0x200\n+#define VIRTIO_VIDEO_CMD_STREAM_DESTROY 0x201\n+#define VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS 0x202\n+#define VIRTIO_VIDEO_CMD_STREAM_DRAIN 0x203\n+#define VIRTIO_VIDEO_CMD_STREAM_RESET 0x204\n+\n+/* Resource */\n+#define VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING 0x300\n+#define VIRTIO_VIDEO_CMD_RESOURCE_QUEUE 0x301\n+\\end{lstlisting}\n+\n+A response structure starts with the result of the requested command,\n+defined as follows:\n+\n+\\begin{lstlisting}\n+/* Success */\n+#define VIRTIO_VIDEO_RESULT_OK 0x000\n+#define VIRTIO_VIDEO_RESULT_OK_DELAYED 0x001\n+\n+/* Error */\n+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_COMMAND 0x100\n+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION 0x101\n+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_STREAM_ID 0x102\n+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_RESOURCE_ID 0x103\n+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_ARGUMENT 0x104\n+#define VIRTIO_VIDEO_RESULT_ERR_OUT_OF_MEMORY 0x105\n+\\end{lstlisting}\n+\n+For response structures carrying an error code, the rest of the\n+structure is considered invalid.\n+\n+For all commands beginning background operations and returning delayed\n+responses over eventq, the command response is defined as follows:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_INVALID_RESPONSE_ID 0xffffffff\n+\n+struct virtio_video_command_resp_delayed_common {\n+ le32 result; /* VIRTIO_VIDEO_RESULT_* */\n+ le32 delayed_response_id;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{result}]\n+ is\n+\n+ \\begin{description}\n+ \\item[VIRTIO_VIDEO_RESULT_OK_DELAYED]\n+ if the command started the desired background operation successfully,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_INVALID_STREAM_ID]\n+ if the mentioned stream ID does not exist,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_INVALID_RESOURCE_ID]\n+ if the mentioned resource ID does not exist,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_INVALID_ARGUMENT]\n+ if other command parameters are not valid, e.g. not within the device's\n+ capabilities,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION]\n+ if the command is performed at a time when it is not valid.\n+ \\end{description}\n+\\item[\\field{delayed_response_id}]\n+ is an ID of the future delayed response provided by the device, that allows\n+ to relate it to the command.\n+\\end{description}\n+\n+\\devicenormative{\\paragraph}{Device Operation: Command Virtqueue}{Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+\n+Responses to a command MUST be written by the device in the first\n+device-writable descriptor of the descriptor chain from which the\n+command came.\n+\n+The device MUST return VIRTIO_VIDEO_RESULT_ERR_INVALID_COMMAND to\n+any command code it does not recognize.\n+\n+\\field{delayed_response_id} MUST be set to a stream-unique identifier that\n+remains valid as long as the background operation hasn't finished.\n+\n+\\drivernormative{\\paragraph}{Device Operation: Command Virtqueue}{Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+\n+Descriptor chains sent to the commandq by the driver MUST include at\n+least one device-writable descriptor of a size sufficient to receive the\n+response to the queued command.\n+\n+The driver MUST NOT interpret the rest of a response whose result is not\n+VIRTIO_VIDEO_RESULT_OK or VIRTIO_VIDEO_RESULT_OK_DELAYED.\n+\n+\\subsubsection{Device Operation: Event Virtqueue}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}\n+\n+The eventq is used by the device to send delayed responses to commands queued\n+by the driver on the commandq and standalone events. Stream errors and dynamic\n+parameters changes are caused by changes in the device's state, not by\n+commands, still they are delivered as VIRTIO_VIDEO_DELAYED_RESP_STREAM_DESTROY\n+and VIRTIO_VIDEO_DELAYED_RESP_STREAM_SET_PARAMS, respectively.\n+\n+The supported events are defined as follows:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_DELAYED_RESP_STREAM_DESTROY 1\n+#define VIRTIO_VIDEO_DELAYED_RESP_STREAM_SET_PARAMS 2\n+#define VIRTIO_VIDEO_DELAYED_RESP_STREAM_DRAIN 3\n+#define VIRTIO_VIDEO_DELAYED_RESP_STREAM_RESET 4\n+#define VIRTIO_VIDEO_DELAYED_RESP_RESOURCE_QUEUE 5\n+\n+#define VIRTIO_VIDEO_EVENT_FLAG_CANCELED (1 << 0)\n+\n+struct virtio_video_event {\n+ le32 event_type; /* VIRTIO_VIDEO_DELAYED_RESP_* */\n+ le32 stream_id;\n+ le32 delayed_response_id;\n+ le32 event_flags; /* Bitmask of VIRTIO_VIDEO_EVENT_FLAG_* */\n+ union {\n+ struct virtio_video_stream_set_params_delayed_resp set_params;\n+ struct virtio_video_resource_queue_delayed_resp queue;\n+ };\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{event_type}]\n+ is the type of the event.\n+\\item[\\field{stream_id}]\n+ is the ID of a valid stream.\n+\\item[\\field{delayed_response_id}]\n+ is an ID of the delayed response, that allows to relate it to a previously\n+ submitted command. If it is set to VIRTIO_VIDEO_INVALID_RESPONSE_ID, then\n+ this is a standalone event, see\n+ \\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events}.\n+\\item[\\field{event_flags}]\n+ is a bitmask of VIRTIO_VIDEO_EVENT_FLAG_* flags\n+\n+ \\begin{description}\n+ \\item[VIRTIO_VIDEO_EVENT_FLAG_CANCELED]\n+ is set if the command has been canceled by another command, that has\n+ higher priority. Doesn't make sense for standalone events.\n+ \\end{description}\n+\\end{description}\n+\n+The particular member of the union is selected according to the\n+\\field{event_type} for some of the types.\n+\n+\\drivernormative{\\paragraph}{Device Operation: Event Virtqueue}{Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}\n+\n+The driver MUST at any time have at least one descriptor with a used\n+buffer large enough to contain a \\field{struct virtio_video_event}\n+queued on the eventq.\n+\n+The driver MUST NOT put device-readable descriptors into the eventq.\n+\n+\\subsubsection{Device Operation: Device Commands}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands}\n+\n+This command allows retrieving the device capabilities.\n+\n+\\paragraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}\n+\n+Retrieve device capabilities for all available stream parameters.\n+\n+The driver sends this command with\n+\\field{struct virtio_video_device_query_caps}:\n+\n+\\begin{lstlisting}\n+struct virtio_video_device_query_caps {\n+ le32 cmd_type; /* VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS */\n+};\n+\\end{lstlisting}\n+\n+The device responds with\n+\\field{struct virtio_video_device_query_caps_resp}:\n+\n+\\begin{lstlisting}\n+#define MASK(x) (1 << (x))\n+\n+struct virtio_video_device_query_caps_resp {\n+ le32 result; /* VIRTIO_VIDEO_RESULT_* */\n+ le32 stream_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_PARAM_*) */\n+ le32 coded_formats_bitmask; /* Bitmaks of MASK(VIRTIO_VIDEO_CODED_FORMAT_*) */\n+ le32 raw_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_RAW_FORMAT_*) */\n+ le32 num_format_deps;\n+ le32 num_raw_format_caps;\n+ le32 num_coded_resources_caps;\n+ le32 num_raw_resources_caps;\n+ le32 num_bitrate_caps; /* If MASK(VIRTIO_VIDEO_PARAM_BITRATE) is set. */\n+ u8 padding[4];\n+ /* If corresponding MASK(VIRTIO_VIDEO_PARAM_GROUP_CODEC_*) is set. */\n+ struct virtio_video_mpeg2_caps mpeg2_caps;\n+ struct virtio_video_mpeg4_caps mpeg4_caps;\n+ struct virtio_video_h264_caps h264_caps;\n+ struct virtio_video_hevc_caps hevc_caps;\n+ struct virtio_video_vp8_caps vp8_caps;\n+ struct virtio_video_vp9_caps vp9_caps;\n+ /**\n+ * Followed by\n+ * struct virtio_video_format_dependency format_deps[num_format_deps];\n+ */\n+ /**\n+ * Followed by\n+ * struct virtio_video_raw_format_caps raw_format_caps[num_raw_format_caps];\n+ */\n+ /**\n+ * Followed by\n+ * struct virtio_video_coded_resources_caps\n+ * coded_resources_caps[num_coded_resources_caps];\n+ */\n+ /**\n+ * Followed by\n+ * struct virtio_video_raw_resources_caps raw_resources_caps[num_raw_resources_caps];\n+ */\n+ /**\n+ * Followed by if MASK(VIRTIO_VIDEO_PARAM_BITRATE) is set\n+ * struct virtio_video_bitrate_caps bitrate_caps[num_bitrate_caps];\n+ */\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{result}]\n+ is\n+\n+ \\begin{description}\n+ \\item[VIRTIO_VIDEO_RESULT_OK]\n+ if the operation succeeded,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_OUT_OF_MEMORY]\n+ if the descriptor was smaller than the defined \\field{caps_length} in\n+ the video device configuration.\n+ \\end{description}\n+\\item[\\field{stream_params_bitmask}]\n+ is a bitmask of supported stream parameters.\n+\\item[\\field{coded_formats_bitmask}]\n+ is a bitmask of supported coded formats.\n+\\item[\\field{raw_formats_bitmask}]\n+ is a bitmask of supported raw formats.\n+\\item[\\field{num_format_deps}]\n+ is the number of elements in the format_deps array.\n+\\item[\\field{num_raw_format_caps}]\n+ is the number of elements in the raw_format_caps array.\n+\\item[\\field{num_coded_resources_caps}]\n+ is the number of elements in the coded_resources_caps array.\n+\\item[\\field{num_raw_resources_caps}]\n+ is the number of elements in the raw_resources_caps array.\n+\\item[\\field{num_bitrate_caps}]\n+ is the number of elements in the bitrate_caps array.\n+\\item[\\field{mpeg2_caps}]\n+ groups the capabilities of MPEG2 specific parameters.\n+\\item[\\field{mpeg4_caps}]\n+ groups the capabilities of MPEG4 specific parameters.\n+\\item[\\field{h264_caps}]\n+ groups the capabilities of H.264 specific parameters.\n+\\item[\\field{hevc_caps}]\n+ groups the capabilities of HEVC specific parameters.\n+\\item[\\field{vp8_caps}]\n+ groups the capabilities of VP8 specific parameters.\n+\\item[\\field{vp9_caps}]\n+ groups the capabilities of VP9 specific parameters.\n+\\item[\\field{format_deps}]\n+ is an array of size \\field{num_format_deps} establishing dependencies\n+ between coded and raw formats.\n+\\item[\\field{raw_format_caps}]\n+ is an array of size \\field{num_raw_format_caps} containing the supported\n+ raw formats capabilities.\n+\\item[\\field{coded_resources_caps}]\n+ is an array of size \\field{num_coded_resources_caps}, that sets bounds for\n+ the number of resources in the CODED queue.\n+\\item[\\field{raw_resources_caps}]\n+ is an array of size \\field{num_raw_resources_caps}, that sets bounds for\n+ the number of resources in the RAW queue.\n+\\item[\\field{bitrate_caps}]\n+ is an array of size \\field{num_bitrate_caps} containing the supported\n+ bitrates.\n+\\end{description}\n+\n+% TODO: V4L2 flow: 1. coded format without variants (maybe these flags\n+% are relevant too: V4L2_FMT_FLAG_CONTINUOUS_BYTESTREAM?,\n+% V4L2_FMT_FLAG_DYN_RESOLUTION?, V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL???),\n+% also include variants (see VIDIOC_QUERYCTRL), then raw formats,\n+% then resolutions (discrete or stepwise, see VIDIOC_ENUM_FRAMESIZES),\n+% intervals are optional (see VIDIOC_ENUM_FRAMEINTERVALS)\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}\n+\n+The device MUST support at least these parameters:\n+VIRTIO_VIDEO_PARAM_CODED_FORMAT, VIRTIO_VIDEO_PARAM_RAW_FORMAT,\n+VIRTIO_VIDEO_PARAM_CODED_RESOURCES, VIRTIO_VIDEO_PARAM_RAW_RESOURCES.\n+\n+The device MUST NOT mark codec-specific parameters\n+(VIRTIO_VIDEO_PARAM_GROUP_CODEC_*) as supported unless the corresponding\n+codecs are supported as well.\n+\n+The device MUST set to zero all fields with capabilities of unsupported\n+parameters.\n+\n+The lengths \\field{num_format_deps}, \\field{num_raw_format_caps},\n+\\field{num_coded_resources_caps} and \\field{num_raw_resources_caps} MUST be\n+positive.\n+\n+The device MUST write the five \\field{format_deps},\n+\\field{raw_format_caps}, \\field{coded_resources_caps},\n+\\field{raw_resources_caps} and \\field{bitrate_caps} arrays, of length\n+\\field{num_format_deps}, \\field{num_raw_format_caps},\n+\\field{num_coded_resources_caps}, \\field{num_raw_resources_caps} and\n+\\field{num_bitrate_caps}, respectively.\n+\n+For each coded format in the \\field{coded_formats_bitmask} there MUST be\n+at least one element of \\field{format_deps} referencing it.\n+\n+For each raw format in the \\field{raw_formats_bitmask} there MUST be\n+at least one element of \\field{format_deps} referencing it.\n+\n+For any coded and any raw format there MUST be at most one element of\n+\\field{format_deps} referencing both of them.\n+\n+Elements of \\field{format_deps} SHOULD be ordered according to raw format\n+preferences of the device from preferred to not preferred ones.\n+\n+For each raw format in the \\field{raw_formats_bitmask} there MUST be\n+exactly one element of \\field{raw_format_caps} referencing it.\n+\n+For each coded format in the \\field{coded_formats_bitmask} there MUST be\n+exactly one element of \\field{coded_resources_caps} referencing it.\n+\n+For each raw format in the \\field{raw_formats_bitmask} there MUST be\n+exactly one element of \\field{raw_resources_caps} referencing it.\n+\n+If VIRTIO_VIDEO_PARAM_BITRATE is supported, then for each coded format in\n+the \\field{coded_formats_bitmask} there MUST be exactly one element of\n+\\field{bitrate_caps} referencing it.\n+\n+The total size of the response MUST be equal to \\field{caps_length}\n+bytes, as reported by the device configuration.\n+\n+\\subparagraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Format dependencies}\n+\n+The description of dependencies between coded and raw formats\n+\\field{virtio_video_format_dependency} is defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_format_dependency {\n+ le32 coded_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_CODED_FORMAT_*) */\n+ le32 raw_format; /* VIRTIO_VIDEO_RAW_FORMAT_* */\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{coded_formats_bitmask}]\n+ specifies coded formats, see\n+ \\ref{sec:Device Types / Video Device / Supported parameters / Supported coded formats}.\n+ If a bit for a specific coded format is set, then this coded format can be\n+ decoded into the specified raw format or encoded from it.\n+\\item[\\field{raw_format}]\n+ is a raw format, see\n+ \\ref{sec:Device Types / Video Device / Supported parameters / Supported raw formats}.\n+\\end{description}\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Format dependencies}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Format dependencies}\n+\n+\\field{coded_formats_bitmask} MUST be a subset of \\field{coded_formats_bitmask}\n+field of \\field{struct virtio_video_device_query_caps_resp}.\n+\n+\\field{coded_formats_bitmask} MUST specify at least one coded format.\n+\n+\\field{raw_format} MUST be set to one of the supported raw formats according to\n+the \\field{raw_formats_bitmask} field of\n+\\field{struct virtio_video_device_query_caps_resp}.\n+\n+\\subparagraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}\n+\n+The raw format capability description \\field{virtio_video_raw_format_caps} is\n+defined as follows:\n+\n+\\begin{lstlisting}\n+enum virtio_video_planes_layout {\n+ VIRTIO_VIDEO_PLANES_LAYOUT_SINGLE_BUFFER = 1,\n+ VIRTIO_VIDEO_PLANES_LAYOUT_MULTI_BUFFERS = 2,\n+};\n+\n+struct virtio_video_range {\n+ le32 min;\n+ le32 max;\n+ le32 step;\n+ u8 padding[4];\n+};\n+\n+struct virtio_video_raw_format_caps {\n+ le32 raw_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_RAW_FORMAT_*) */\n+ le32 planes_layouts; /* Bitmask of VIRTIO_VIDEO_PLANES_LAYOUT_* */\n+ le32 plane_align;\n+ le32 stride_align_mask;\n+ struct virtio_video_range width_range;\n+ struct virtio_video_range height_range;\n+};\n+\\end{lstlisting}\n+\n+\\field{struct virtio_video_range} is used to represent a range of values.\n+An integer \\(x\\) is within the range \\field{r} if\n+\\(\\field{r.min} \\le x \\le \\field{r.max}\\) holds and \\(x\\) equals to\n+\\((\\field{min} + \\field{step} * n)\\) for some integer \\(n\\).\n+\n+\\begin{description}\n+\\item[\\field{raw_formats_bitmask}]\n+ specifies raw formats, see\n+ \\ref{sec:Device Types / Video Device / Supported parameters / Supported raw formats},\n+ to which these capabilities apply.\n+\\item[\\field{planes_layouts}]\n+ is a bitmask with the set of plane layout types from\n+ \\field{enum virtio_video_planes_layout}.\n+\\item[\\field{plane_align}]\n+ is the alignment of planes within a buffer in bytes. This field is valid\n+ only if \\field{planes_layouts} has the\n+ \\field{VIRTIO_VIDEO_PLANES_LAYOUT_SINGLE_BUFFER} bit set.\n+\\item[\\field{stride_align_mask}]\n+ is a mask of all supported power of two stride alignments.\n+\\item[\\field{width_range}]\n+ is a range of widths in pixels.\n+\\item[\\field{height_range}]\n+ is a range of heights in pixels.\n+\\end{description}\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}\n+\n+\\field{raw_formats_bitmask} MUST be a subset of \\field{raw_formats_bitmask}\n+field of \\field{struct virtio_video_device_query_caps_resp}.\n+\n+\\field{raw_formats_bitmask} MUST specify at least one raw format.\n+\n+The device MUST set \\field{VIRTIO_VIDEO_PLANES_LAYOUT_SINGLE_BUFFER} bit in\n+\\field{planes_layouts} if the plane layout with planes of a frame laid out one\n+after another in the same buffer is supported.\n+\n+The device MUST set \\field{VIRTIO_VIDEO_PLANES_LAYOUT_MULTI_BUFFERS} bit in\n+\\field{planes_layouts} if the plane layout with planes of a frame laid out in\n+separate buffers is supported.\n+\n+\\field{plane_align} MUST be set to a power of two according to the device\n+plane alignment requirements if \\field{planes_layouts} has the\n+\\field{VIRTIO_VIDEO_PLANES_LAYOUT_SINGLE_BUFFER} bit set or to zero otherwise.\n+\n+\\field{min}, \\field{step} and \\field{max} MUST be positive.\n+\n+\\field{min} MUST be less then or equal to \\field{max} within the same range.\n+\n+\\subparagraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Resource capabilities}\n+\n+The CODED resource capabilities \\field{virtio_video_coded_resources_caps} is\n+defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_coded_resources_caps {\n+ le32 coded_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_CODED_FORMAT_*) */\n+ le32 min_resources;\n+ le32 max_resources;\n+ le32 buffer_size;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{coded_formats_bitmask}]\n+ specifies coded formats, see\n+ \\ref{sec:Device Types / Video Device / Supported parameters / Supported coded formats},\n+ to which these capabilities apply.\n+\\item[\\field{min_resources}]\n+ is the minimum number of resources that the CODED queue supports for all\n+ the specified coded formats.\n+\\item[\\field{max_resources}]\n+ is the maximum number of resources that the CODED queue supports for all\n+ the specified coded formats.\n+\\item[\\field{buffer_size}]\n+ is the minimum size of the buffers that will back resources to be queued.\n+\\end{description}\n+\n+The RAW resource capabilities \\field{virtio_video_raw_resources_caps} is\n+defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_raw_resources_caps {\n+ le32 raw_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_RAW_FORMAT_*) */\n+ le32 min_resources;\n+ le32 max_resources;\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{raw_formats_bitmask}]\n+ specifies raw formats, see\n+ \\ref{sec:Device Types / Video Device / Supported parameters / Supported raw formats},\n+ to which these capabilities apply.\n+\\item[\\field{min_resources}]\n+ is the minimum number of resources that the RAW queue supports for all\n+ the specified raw formats.\n+\\item[\\field{max_resources}]\n+ is the maximum number of resources that the RAW queue supports for all\n+ the specified raw formats.\n+\\end{description}\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Resource capabilities}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Resource capabilities}\n+\n+\\field{coded_formats_bitmask} MUST be a subset of \\field{coded_formats_bitmask}\n+field of \\field{struct virtio_video_device_query_caps_resp}.\n+\n+\\field{coded_formats_bitmask} MUST specify at least one coded format.\n+\n+\\field{raw_formats_bitmask} MUST be a subset of \\field{raw_formats_bitmask}\n+field of \\field{struct virtio_video_device_query_caps_resp}.\n+\n+\\field{raw_formats_bitmask} MUST specify at least one raw format.\n+\n+\\field{min_resources} MUST NOT be negative.\n+\n+\\field{max_resources} MUST be greater then or equal to \\field{min_resources}\n+within the same struct instance.\n+\n+\\subparagraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Bitrates}\n+\n+The bitrate capabilities \\field{virtio_video_bitrate_caps} is\n+defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_bitrate_caps {\n+ le32 coded_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_CODED_FORMAT_*) */\n+ le32 min_bitrate;\n+ le32 max_bitrate;\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{coded_formats_bitmask}]\n+ specifies coded formats, see\n+ \\ref{sec:Device Types / Video Device / Supported parameters / Supported coded formats},\n+ to which these capabilities apply.\n+\\item[\\field{min_bitrate}]\n+ is the minimum bitrate in bits per second supported by the encoder for all the specified coded\n+ formats.\n+\\item[\\field{max_bitrate}]\n+ is the maximum bitrate in bits per second supported by the encoder for all the specified coded\n+ formats.\n+\\end{description}\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Bitrates}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Bitrates}\n+\n+\\field{coded_formats_bitmask} MUST be a subset of \\field{coded_formats_bitmask}\n+field of \\field{struct virtio_video_device_query_caps_resp}.\n+\n+\\field{coded_formats_bitmask} MUST specify at least one coded format.\n+\n+\\field{min_bitrate} MUST NOT be negative.\n+\n+\\field{max_bitrate} MUST be greater then or equal to \\field{min_bitrate}\n+within the same \\field{struct virtio_video_bitrate_caps} instance.\n+\n+\\subsubsection{Device Operation: Stream commands}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands}\n+\n+Stream commands allow the creation, destruction, and flow control of a\n+stream.\n+\n+\\paragraph{VIRTIO_VIDEO_CMD_STREAM_CREATE}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_CREATE}\n+\n+Create a new stream using the device.\n+\n+The driver sends this command with\n+\\field{struct virtio_video_stream_create}:\n+\n+\\begin{lstlisting}\n+struct virtio_video_stream_create {\n+ le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_CREATE */\n+};\n+\\end{lstlisting}\n+\n+The device responds with \\field{struct virtio_video_stream_create_resp}:\n+\n+\\begin{lstlisting}\n+struct virtio_video_stream_create_resp {\n+ le32 result; /* VIRTIO_VIDEO_RESULT_* */\n+ le32 stream_id;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{result}]\n+ is\n+\n+ \\begin{description}\n+ \\item[VIRTIO_VIDEO_RESULT_OK]\n+ if the operation succeeded,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_OUT_OF_MEMORY]\n+ if the limit of simultaneous streams has been reached by the device and\n+ no more can be created.\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION]\n+ if the stream cannot be created due to an unexpected device issue.\n+ \\end{description}\n+\\item[\\field{stream_id}]\n+ is the ID of the created stream allocated by the device.\n+\\end{description}\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_CREATE}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_CREATE}\n+\n+\\field{stream_id} MUST be set to a device-unique identifier that remains\n+valid as long as the stream is alive.\n+\n+\\paragraph{VIRTIO_VIDEO_CMD_STREAM_DESTROY}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}\n+\n+% DESTROY has to be more like RESET, not DRAIN, because it is called, for\n+% example, when the guest user-space app closes a file descriptor. So there\n+% is no sense in continuing the processing.\n+\n+Destroy a video stream and all its resources. Any activity on the stream\n+is halted and all resources are released by the time the delayed response is\n+received by the driver.\n+\n+The driver sends this command with\n+\\field{struct virtio_video_stream_destroy}:\n+\n+\\begin{lstlisting}\n+struct virtio_video_stream_destroy {\n+ le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_DESTROY */\n+ le32 stream_id;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{stream_id}]\n+ is the ID of the stream to be destroyed, as previously returned by\n+ VIRTIO_VIDEO_CMD_STREAM_CREATE.\n+\\end{description}\n+\n+The device responds as described in\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+and begins the background DESTROY operation.\n+\n+When the command is completed the device sends the\n+VIRTIO_VIDEO_DELAYED_RESP_STREAM_DESTROY delayed response, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.\n+The delayed response can also come in case of unrecoverable stream error, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events / Error Event}.\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_DESTROY}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}\n+\n+Before the device sends a delayed response to VIRTIO_VIDEO_CMD_STREAM_DESTROY,\n+it MUST send all other pending delayed responses with\n+VIRTIO_VIDEO_EVENT_FLAG_CANCELED flag set and detach all resources.\n+\n+After VIRTIO_VIDEO_CMD_STREAM_DESTROY is queued, the device MUST reply with\n+VIRTIO_VIDEO_RESULT_ERR_INVALID_STREAM_ID to any subsequently queued command\n+with this stream ID.\n+\n+The DESTROY operation MUST NOT be canceled.\n+\n+\\drivernormative{\\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_DESTROY}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}\n+\n+\\field{stream_id} MUST be set to a valid stream ID previously returned\n+by VIRTIO_VIDEO_CMD_STREAM_CREATE.\n+\n+The driver MUST stop using \\field{stream_id} as a valid stream after it\n+received the delayed response to this command.\n+\n+\\paragraph{VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}\n+\n+Write values of selected parameters of a given stream, and receive back the\n+values for all the parameters supported by the device as reported by\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.\n+The operation can be either executed immediately, or queued into the INPUT\n+queue, i.e. after processing all the INPUT queue elements that are queued\n+before the command.\n+\n+The driver sends this command with\n+\\field{struct virtio_video_stream_set_params}:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_SET_PARAMS_FLAG_IN_BAND (1 << 0)\n+\n+struct virtio_video_stream_set_params {\n+ le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS */\n+ le32 stream_id;\n+ le32 flags; /* Bitmask of VIRTIO_VIDEO_SET_PARAMS_FLAG_* */\n+ u8 padding[4];\n+ struct virtio_video_params params;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{stream_id}]\n+ is the ID of the stream we want to set a parameter for.\n+\\item[\\field{flags}]\n+ is a bitmask of VIRTIO_VIDEO_SET_PARAMS_FLAG_* values.\n+\n+ \\begin{description}\n+ \\item[\\field{VIRTIO_VIDEO_SET_PARAMS_FLAG_IN_BAND}]\n+ The submitted parameters are to be set only after all of the previously\n+ queued INPUT queue elements are processed. Without this flag the\n+ parameters are set Immediately.\n+ \\end{description}\n+\\item[\\field{params}]\n+ is a container for the selected stream parameters to be set.\n+\\end{description}\n+\n+The device responds as described in\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+and begins the background SET_PARAMS operation.\n+\n+When the background processing of the resource is completed the device sends\n+the VIRTIO_VIDEO_DELAYED_RESP_STREAM_SET_PARAMS delayed response, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.\n+The delayed response can also come in case of dynamic parameters change, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events / Dynamic Parameters Change Event}.\n+\n+The command-specific delayed response\n+\\field{struct virtio_video_stream_set_params_delayed_resp} is defined\n+as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_stream_set_params_delayed_resp {\n+ struct virtio_video_params params;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{params}]\n+ is a container for the actual values of all the parameters supported by the\n+ device. The values set by the device may differ from the requested values\n+ depending on the device's capabilities.\n+\\end{description}\n+\n+The \\field{struct virtio_video_params} is defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_raw_format {\n+ le32 format;\n+ le32 planes_layout; /* VIRTIO_VIDEO_PLANES_LAYOUT_* */\n+ le32 stride;\n+ le32 width;\n+ le32 height;\n+ u8 padding[4];\n+};\n+\n+struct virtio_video_param_crop {\n+ le32 left;\n+ le32 top;\n+ le32 width;\n+ le32 height;\n+};\n+\n+union virtio_video_codec_params {\n+ struct virtio_video_mpeg2_params mpeg2;\n+ struct virtio_video_mpeg4_params mpeg4;\n+ struct virtio_video_h264_params h264;\n+ struct virtio_video_hevc_params hevc;\n+ struct virtio_video_vp8_params vp8;\n+ struct virtio_video_vp9_params vp9;\n+};\n+\n+struct virtio_video_params {\n+ le32 stream_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_PARAM_*) */\n+ le32 coded_format; /* If MASK(VIRTIO_VIDEO_PARAM_CODED_FORMAT) is set. */\n+ /* If MASK(VIRTIO_VIDEO_PARAM_RAW_FORMAT) is set. */\n+ struct virtio_video_raw_format raw_format;\n+ /* If MASK(VIRTIO_VIDEO_PARAM_CODED_RESOURCES) is set. */\n+ struct virtio_video_param_resources coded_resources;\n+ /* If MASK(VIRTIO_VIDEO_PARAM_RAW_RESOURCES) is set. */\n+ struct virtio_video_param_resources raw_resources;\n+ struct virtio_video_param_crop crop; /* If MASK(VIRTIO_VIDEO_PARAM_CROP) is set. */\n+ le32 bitrate; /* If MASK(VIRTIO_VIDEO_PARAM_BITRATE) is set. */\n+ u8 padding[4];\n+ /* If the corresponding MASK(VIRTIO_VIDEO_PARAM_GROUP_CODEC_*) is set\n+ * depending on the coded_format. */\n+ union virtio_video_codec_params codec;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{stream_params_bitmask}]\n+ is a bitmask of supported stream parameters.\n+\\item[\\field{coded_format}]\n+ is a coded format of the CODED queue, see\n+ \\ref{sec:Device Types / Video Device / Supported parameters}.\n+\\item[\\field{raw_format}]\n+ is a raw format of the RAW queue including related parameters\n+\n+ \\begin{description}\n+ \\item[\\field{format}]\n+ is the actual format, see\n+ \\ref{sec:Device Types / Video Device / Supported parameters / Supported raw formats}.\n+ \\item[\\field{planes_layout}]\n+ is the actual layout of the planes, see\n+ \\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}.\n+ \\item[\\field{stride}]\n+ is the distance in bytes between two lines of data.\n+ \\item[\\field{width}]\n+ is the width in pixels of the stream frames.\n+ \\item[\\field{height}]\n+ is the height in pixels of the stream frames.\n+ \\end{description}\n+\\item[\\field{coded_resources}]\n+ is the CODED queue resources parameters, see\n+ \\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.\n+\\item[\\field{raw_resources}]\n+ is the RAW queue resources parameters, see\n+ \\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.\n+\\item[\\field{crop}]\n+ is the rectangle covering the visible size of the frame, i.e the part of\n+ the frame that should be displayed, \\field{width} and \\field{height} are\n+ relative to \\field{left} and \\field{top}.\n+\\item[\\field{bitrate}]\n+ is the current desired bitrate for the encoder. This can be changed at\n+ any moment by the driver and will apply to subsequently submitted frames.\n+\\item[\\field{codec}]\n+ consists of codec-specific parameters, see\n+ \\ref{sec:Device Types / Video Device / Codec-specific parameters} for the\n+ definitions. Not available until \\field{coded_format} is set.\n+\\end{description}\n+\n+Successfully setting \\field{coded_format}, \\field{coded_resources},\n+\\field{raw_format} or \\field{raw_resources} starts with an implicit\n+background DRAIN operation if the corresponding queue has any queued\n+resources, then all the remaining elements in the queue are cancelled if\n+there are any and then all currently attached resources of the queue are\n+detached if there are any, i.e. the driver cannot queue a resource to the\n+queue without attaching some backing memory first.\n+\n+% Use-case: for the decoder, resolution can be set manually by the driver\n+% (useful for codecs that do not embed this information). The processing\n+% sequence should the look similar to the dynamic parameters change case.\n+\n+\\field{struct virtio_video_param_resources} is used to control the\n+number of resources and their backing memory type for the INPUT and\n+OUTPUT queues:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_MEM_TYPE_GUEST_PAGES 0x1\n+#define VIRTIO_VIDEO_MEM_TYPE_VIRTIO_OBJECT 0x2\n+\n+struct virtio_video_param_resources {\n+ le32 num_resources;\n+ u8 mem_type; /* VIRTIO_VIDEO_MEM_TYPE_* */\n+ u8 padding[3];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{num_resources}]\n+ is the number of resources that can be addressed for the queue, numbered\n+ from \\(0\\) to \\(num\\_resources - 1\\). Can be equal to zero if no\n+ resources are allocated, otherwise will be comprised between\n+ \\field{min_resources} and \\field{max_resources}.\n+\\item[\\field{mem_type}]\n+ is the memory type that will be used to back these resources.\n+\\end{description}\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}\n+\n+The device MUST initialize each parameter to a valid default value.\n+\n+The device MUST allow each parameter to be read even without the driver\n+explicitly setting a value for them beforehand.\n+\n+\\field{stream_params_bitmask} MUST be a subset of \\field{stream_params_bitmask}\n+field of \\field{struct virtio_video_device_query_caps_resp}.\n+\n+The fields \\field{coded_format}, \\field{raw_format}, \\field{coded_resources},\n+\\field{raw_resources}, \\field{bitrate}, \\field{codec} MUST be set according\n+to the capabilities returned by VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.\n+The conformance check MUST be performed before the command response is sent.\n+\n+\\field{stream_params_bitmask} MAY contain at most one of\n+VIRTIO_VIDEO_PARAM_GROUP_CODEC_* bits. This bit MUST correspond to the\n+coded format selected with \\field{coded_format}.\n+\n+The device MAY adjust any requested parameter to a closest supported\n+value if the requested one is not supported with the current settings.\n+\n+There MAY be at most one out of band SET_PARAMS operations at the same time.\n+The amount of in band SET_PARAMS operations at the same time MUST NOT exceed\n+the number of input resources.\n+\n+The parameters MUST be applied in the same order as in\n+\\ref{sec:Device Types / Video Device / Supported parameters / Supported stream parameters}.\n+\n+When \\field{coded_format}, \\field{coded_resources},\n+\\field{raw_format} or \\field{raw_resources} are being changed, the device\n+MUST first check if there are any queued resources in the corresponding\n+queue. If there are any the device MUST run a DRAIN operation in the same way\n+as with VIRTIO_VIDEO_CMD_STREAM_DRAIN except that sending\n+VIRTIO_VIDEO_DELAYED_RESP_STREAM_DRAIN MUST be omitted. Then the device MUST\n+cancel all remaining elements in the queue if there are any. Then the device\n+MUST detach all attached resources of the queue if there are any. Then the\n+device MUST set the requested parameters and send the delayed response. Any\n+subsequent operations using the queue MUST be blocked until the first\n+resource is attached and queued again. All these steps MUST be performed\n+before processing any subsequent commands.\n+\n+The device MUST process parameters changes, that are embedded in the input\n+stream, in the same way as if there is an in band\n+VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS command changing the OUTPUT queue\n+parameters. A standalone DPC event MUST be sent instead of the command's\n+delayed response in this case.\n+\n+The device MUST return all the available parameters in the delayed response\n+to the command. \\field{codec} is not available until \\field{coded_format}\n+is set.\n+\n+% TODO define when changing other parameters is allowed.\n+\n+\\drivernormative{\\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}\n+\n+\\field{stream_id} MUST be set to a valid stream ID previously returned\n+by VIRTIO_VIDEO_CMD_STREAM_CREATE.\n+\n+The driver MUST fill the fields according to the parameters selected with\n+\\field{stream_params_bitmask}. All the other fields MUST be set to zero.\n+\n+The driver MUST check the actual values of the parameters as set by the\n+device and work with these values, or try to set a different one if it\n+cannot, or fail properly.\n+\n+After creating a new stream, the initial value of all parameters is\n+undefined to the driver. Thus, the driver MUST NOT assume the default\n+value of any parameter and MAY use VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS\n+in order to get the values of the parameters it needs.\n+\n+The driver SHOULD NOT send any in band SET_PARAMS commands or QUEUE commands\n+on the INPUT queue before receiving the delayed response, when changing the\n+\\field{coded_format} or \\field{coded_resources} for decoder or\n+\\field{raw_format} or \\field{raw_resources} for encoder.\n+\n+If some of the resources were detached as a result of this command the\n+driver SHOULD maybe reallocate and reattach the backing memories of these\n+resources and queue them again to resume the device operation.\n+\n+\\paragraph{VIRTIO_VIDEO_CMD_STREAM_DRAIN}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}\n+\n+Complete processing of all INPUT queue elements queued before this command\n+and make the resulting output resources available to the driver.\n+\n+The driver sends this command with\n+\\field{struct virtio_video_stream_drain}:\n+\n+\\begin{lstlisting}\n+struct virtio_video_stream_drain {\n+ le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_DRAIN */\n+ le32 stream_id;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{stream_id}]\n+ is the ID of the stream to drain, as previously returned by\n+ VIRTIO_VIDEO_CMD_STREAM_CREATE.\n+\\end{description}\n+\n+The device responds as described in\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+and begins the background DRAIN operation.\n+\n+When the background DRAIN operation is completed the device sends the\n+VIRTIO_VIDEO_DELAYED_RESP_STREAM_DRAIN delayed response, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_DRAIN}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}\n+\n+Before the device sends the response, it MUST process and respond to all\n+the VIRTIO_VIDEO_CMD_RESOURCE_QUEUE commands on the INPUT queue that\n+were sent before the drain command, and make all the corresponding\n+output resources available to the driver by responding to their\n+VIRTIO_VIDEO_CMD_RESOURCE_QUEUE command.\n+\n+The device MUST be able to accept input work while a DRAIN operation\n+is ongoing, but any resulting delayed responses MUST NOT be sent before\n+the delayed response to the DRAIN command.\n+\n+The amount of DRAIN operations at the same time in the INPUT queue MUST NOT\n+exceed the number of input resources. The device MUST return\n+VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION if the number is exceeded.\n+\n+If the command is interrupted with a VIRTIO_VIDEO_CMD_STREAM_RESET\n+or VIRTIO_VIDEO_CMD_STREAM_DESTROY commands, the device MUST\n+send the delayed response with VIRTIO_VIDEO_EVENT_FLAG_CANCELED flag set.\n+\n+\\drivernormative{\\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_DRAIN}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}\n+\n+\\field{stream_id} MUST be set to a valid stream ID previously returned\n+by VIRTIO_VIDEO_CMD_STREAM_CREATE.\n+\n+The driver MUST keep queueing output resources until it gets the\n+response to this command or cancels it using\n+VIRTIO_VIDEO_CMD_STREAM_RESET or\n+VIRTIO_VIDEO_CMD_STREAM_DESTROY. Failure to do so may result in the\n+device stalling as it waits for output resources to write into.\n+\n+The driver MUST account for the fact that the response to this command\n+might come out-of-order (i.e. after other commands sent to the device),\n+and that it can be interrupted.\n+\n+The driver MUST send a DRAIN command when it does not have any further\n+input, in order to ensure it receives all the output corresponding to\n+the stream.\n+\n+\\paragraph{VIRTIO_VIDEO_CMD_STREAM_RESET}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}\n+\n+Immediately cancel all INPUT queue elements queued before this command\n+without processing them and discard any processing results in the output\n+resources, that are not yet dequeued. This command is mostly useful for\n+decoders that need to quickly jump from one point of the stream to another\n+(i.e. seeking), or in order to stop processing as quickly as possible.\n+\n+The driver sends this command with\n+\\field{struct virtio_video_stream_reset}:\n+\n+\\begin{lstlisting}\n+struct virtio_video_stream_reset {\n+ le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_RESET */\n+ le32 stream_id;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{stream_id}]\n+ is the ID of the stream to reset, as previously returned by\n+ VIRTIO_VIDEO_CMD_STREAM_CREATE.\n+\\end{description}\n+\n+The device responds as described in\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+and begins the background RESET operation.\n+\n+When the background RESET operation is completed the device sends the\n+VIRTIO_VIDEO_DELAYED_RESP_STREAM_RESET delayed response, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_RESET}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}\n+\n+The device MUST send delayed responses with VIRTIO_VIDEO_EVENT_FLAG_CANCELED\n+flag set for a background DRAIN operation and VIRTIO_VIDEO_CMD_RESOURCE_QUEUE\n+commands on the INPUT queue before responding to this command.\n+\n+While the device is processing the command, it MUST return\n+VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION to any subsequent\n+VIRTIO_VIDEO_CMD_STREAM_RESET commands.\n+\n+The device MUST be able to accept input work while a RESET operation\n+is ongoing, but any resulting delayed responses MUST NOT be sent before\n+the delayed response to the RESET command.\n+\n+The device MUST interrupt operation as quickly as possible, and not be\n+dependent on output resources being queued by the driver.\n+\n+Upon resuming processing, the device MAY skip input data until it finds\n+a point that allows it to resume operation properly (e.g. until a\n+keyframe is found in the input stream of a decoder).\n+\n+\\drivernormative{\\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_RESET}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}\n+\n+\\field{stream_id} MUST be set to a valid stream ID previously returned\n+by VIRTIO_VIDEO_CMD_STREAM_CREATE.\n+\n+Upon receiving the response to this command, the driver SHOULD process\n+(or drop) any output resource before resuming operation by queueing new\n+input resources.\n+\n+Upon receiving the response to this command, the driver MAY modify the\n+\\field{struct virtio_video_param_resources} parameter corresponding to\n+the INPUT queue, and subsequently attach new backing memory to the input\n+resources using the VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING\n+command.\n+\n+\\subsubsection{Device Operation: Resource Commands}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Resource Commands}\n+\n+Resource commands manage the memory backing of individual resources and\n+queue them for the device to process.\n+\n+\\paragraph{VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}\n+\n+Attach backing memory to a resource.\n+\n+The driver sends this command with\n+\\field{struct virtio_video_resource_attach_backing}:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_QUEUE_TYPE_INPUT 0\n+#define VIRTIO_VIDEO_QUEUE_TYPE_OUTPUT 1\n+\n+struct virtio_video_resource_attach_backing {\n+ le32 cmd_type; /* VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING */\n+ le32 stream_id;\n+ le32 queue_type; /* VIRTIO_VIDEO_QUEUE_TYPE_* */\n+ le32 resource_id;\n+ union virtio_video_resource resources[];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{stream_id}]\n+ is the ID of a valid stream.\n+\\item[\\field{queue_type}]\n+ is the direction of the queue.\n+\\item[\\field{resource_id}]\n+ is the ID of the resource to be attached to.\n+\\item[\\field{resources}]\n+ specifies memory regions to attach.\n+% TODO add number of resources?\n+\\end{description}\n+\n+The union \\field{virtio_video_resource} is defined as follows:\n+\n+\\begin{lstlisting}\n+union virtio_video_resource {\n+ struct virtio_video_resource_sg_list sg_list;\n+ struct virtio_video_resource_object object;\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{sg_list}]\n+ represents a scatter-gather list. This variant can be used when the\n+ \\field{mem_type} member of the \\field{virtio_video_param_resources}\n+ corresponding to the queue is set to\n+ VIRTIO_VIDEO_MEM_TYPE_GUEST_PAGES, see\n+ \\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.\n+\\item[\\field{object}]\n+ represents an object exported from another virtio device as defined in\n+ \\ref{sec:Basic Facilities of a Virtio Device / Exporting Objects}.\n+ This variant can be used when the \\field{mem_type} member of the\n+ \\field{virtio_video_param_resources} corresponding to the queue is set\n+ to VIRTIO_VIDEO_MEM_TYPE_VIRTIO_OBJECT, see\n+ \\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.\n+\\end{description}\n+\n+The struct \\field{virtio_video_resource_sg_list} is defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_resource_sg_entry {\n+ le64 addr;\n+ le32 length;\n+ u8 padding[4];\n+};\n+\n+struct virtio_video_resource_sg_list {\n+ le32 num_entries;\n+ u8 padding[4];\n+ /* Followed by num_entries instances of\n+ virtio_video_resource_sg_entry */\n+};\n+\\end{lstlisting}\n+\n+Within \\field{struct virtio_video_resource_sg_entry}:\n+\n+\\begin{description}\n+\\item[\\field{addr}]\n+ is a guest physical address to the start of the SG entry. Must be\n+ aligned to the size of physical guest pages.\n+\\item[\\field{length}]\n+ is the length of the SG entry in bytes. Must be aligned to the size\n+ of physical guest pages.\n+\\end{description}\n+\n+Finally, for \\field{struct virtio_video_resource_sg_list}:\n+\n+\\begin{description}\n+\\item[\\field{num_entries}]\n+ is the number of \\field{struct virtio_video_resource_sg_entry} instances\n+ that follow.\n+\\end{description}\n+\n+\\field{struct virtio_video_resource_object} is defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_resource_object {\n+ u8 uuid[16];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[uuid]\n+ is a version 4 UUID specified by \\hyperref[intro:rfc4122]{[RFC4122]}.\n+\\end{description}\n+\n+The device responds with\n+\\field{struct virtio_video_resource_attach_backing_resp}:\n+\n+\\begin{lstlisting}\n+struct virtio_video_resource_attach_backing_resp {\n+ le32 result; /* VIRTIO_VIDEO_RESULT_* */\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{result}]\n+ is\n+\n+ \\begin{description}\n+ \\item[VIRTIO_VIDEO_RESULT_OK]\n+ if the operation succeeded,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_INVALID_STREAM_ID]\n+ if the mentioned stream does not exist,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_INVALID_RESOURCE_ID]\n+ if the mentioned resource does not exist,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_INVALID_ARGUMENT]\n+ if \\field{queue_type} or \\field{resources} have an invalid value,\n+ \\item[VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION]\n+ if the operation is performed at a time when it is not valid.\n+ \\end{description}\n+\\end{description}\n+\n+VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING can only be called during\n+the following times:\n+\n+\\begin{itemize}\n+\\item\n+ AFTER a VIRTIO_VIDEO_CMD_STREAM_CREATE and BEFORE invoking\n+ VIRTIO_VIDEO_CMD_RESOURCE_QUEUE for the first time on the\n+ resource,\n+\\item\n+ AFTER successfully changing the \\field{virtio_video_param_resources}\n+ parameter corresponding to the queue and BEFORE\n+ VIRTIO_VIDEO_CMD_RESOURCE_QUEUE is called again on the resource.\n+\\end{itemize}\n+\n+This is to ensure that the device can rely on the fact that a given\n+resource will always point to the same memory for as long as it may be\n+used by the video device. For instance, a decoder may use returned\n+decoded frames as reference for future frames and won't overwrite the\n+backing resource of a frame that is being referenced. It is only before\n+a stream is started and after a Dynamic Parameters Change event has\n+occurred that we can be sure that all resources won't be used in that\n+way.\n+\n+% TODO add a requirement for the driver or the device to handle a case\n+% when a still referenced frame is queued again. So that it is less likely\n+% to be forgotten.\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}{Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}\n+\n+At any time other than the times valid for calling this command, the\n+device MUST return VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION.\n+\n+\\drivernormative{\\subparagraph}{VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}{Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}\n+\n+\\field{stream_id} MUST be set to a valid stream ID previously returned\n+by VIRTIO_VIDEO_CMD_STREAM_CREATE.\n+\n+\\field{queue_type} MUST be set to a valid queue type.\n+\n+\\field{resource_id} MUST be an integer inferior to the number of\n+resources currently allocated for the queue.\n+\n+The length of the \\field{resources} array of\n+\\field{struct virtio_video_resource_attach_backing} MUST be equal to the\n+number of resources required by the format currently set on the queue,\n+as described in\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.\n+\n+\\paragraph{VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}\n+\n+Add a resource to the device's queue.\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_MAX_PLANES 8\n+\n+#define VIRTIO_VIDEO_ENQUEUE_FLAG_FORCE_KEY_FRAME (1 << 0)\n+\n+struct virtio_video_resource_queue {\n+ le32 cmd_type; /* VIRTIO_VIDEO_CMD_RESOURCE_QUEUE */\n+ le32 stream_id;\n+ le32 queue_type; /* VIRTIO_VIDEO_QUEUE_TYPE_* */\n+ le32 resource_id;\n+ le32 flags; /* Bitmask of VIRTIO_VIDEO_ENQUEUE_FLAG_* */\n+ u8 padding[4];\n+ le64 timestamp;\n+ le32 offsets[VIRTIO_VIDEO_MAX_PLANES];\n+ le32 data_sizes[VIRTIO_VIDEO_MAX_PLANES];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{stream_id}]\n+ is the ID of a valid stream.\n+\\item[\\field{queue_type}]\n+ is the direction of the queue.\n+\\item[\\field{resource_id}]\n+ is the ID of the resource to be queued.\n+\\item[\\field{flags}]\n+ is a bitmask of VIRTIO_VIDEO_ENQUEUE_FLAG_* values.\n+\n+ \\begin{description}\n+ \\item[\\field{VIRTIO_VIDEO_ENQUEUE_FLAG_FORCE_KEY_FRAME}]\n+ The submitted frame is to be encoded as a key frame. Only valid for the\n+ encoder's INPUT queue.\n+ \\end{description}\n+\\item[\\field{timestamp}]\n+ is an abstract sequence counter that can be used on the INPUT queue for\n+ synchronization. Resources produced on the output queue will carry the\n+ \\field{timestamp} of the first input resource they have been produced\n+ from.\n+% TODO take note about timestamps from V4L2 spec\n+\\item[\\field{offsets}]\n+ is the starting offset for the data in the buffer for each plane.\n+ The number of planes depends on the format. Set by the driver for input\n+ resources.\n+\\item[\\field{data_sizes}]\n+ is number of data bytes used for each plane. Set by the driver for input\n+ resources.\n+\\end{description}\n+\n+The device responds as described in\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+and puts the resource in the selected queue for background processing.\n+\n+When the background processing of the resource is completed the device sends\n+the VIRTIO_VIDEO_DELAYED_RESP_RESOURCE_QUEUE delayed response, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.\n+\n+The command-specific delayed response\n+\\field{struct virtio_video_resource_queue_delayed_resp} is defined\n+as follows:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_DEQUEUE_FLAG_ERR (1 << 0)\n+/* Encoder only */\n+#define VIRTIO_VIDEO_DEQUEUE_FLAG_KEY_FRAME (1 << 1)\n+#define VIRTIO_VIDEO_DEQUEUE_FLAG_P_FRAME (1 << 2)\n+#define VIRTIO_VIDEO_DEQUEUE_FLAG_B_FRAME (1 << 3)\n+\n+struct virtio_video_resource_queue_delayed_resp {\n+ le32 queue_type; /* VIRTIO_VIDEO_QUEUE_TYPE_* */\n+ le32 resource_id;\n+ le32 flags;\n+ u8 padding[4];\n+ le64 timestamp;\n+ le32 offsets[VIRTIO_VIDEO_MAX_PLANES];\n+ le32 data_sizes[VIRTIO_VIDEO_MAX_PLANES];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{queue_type}]\n+ is the direction of the queue.\n+\\item[\\field{resource_id}]\n+ is the ID of the dequeued resource.\n+\\item[\\field{flags}]\n+ is a bitmask of VIRTIO_VIDEO_DEQUEUE_FLAG_* flags.\n+\n+ \\begin{description}\n+ \\item[VIRTIO_VIDEO_DEQUEUE_FLAG_ERR]\n+ is set on resources when a non-fatal processing error has happened and\n+ the data contained by the resource is likely to be corrupted,\n+ \\item[VIRTIO_VIDEO_DEQUEUE_FLAG_KEY_FRAME]\n+ is set on output resources when the resource contains an encoded key\n+ frame (only for encoders).\n+ \\item[VIRTIO_VIDEO_DEQUEUE_FLAG_P_FRAME]\n+ is set on output resources when the resource contains only differences\n+ to a previous key frame (only for encoders).\n+ \\item[VIRTIO_VIDEO_DEQUEUE_FLAG_B_FRAME]\n+ is set on output resources when the resource contains only the\n+ differences between the current frame and both the preceding and\n+ following key frames (only for encoders).\n+ \\end{description}\n+\\item[\\field{timestamp}]\n+ is set on output resources to the \\field{timestamp} value of the input\n+ resource that produced the resource.\n+\\item[\\field{offsets}]\n+ is set on output resources to the starting offset for the data in the\n+ buffer for each plane.\n+\\item[\\field{data_sizes}]\n+ is set on output resources to the amount of data written by the device,\n+ for each plane.\n+\\end{description}\n+\n+\\devicenormative{\\subparagraph}{VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}{Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}\n+\n+The device MUST return VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION if\n+VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING has not been\n+successfully called on the resource prior to queueing it or for an\n+attempt to queue a resources that is still processed in background.\n+\n+The device MUST mark resources that might contain corrupted content due to\n+an error with the VIRTIO_VIDEO_BUFFER_FLAG_ERR flag.\n+\n+For output resources, the device MUST copy the \\field{timestamp}\n+parameter of the input resource that produced it into its response.\n+% TODO rephrase?\n+\n+In case of encoder, the device MUST mark each output resource with one\n+of VIRTIO_VIDEO_DEQUEUE_FLAG_KEY_FRAME,\n+VIRTIO_VIDEO_DEQUEUE_FLAG_P_FRAME, or\n+VIRTIO_VIDEO_DEQUEUE_FLAG_B_FRAME.\n+\n+If the processing of a resource was stopped due to a stream event, a\n+VIRTIO_VIDEO_CMD_STREAM_RESET, or a VIRTIO_VIDEO_CMD_STREAM_DESTROY,\n+the device MUST send the corresponding delayed responses with\n+VIRTIO_VIDEO_EVENT_FLAG_CANCELED flag set.\n+\n+\\drivernormative{\\subparagraph}{VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}{Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}\n+\n+\\field{stream_id} MUST be set to a valid stream ID previously returned\n+by VIRTIO_VIDEO_CMD_STREAM_CREATE.\n+\n+\\field{queue_type} MUST be set to a valid queue type.\n+\n+\\field{resource_id} MUST be an integer inferior to the number of\n+resources currently allocated for the queue.\n+\n+The driver MUST account for the fact that the response to this command\n+might come out-of-order (i.e. after other commands sent to the device),\n+and that it can be interrupted.\n+\n+% TODO acourbot: The driver and device MUST follow requirements about\n+% buffer ownership explained in\n+% \\ref{sec:Device Types / Video Device / Device Operation / Buffer lifecycle}.\n+\n+\\subsubsection{Device Operation: Standalone Events}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events}\n+\n+These events are caused by state changes in the device, not as a delayed\n+response to any command.\n+\n+\\paragraph{Error Event}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events / Error Event}\n+\n+The error event is sent by the device when an unrecoverable error occurs\n+during processing a stream. The device operation is exactly the same as when\n+it receives a VIRTIO_VIDEO_CMD_STREAM_DESTROY command, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}.\n+Note that this is different from dequeued resources carrying the\n+VIRTIO_VIDEO_DEQUEUE_FLAG_ERR flag. This flag indicates that the\n+particular output frame might be corrupted, but the stream still exists\n+and can recover.\n+\n+\\paragraph{Dynamic Parameters Change Event}\n+\\label{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events / Dynamic Parameters Change Event}\n+\n+A Dynamic Parameters Change (or DPC) event is sent by a decoder device when it\n+detects that the parameters of the stream being decoded have changed.\n+The device operation is exactly the same as when it receives an in band\n+VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS command at the exact same point in the\n+stream, that changes OUTPUT queue parameters, see\n+\\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.\n+\n+% TODO add QoS events and overall think about quotas. Codecs are normally\n+% limited by bandwidth. How can we accommodate this?\n+\n+\\subsection{Codec-specific parameters}\n+\\label{sec:Device Types / Video Device / Codec-specific parameters}\n+\n+The codec-specific controls follow V4L2 controls definitions, that can be\n+found in \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+Human-readable descriptions for the codec-specific V4L2 controls can be found\n+in \\hyperref[intro:V4L2 codec controls]{V4L2 documentation}.\n+\n+\\subsubsection{MPEG2}\n+\n+MPEG2 capabilities are defined as follows:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_MPEG2_PARAM_PROFILE 1 /* Same as V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE */\n+#define VIRTIO_VIDEO_MPEG2_PARAM_LEVEL 2 /* Same as V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL */\n+\n+struct virtio_video_mpeg2_caps {\n+ le32 mpeg2_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_MPEG2_PARAM_*) */\n+ le32 mpeg2_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_MPEG2_PROFILE_*) */\n+ le32 mpeg2_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_MPEG2_LEVEL_*) */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{mpeg2_params_bitmask}]\n+ is a bitmask of supported MPEG2 codec parameters.\n+\\item[\\field{mpeg2_profiles_bitmask}]\n+ is a bitmask of supported MPEG2 profiles used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_mpeg2_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{mpeg2_levels_bitmask}]\n+ is a bitmask of supported MPEG2 levels used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_mpeg2_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+MPEG2 parameters are defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_mpeg2_params {\n+ le32 mpeg2_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_MPEG2_PARAM_*) */\n+ le32 mpeg2_profile; /* V4L2_MPEG_VIDEO_MPEG2_PROFILE_* */\n+ le32 mpeg2_level; /* V4L2_MPEG_VIDEO_MPEG2_LEVEL_* */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{mpeg2_params_bitmask}]\n+ is a bitmask of supported MPEG2 codec parameters.\n+\\item[\\field{mpeg2_profile}]\n+ is one of the supported MPEG2 profiles, see\n+ \\field{enum v4l2_mpeg_video_mpeg2_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{mpeg2_level}]\n+ is one of the supported MPEG2 levels, see\n+ \\field{enum v4l2_mpeg_video_mpeg2_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+\\subsubsection{MPEG4}\n+\n+MPEG4 capabilities are defined as follows:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_MPEG4_PARAM_PROFILE 1 /* Same as V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE */\n+#define VIRTIO_VIDEO_MPEG4_PARAM_LEVEL 2 /* Same as V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL */\n+\n+struct virtio_video_mpeg4_caps {\n+ le32 mpeg4_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_MPEG4_PARAM_*) */\n+ le32 mpeg4_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_MPEG4_PROFILE_*) */\n+ le32 mpeg4_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_MPEG4_LEVEL_*) */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{mpeg4_params_bitmask}]\n+ is a bitmask of supported MPEG4 codec parameters.\n+\\item[\\field{mpeg4_profiles_bitmask}]\n+ is a bitmask of supported MPEG4 profiles used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_mpeg4_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{mpeg4_levels_bitmask}]\n+ is a bitmask of supported MPEG4 levels used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_mpeg4_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+MPEG4 parameters are defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_mpeg4_params {\n+ le32 mpeg4_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_MPEG4_PARAM_*) */\n+ le32 mpeg4_profile; /* V4L2_MPEG_VIDEO_MPEG4_PROFILE_* */\n+ le32 mpeg4_level; /* V4L2_MPEG_VIDEO_MPEG4_LEVEL_* */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{mpeg4_params_bitmask}]\n+ is a bitmask of supported MPEG4 codec parameters.\n+\\item[\\field{mpeg4_profile}]\n+ is one of the supported MPEG4 profiles, see\n+ \\field{enum v4l2_mpeg_video_mpeg4_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{mpeg4_level}]\n+ is one of the supported MPEG4 levels, see\n+ \\field{enum v4l2_mpeg_video_mpeg4_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+\\subsubsection{H.264}\n+\n+H.264 capabilities are defined as follows:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_H264_PARAM_PROFILE 1 /* Same as V4L2_CID_MPEG_VIDEO_H264_PROFILE */\n+#define VIRTIO_VIDEO_H264_PARAM_LEVEL 2 /* Same as V4L2_CID_MPEG_VIDEO_H264_LEVEL */\n+\n+struct virtio_video_h264_caps {\n+ le32 h264_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_H264_PARAM_*) */\n+ le32 h264_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_H264_PROFILE_*) */\n+ le32 h264_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_H264_LEVEL_*) */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{h264_params_bitmask}]\n+ is a bitmask of supported H.264 codec parameters.\n+\\item[\\field{h264_profiles_bitmask}]\n+ is a bitmask of supported H.264 profiles used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_h264_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{h264_levels_bitmask}]\n+ is a bitmask of supported H.264 levels used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_h264_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+H.264 parameters are defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_h264_params {\n+ le32 h264_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_H264_PARAM_*) */\n+ le32 h264_profile; /* V4L2_MPEG_VIDEO_H264_PROFILE_* */\n+ le32 h264_level; /* V4L2_MPEG_VIDEO_H264_LEVEL_* */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{h264_params_bitmask}]\n+ is a bitmask of supported H.264 codec parameters.\n+\\item[\\field{h264_profile}]\n+ is one of the supported H.264 profiles, see\n+ \\field{enum v4l2_mpeg_video_h264_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{h264_level}]\n+ is one of the supported H.264 levels, see\n+ \\field{enum v4l2_mpeg_video_h264_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+\\subsubsection{HEVC}\n+\n+HEVC capabilities are defined as follows:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_HEVC_PARAM_PROFILE 1 /* Same as V4L2_CID_MPEG_VIDEO_HEVC_PROFILE */\n+#define VIRTIO_VIDEO_HEVC_PARAM_LEVEL 2 /* Same as V4L2_CID_MPEG_VIDEO_HEVC_LEVEL */\n+\n+struct virtio_video_hevc_caps {\n+ le32 hevc_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_HEVC_PARAM_*) */\n+ le32 hevc_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_HEVC_PROFILE_*) */\n+ le32 hevc_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_HEVC_LEVEL_*) */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{hevc_params_bitmask}]\n+ is a bitmask of supported HEVC codec parameters.\n+\\item[\\field{hevc_profiles_bitmask}]\n+ is a bitmask of supported HEVC profiles used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_hevc_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{hevc_levels_bitmask}]\n+ is a bitmask of supported HEVC levels used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_hevc_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+HEVC parameters are defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_hevc_params {\n+ le32 hevc_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_HEVC_PARAM_*) */\n+ le32 hevc_profile; /* V4L2_MPEG_VIDEO_HEVC_PROFILE_* */\n+ le32 hevc_level; /* V4L2_MPEG_VIDEO_HEVC_LEVEL_* */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{hevc_params_bitmask}]\n+ is a bitmask of supported HEVC codec parameters.\n+\\item[\\field{hevc_profile}]\n+ is one of the supported HEVC profiles, see\n+ \\field{enum v4l2_mpeg_video_hevc_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{hevc_level}]\n+ is one of the supported HEVC levels, see\n+ \\field{enum v4l2_mpeg_video_hevc_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+\\subsubsection{VP8}\n+\n+VP8 capabilities are defined as follows:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_VP8_PARAM_PROFILE 1 /* Same as V4L2_CID_MPEG_VIDEO_VP8_PROFILE */\n+\n+struct virtio_video_vp8_caps {\n+ le32 vp8_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_VP8_PARAM_*) */\n+ le32 vp8_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_VP8_PROFILE_*) */\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{vp8_params_bitmask}]\n+ is a bitmask of supported VP8 codec parameters.\n+\\item[\\field{vp8_profiles_bitmask}]\n+ is a bitmask of supported VP8 profiles used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_vp8_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+VP8 parameters are defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_vp8_params {\n+ le32 vp8_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_VP8_PARAM_*) */\n+ le32 vp8_profile; /* V4L2_MPEG_VIDEO_VP8_PROFILE_* */\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{vp8_params_bitmask}]\n+ is a bitmask of supported VP8 codec parameters.\n+\\item[\\field{vp8_profile}]\n+ is one of the supported VP8 profiles, see\n+ \\field{enum v4l2_mpeg_video_vp8_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+\\subsubsection{VP9}\n+\n+VP9 capabilities are defined as follows:\n+\n+\\begin{lstlisting}\n+#define VIRTIO_VIDEO_VP9_PARAM_PROFILE 1 /* Same as V4L2_CID_MPEG_VIDEO_VP9_PROFILE */\n+#define VIRTIO_VIDEO_VP9_PARAM_LEVEL 2 /* Same as V4L2_CID_MPEG_VIDEO_VP9_LEVEL */\n+\n+struct virtio_video_vp9_caps {\n+ le32 vp9_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_VP9_PARAM_*) */\n+ le32 vp9_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_VP9_PROFILE_*) */\n+ le32 vp9_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_VP9_LEVEL_*) */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{vp9_params_bitmask}]\n+ is a bitmask of supported VP9 codec parameters.\n+\\item[\\field{vp9_profiles_bitmask}]\n+ is a bitmask of supported VP9 profiles used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_vp9_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{vp9_levels_bitmask}]\n+ is a bitmask of supported VP9 levels used as bit numbers, see\n+ \\field{enum v4l2_mpeg_video_vp9_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\n+\n+VP9 parameters are defined as follows:\n+\n+\\begin{lstlisting}\n+struct virtio_video_vp9_params {\n+ le32 vp9_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_VP9_PARAM_*) */\n+ le32 vp9_profile; /* V4L2_MPEG_VIDEO_VP9_PROFILE_* */\n+ le32 vp9_level; /* V4L2_MPEG_VIDEO_VP9_LEVEL_* */\n+ u8 padding[4];\n+};\n+\\end{lstlisting}\n+\n+\\begin{description}\n+\\item[\\field{vp9_params_bitmask}]\n+ is a bitmask of supported VP9 codec parameters.\n+\\item[\\field{vp9_profile}]\n+ is one of the supported VP9 profiles, see\n+ \\field{enum v4l2_mpeg_video_vp9_profile} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\item[\\field{vp9_level}]\n+ is one of the supported VP9 levels, see\n+ \\field{enum v4l2_mpeg_video_vp9_level} in\n+ \\hyperref[intro:V4L2 controls]{V4L2 controls header}.\n+\\end{description}\ndiff --git a/device-types/video/device-conformance.tex b/device-types/video/device-conformance.tex\nnew file mode 100644\nindex 0000000..8aaf744\n--- /dev/null\n+++ b/device-types/video/device-conformance.tex\n@@ -0,0 +1,22 @@\n+\\conformance{\\subsection}{Video Device Conformance}\n+\\label{sec:Conformance / Device Conformance / Video Device Conformance}\n+\n+A video device MUST conform to the following normative statements:\n+\n+\\begin{itemize}\n+\\item \\ref{devicenormative:Device Types / Video Device / Feature bits}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device configuration layout}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Format dependencies}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Resource capabilities}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Bitrates}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_CREATE}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}\n+\\item \\ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}\n+\\end{itemize}\ndiff --git a/device-types/video/driver-conformance.tex b/device-types/video/driver-conformance.tex\nnew file mode 100644\nindex 0000000..1fe8473\n--- /dev/null\n+++ b/device-types/video/driver-conformance.tex\n@@ -0,0 +1,16 @@\n+\\conformance{\\subsection}{Video Driver Conformance}\n+\\label{sec:Conformance / Driver Conformance / Video Driver Conformance}\n+\n+A video driver MUST conform to the following normative statements:\n+\n+\\begin{itemize}\n+\\item \\ref{drivernormative:Device Types / Video Device / Feature bits}\n+\\item \\ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}\n+\\item \\ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}\n+\\item \\ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}\n+\\item \\ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}\n+\\item \\ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}\n+\\item \\ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}\n+\\item \\ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}\n+\\item \\ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}\n+\\end{itemize}\ndiff --git a/introduction.tex b/introduction.tex\nindex b7155bf..b378883 100644\n--- a/introduction.tex\n+++ b/introduction.tex\n@@ -101,6 +101,15 @@ \\section{Normative References}\\label{sec:Normative References}\n \t\\phantomsection\\label{intro:SEC1}\\textbf{[SEC1]} &\n Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.\n \t\\newline\\url{https://www.secg.org/sec1-v2.pdf}\\\\\n+\t\\phantomsection\\label{intro:V4L2}\\textbf{[V4L2]} &\n+\tLinux V4L2 interface.\n+\t\\newline\\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/videodev2.h}\\\\\n+\t\\phantomsection\\label{intro:V4L2 controls}\\textbf{[V4L2 Controls]} &\n+\tLinux V4L2 controls definitions.\n+\t\\newline\\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/v4l2-controls.h}\\\\\n+\t\\phantomsection\\label{intro:DRM formats}\\textbf{[DRM Formats]} &\n+\tLinux DRM format definitions.\n+\t\\newline\\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h}\\\\\n \n \\end{longtable}\n \n@@ -110,6 +119,18 @@ \\section{Non-Normative References}\n \t\\phantomsection\\label{intro:Virtio PCI Draft}\\textbf{[Virtio PCI Draft]} &\n \tVirtio PCI Draft Specification\n \t\\newline\\url{http://ozlabs.org/~rusty/virtio-spec/virtio-0.9.5.pdf}\\\\\n+\t\\phantomsection\\label{intro:V4L2 compressed}\\textbf{[V4L2 compressed formats]} &\n+\tDetailed descriptions of V4L2 compressed formats\n+\t\\newline\\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst}\\\\\n+\t\\phantomsection\\label{intro:V4L2 RGB}\\textbf{[V4L2 RGB formats]} &\n+\tDetailed descriptions of V4L2 RGB formats\n+\t\\newline\\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst}\\\\\n+\t\\phantomsection\\label{intro:V4L2 YUV}\\textbf{[V4L2 planar YUV formats]} &\n+\tDetailed descriptions of V4L2 planar YUV formats\n+\t\\newline\\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst}\\\\\n+\t\\phantomsection\\label{intro:V4L2 codec controls}\\textbf{[V4L2 codec controls]} &\n+\tDetailed descriptions of V4L2 controls\n+\t\\newline\\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst}\\\\\n \\end{longtable}\n \n \\section{Terminology}\\label{Terminology}\n", "prefixes": [ "libcamera-devel", "RFC", "v8", "1/1" ] }