LWN：处理复杂摄像头！

关注了就能看到更多这么棒的文章哦～

Coping with complex cameras

By Jonathan Corbet
October 3, 2024
LPC
Gemini-1.5-flash translation
https://lwn.net/Articles/992411/

摄像头从来都不是 Linux 中特别容易支持的那类设备；它们有各种各样的运行参数，并且可以生成大量数据。然而，近年来，摄像头变得越来越复杂，这给内核的 媒体子系统（media subsystem） 管理它们的能力带来了压力。在 2024 年 Linux Plumbers Conference，来自该子系统和更多领域的开发者聚集在一起，讨论了现状以及如何支持未来复杂的摄像头设备。

复杂摄像头峰会（The complex-camera summit）

Ricardo Ribalda 主持了会议，首先总结了前一天举行的闭门复杂摄像头峰会。 “复杂摄像头” 这些看似简单的设备内置于手机、笔记本电脑和其他移动设备中。 这些设备确实按预期收集图像数据，但作为此任务的一部分，它们还会对传感器返回的数据进行大量信号处理。这些处理（包括去马赛克、降噪、锐化、白平衡校正、图像稳定、自动对焦控制、对比度调整、高动态范围处理、人脸识别等）在内存中由一个可配置的单元流水线执行，该流水线被称为图像信号处理器 (ISP)。

许多功能通过一个直接抵达用户空间的反馈回路（feedback loop）进行控制。 ISP 必须提供大量数据来控制要执行的处理；这些参数加起来可能达到 500KB 左右的数据——对于处理器处理的每一帧来说。 当然，控制数据的格式往往是专有的，并且每个 ISP 都不一样。

Ribalda 首先说，这些设备的供应商希望使用内核现有的媒体接口（通常称为 Video4Linux 或 V4L），但该子系统不是为这种内存到内存的 ISP 设计的。 每个帧都需要多个 ioctl() 调用，这增加了许多开销。 V4L 没有为异步操作的管理提供栅栏（fence）；过去曾尝试添加栅栏，但没有成功。 没有抽象的先进的操作调度，也不支持将多个缓冲区发送到 ISP 并由其决定哪些缓冲区是重要的。 他说，现代手机需要的多摄像头支持在 V4L 中是缺失的。

供应商认为 V4L API 的演进速度太慢，无法跟上现代摄像头的步伐。 至少在短期内，供应商只需为他们的硬件编写针对特定设备的驱动程序，这样会更快。但这会导致相同功能的多个 API，从而导致碎片化。

人们一直谈论将这些设备的支持转移到直接渲染管理器 (DRM) 子系统，与图形处理器并列，但 DRM 开发人员不是摄像头专家。 还有人希望创建直通接口，让用户空间直接与设备通信（这是一个在几天前的维护人员峰会上被 广泛讨论 的主题），但允许这样的 API 需要相信供应商，而供应商又没有足够信任内核社区来提供有关其设备工作原理的详细信息。

Ribalda 说，复杂摄像头峰会的结论是，V4L 开发人员希望看到支持复杂摄像头设备所需的所有技术特性的完整列表。 然后他们将努力解决这些缺陷。 他说，如果他们在合理的时间内无法做到这一点，他们同意不会阻止将 ISP 驱动程序合并到 DRM 子系统中，可能使用直通 API。

Ribalda 继续说，还有一些非技术性的挑战。 不仅仅是这些 ISP 的许多方面没有记录；供应商声称他们 无法 记录。 这一领域似乎充满了专利和“特殊秘诀”；供应商不想透露他们的硬件工作原理。 但 V4L 子系统目前要求对用户空间用户可以控制的任何功能进行文档化。 目前，该策略意味着未记录的功能无法使用；然而，更改该策略可能会导致 所有 功能都变得没有记录。

峰会上提出的一个解决方案是描述一个“规范 ISP”，该 ISP 具有所有这些设备都应该具有的功能；这些功能需要以标准的方式完全记录和实现。 ISP 提供的所有其他功能都可以通过直通接口直接连接到用户空间。 这将允许在无需记录设备执行的所有操作的情况下，使功能可用。

当然，这种方法也存在问题，他说。 直通接口会引发安全问题。 内核不知道设备在做什么，例如，它无法阻止设备被告知覆盖内核中不相关的数据。 这些设备需要针对 ISP、传感器和镜头的每种组合进行校准；如果没有完整的文档，就无法进行校准。 而且，自然地，关于规范 ISP 应该做什么会有分歧；供应商会推动以最少的实现为目标。

另一种方法是完全忽略专有功能，只记录设备的基本功能。 然后，供应商将提供一个树外驱动程序来使设备按预期工作。 不过，在这个世界里，供应商不太可能费心开发一个上游驱动程序。 这将难以被发行版和用户管理。

应该怎么做

这些介绍之后，围绕着如何正确处理复杂摄像头问题展开了一场热烈、漫长、游离且时常喧嚣的讨论。这场讨论也超出了预定的时间。为了避免记录下所有内容，以下试图概括最主要的观点。对于在此未提及贡献的参与者，我们深表歉意。

很明显，封闭峰会没有在会上达成共识。几乎每个方面都在某个时刻受到质疑。尽管如此，它们为接下来的讨论提供了一个有用的起点。

V4L 维护者 Hans Verkuil 断言，根据他的经验，供应商要求的设备特定功能并非真的只存在于某个设备中；他说，这种功能应该在接口中进行泛化。DRM 层需要 Mesa（在用户空间中）支持新驱动程序；这就是 API 标准化的级别。V4L，他说，缺乏等同于 Mesa 的东西，因此内核 API 就是 标准接口。

现在，libcamera 库正在接管为摄像头设备提供“真正”接口的角色，这可能会改变这种情况。供应商特定的支持可以在那里实现，对用户隐藏。因此，最好的解决方案可能是要求为复杂的摄像头驱动程序提供 libcamera 接口。同时，V4L 接口仍然需要用来控制任何处理链的传感器部分；如果 V4L 支持迟迟未到，或许可以将代码移动到 DRM 用于 ISP 部分。媒体子系统维护者 Mauro Carvalho Chehab 同意，libcamera 使 DRM 类似模型更可行。

DRM 子系统维护者 Dave Airlie 表示，V4L 子系统的现有架构根本不适合现代摄像头设备。他说，它与 20 年前的 DRM 处境相同，当时该子系统不得不从编程设备寄存器痛苦地过渡到通过环形缓冲区与用户空间交换命令和数据。他说，如果存在一个 libcamera API 可以以通用方式描述这些设备，那么在 libcamera 支持出现之前，不应合并特定设备的内核驱动程序。然后，他说，生态系统会随着时间的推移自行解决。

他后来补充说，他不希望在 DRM 子系统中使用摄像头驱动程序，因为 DRM 子系统并非为此设计；尽管如此，他愿意接受它们，如果需要的话。他实际上希望 V4L 到现在已经发展出一些类似 DRM 的功能；这就是问题所在。

他说，从 DRM 世界中汲取的教训是，直接去构建一些东西，情况会随着时间的推移而改善。拥有更好驱动程序的供应商将在市场上胜出。他建议不要为驱动程序的接受制定具体规则，因为供应商总是会试图钻空子。相反，每个驱动程序都应该在与供应商协商后合并，随着时间的推移，要求也会逐步提高。这可能意味着最初会允许一些不好的代码，尤其是来自早期合作的供应商的代码，但随着子系统整体质量的提高，门槛可以提高。

关于 ISP 实际上与 DRM 子系统驱动的 GPU 匹配程度，有一些讨论。Sakari Ailus 说，它们不同；它们是由用户空间配置的处理块管道。只有一个真正的命令：“处理一帧（process a frame）”。libcamera 开发者 Laurent Pinchart 表示，目前 ISP 模型不涉及环形缓冲区；相反，用户空间为每帧要处理的数据提交大量配置数据。两人似乎都认为，DRM 方法可能不适用于这种类型的设备。

但是，Daniel Stone 说，有一些 GPU 以类似的编程模型运行；它们并不都具有环形缓冲区。他强烈反对这种说法，即如果提供直通功能，供应商将没有动力将他们的驱动程序推送给上游。他说，通常情况下，并不是供应商首先做这项工作。Arm GPU 驱动程序是由 Collabora 实现的；Arm 现在才开始协助这项工作。他说，很多人想要开放的驱动程序，并愿意为这项工作付费。因此，他同意 Airlie 的观点，即市场会随着时间的推移自行解决。最终，参与这一过程的制造商将做得更好。

几位参与者不同意供应商需要出于专利或竞争原因将硬件的某些方面保密的观点。正如技术行业其他地方一样，公司非常清楚竞争对手在做什么。Airlie 补充说，所有这些公司都在互相抄袭工作，这得益于在公司之间自由流动的工程师。

还讨论了允许直通驱动程序是否会促进对硬件的完全逆向工程。Pinchart 表示，每帧的大量参数使得逆向工程变得困难。Stone 回复说，这种论点暗示 ISP 不同于任何其他设备，或者与它们合作的工程师不如其他人；他说，两者都不正确。Airlie 补充说，人们也曾经这样说虚拟现实（VR）头戴设备，但后来“一个人想通了”，免费的驱动程序被创建出来了。Pinchart 说，这些设备的常规文档不足以编写驱动程序，再次引发了普遍的反对。

目标

房间里的开发者试图至少在他们试图达成的目标上达成一致。所需 API 的形式目前尚不清楚，尽管 Pinchart 说它不应该在内核中强迫大量计算。Airlie 建议将所有应用程序推向使用 libcamera；最终，开发人员会更喜欢 libcamera，而不是使用专有堆栈。Pinchart 担心允许直通功能会倒退供应商迄今为止取得的进展。因此，至少某些功能必须成为标准 API 的一部分；他说，难点在于决定哪些功能。

Pinchart 说，似乎有一项粗略协议，即应该要求供应商提供一定级别的功能才能合并驱动程序，但他想知道这些要求应该如何设定。Airlie 重申，这里的硬性规则会被钻空子，应该与每个供应商进行协商。他说，如果与一个供应商友好相处能推进情况，那就“大胆去做”。Pinchart 担心供应商和社区都可能反对。Airlie 说，他只是告诉抱怨的供应商离开，但早期合作的供应商在很大程度上是/社区/。

几位开发者表示，要求可能会因每个设备所面向的市场而异。对于针对 Chromebook 的摄像头，足以提供能够进行基本视频会议的开放功能。但是，对于在其他环境中使用的摄像头，门槛可能更高，需要提供更多由代码树内的驱动程序提供的功能。一些开发者建议设置一个最低图像质量要求，但这很难执行；正确测量图像质量需要一个设备齐全（且昂贵）的实验室。

随着这场持续数小时的会议超时，Ribalda 做了一些尝试来提炼出一套共识结论，但他并没有取得很大成功。尽管如此，这场讨论似乎取得了一些进展。过去，其他内核子系统不得不解决这个问题，从而积累了大量可以借鉴的经验。Linux 中对复杂摄像头设备的支持很可能在一段时间内会很混乱且专有，但幸运的是，它会慢慢改善。

[ 感谢 Linux 基金会，LWN 的旅行赞助商，支持我们前往该活动。 ]

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～