Deepin 25 上 Intel IPU6 / hi556 摄像头修复与按需虚拟摄像头指南
最后验证日期:2026-09-25
本机环境:Deepin 25(crimson)、Linux6.18.48-amd64-desktop-rolling、Intel Alder Lake IPU68086:465d、hi556 MIPI 摄像头。
最终效果:应用可在IPU6 Camera 360p(/dev/video42,640×360)和IPU6 Camera 720p(/dev/video43,1280×720)之间手动选择;空闲时不打开物理摄像头,停止取流 3 秒后自动释放。
1. 问题与最终架构
这台电脑的摄像头不是普通 USB UVC 摄像头,而是通过 Intel IPU6 连接的 MIPI hi556。Linux 会为 IPU6 媒体拓扑生成大量 /dev/video* 节点;腾讯会议等软件看到的几十个 ipu6(n) 多数是媒体图中的原始节点,不是可直接显示的成品摄像头,所以选中后没有画面。
本机的物理摄像头可以被 libcamera 正常驱动,但部分传统应用只接受标准 V4L2 Capture 设备。最终方案如下:
| |
按需代理常驻时只持有 /dev/video42 和 /dev/video43 的写端,并各放入一帧黑色占位图,使 exclusive_caps=1 的虚拟设备始终以纯 Capture 摄像头出现。它订阅 v4l2loopback 0.15.4 的 V4L2_EVENT_PRI_CLIENT_USAGE 私有事件:
- 仅枚举或查询摄像头不会启动物理相机;
- 软件真正执行
STREAMON后才启动libcamerasrc; - 读取结束 3 秒后停止 GStreamer 并释放物理相机;
- 双设备空闲实测约 2–4 MB,且没有
gst-launch-1.0子进程; - 单路 360p 取流约 47 MB,单路或双路含 720p 时约 62 MB,退出后回落;
- 第一次取流可能短暂出现 1–2 帧黑色占位帧,之后进入真实画面。
最终方案不依赖 pw-v4l2 或 gstreamer1.0-pipewire。此前 pw-v4l2 能让腾讯会议出现 hi556 条目,但腾讯会议处理 PipeWire 提供的 BGRx 画面时仍显示黑屏,因此没有采用。
进一步跟踪腾讯会议的 V4L2 调用后确认:其 libxcast.so 在 VIDIOC_DQBUF 和 VIDIOC_QBUF 前把 v4l2_buffer.memory 留成 0,而 MMAP 队列要求 V4L2_MEMORY_MMAP=1。内核因此返回 EINVAL,日志会循环出现 Could not requeue buffer,最终表现为黑屏。第 13 节的兼容库只对 /dev/video42 和 /dev/video43 修正这两个调用,不会修改其他摄像头或其他程序。
2. 已验证的软件版本
以下版本是本机成功运行时的基线。重装后不要求版本号完全一致,但 libcamera 相关包应来自同一套仓库版本。
| 组件 | 已验证版本 |
|---|---|
| Deepin | 25 / crimson |
| Linux 内核 | 6.18.48-amd64-desktop-rolling |
| libcamera / libcamera-tools | 0.7.0-2deepin1 |
| gstreamer1.0-libcamera | 0.7.0-2deepin1 |
| GStreamer base/good | 1.24.13 |
| v4l-utils | 1.30.1 |
| DKMS | 3.1.0 |
| v4l2loopback | 0.15.4(上游源码 DKMS) |
本机 Secure Boot 为关闭状态。若重装后启用了 Secure Boot,必须签名并信任 DKMS 模块,否则 modprobe v4l2loopback 会失败。
3. 安装基础组件
先在终端缓存一次 sudo 凭据,避免每条命令都要求密码:
| |
安装依赖。Deepin 软件仓库未来可能调整包名;以下包名已在 Deepin 25 验证:
| |
如果系统限制直接使用 apt,通过 Deepin 应用商店或系统软件管理器安装同名包即可。
最终按需方案不需要安装以下两个包:
| |
它们可以保留,但不是本方案的依赖。
4. 确认内核已经识别 IPU6 和 hi556
查看硬件:
| |
本机应出现:
| |
检查内核模块:
| |
Deepin 25 的 6.18 内核已自带 intel-ipu6、intel-ipu6-isys 和 hi556。不要一开始就盲目安装额外的 Intel IPU6 DKMS 驱动;先执行后面的 cam -l。只有内核确实缺少这些模块时,才参考 intel/ipu6-drivers 的 DKMS 说明。
本机也曾加入过 ipu6-drivers/0.0.0 DKMS,但在 6.18 上核心 IPU6 与 hi556 都已有内核原生模块,DKMS 状态会提示 original_module exists。这不是最终虚拟摄像头方案的必要条件。
5. 给予桌面用户 /dev/udmabuf 权限
libcamera 的软件 ISP 需要访问 /dev/udmabuf。创建 udev 规则:
| |
如果 ACL 没有立即更新,注销并重新登录,或直接重启。检查:
| |
当前图形会话用户应具有读写权限。
6. 先用 libcamera 验证物理摄像头
列出摄像头:
| |
本机的正确结果包含:
| |
以下警告在本机存在,但不妨碍画面输出:
| |
libcamera 会回退到通用的 uncalibrated.yaml 和软件 ISP。
打开预览:
| |
只有 qcam 能正常显示画面后,才继续配置虚拟摄像头。如果 cam -l 找不到 hi556,应先处理内核驱动、固件或 /dev/udmabuf 权限问题。
可选:让开始菜单“相机”直接启动 qcam
原 Deepin 相机程序只识别普通 V4L2 摄像头时,可能提示“未连接摄像头”。可建立用户级桌面入口覆盖:
| |
7. 安装兼容 Linux 6.18 的 v4l2loopback
Deepin 仓库当时提供的 v4l2loopback-dkms 0.14.0-1 无法在 Linux 6.18 上编译,典型错误包括:
| |
上游 0.15.4 已在本机内核上编译和运行成功。先检查仓库版本:
| |
如果候选版本已经是 0.15.4 或更高,可优先直接安装发行版包。若仍是 0.14,按下面步骤安装固定的上游版本。
先移除可能处于半配置状态的旧包:
| |
下载并放入 DKMS 源码目录:
| |
注册、编译并安装:
| |
检查:
| |
预期包含:
| |
若 Secure Boot 已开启且 modprobe 报签名错误,需要按系统提示注册 DKMS MOK 证书,或在固件设置中关闭 Secure Boot。可用以下命令确认状态:
| |
8. 固定两个虚拟设备为 /dev/video42 和 /dev/video43
创建模块自动加载配置:
| |
首次加载:
| |
如果模块已经按旧的单设备参数加载,先彻底退出使用摄像头的软件并停止代理,再重载:
| |
检查:
| |
预期名称:
| |
配置文件中 card_label 必须用一组引号包住整个逗号分隔列表;分别给每个名称加引号会让引号字符进入设备名称。
exclusive_caps=1,1 很重要:它让 Chrome/WebRTC 等应用只看到标准 Capture 能力。共享代理会一直持有两个虚拟设备的 Output 写端,因此即使物理摄像头处于关闭状态,应用仍能发现两个设备。
9. 安装按需代理
代理只依赖 libc 和 Linux V4L2 头文件。保存以下源码到:
| |
| |
编译并安装:
| |
10. 创建并启用用户服务
创建 ~/.config/systemd/user/ipu6-virtual-camera.service:
| |
注意:本机实际安装的服务文件使用了绝对路径 /home/tryao/.local/libexec/ipu6-camera-demand。上面的 %h 写法更便于重装和迁移用户目录;systemd 用户服务支持 %h。
启用:
| |
如果服务文件刚刚才保存,确保保存后再执行 daemon-reload。
11. 验证空闲状态
| |
预期关键结果:
| |
空闲时服务 cgroup 中应只有一个 ipu6-camera-demand 代理进程,不应存在 gst-launch-1.0:
| |
本机双设备空闲实测约 2–4 MB。代理只应持有 /dev/video42 和 /dev/video43,不应持有 /dev/media0、IPU6 原始视频节点或 /dev/udmabuf。
12. 验证按需启动和真实画面
先测试 360p:
| |
再等待约 3 秒释放物理摄像头,然后测试 720p:
| |
v4l2loopback 可能输出 VIDIOC_CREATE_BUFS returned -1 (Inappropriate ioctl for device),但随后能正常抓满指定帧数时可以忽略。
抓帧期间执行:
| |
只读取 360p 时,子进程参数应包含 width=640,height=360;只读取 720p 时应包含 width=1280,height=720。抓帧结束约 3 秒后,gst-launch-1.0 子进程应自动消失,代理继续常驻。
若安装了 FFmpeg,可检查两路亮度:
| |
开始可能有一两帧 YAVG=16 的黑色占位帧,之后应明显高于 16。本机最终单路测试分别为 360p YAVG=127.21、720p YAVG=144.64。
可选的双路并发测试:
| |
日志应出现 outputs=360p+720p,并且同一时刻只有一个 gst-launch-1.0/libcamera 子进程。本机并发末帧亮度分别为 154.15 和 153.70;双路含 720p 时内存约 62 MB。
测试完成后删除原始文件:
| |
13. 在会议和聊天软件中使用
普通软件完全退出并重新启动后,按需要选择:
| |
不要选择名为 ipu6(0)、ipu6(1)……的原始节点。它们是 IPU6 媒体拓扑中的处理节点,不是成品视频流。腾讯会议会把这些节点全部列出来,因此会看到约 32 个条目;不能用全局权限规则安全隐藏它们,否则 libcamera 和 qcam 也可能无法访问完成处理所需的节点。实际使用时忽略它们,只选上述两个名称清晰的虚拟设备之一。
微信、浏览器和正常遵循 V4L2 的应用不需要专用启动器。删除以前为微信创建过的兼容菜单覆盖:
| |
13.1 腾讯会议黑屏兼容层
本机腾讯会议的 libxcast.so 会在 MMAP 队列的 VIDIOC_DQBUF/VIDIOC_QBUF 调用中传入 memory=0,v4l2loopback 会正确返回 EINVAL。下面的 LD_PRELOAD 库只在文件描述符确实指向 /dev/video42 或 /dev/video43、请求确实为这两个 ioctl、缓冲区类型确实为 Video Capture 且 memory==0 时,将其修正为 V4L2_MEMORY_MMAP。
保存为 ~/.local/share/ipu6-camera/wemeet-v4l2-fix.c:
| |
编译安装:
| |
复制系统菜单文件到用户目录,并仅替换启动命令:
| |
完全退出腾讯会议后,从开始菜单重新打开。修复成功时,腾讯会议日志会出现与所选设备相符的 config.succ.size.*、start.leave.succ 和 first.draw,不再持续出现针对 /dev/video42 或 /dev/video43 的 Could not requeue buffer。
13.2 与 qcam 的互斥关系
hi556 物理摄像头一次只能由一个 libcamera 流占用。腾讯会议正在预览或开会时,按需代理会占用物理摄像头,此时 qcam 无法同时使用是正常现象。停止腾讯会议预览或完全退出,等待约 3 秒让代理释放物理相机,再启动 qcam。
如果关闭窗口后仍未释放,检查腾讯会议是否还有后台进程:
| |
只要某个应用仍对 /dev/video42 或 /dev/video43 保持 V4L2 Capture 流,代理就会继续运行真实摄像头取流。
14. 常用管理命令
查看状态:
| |
重启:
| |
临时停用:
| |
重新启用:
| |
查看日志:
| |
检查驱动:
| |
15. 常见故障
/dev/video42 或 /dev/video43 不存在
| |
确认 /etc/modules-load.d/ipu6-virtual-camera.conf 和 /etc/modprobe.d/ipu6-virtual-camera.conf 内容正确。
服务显示 ConditionPathExists 未满足
先加载模块,再启动用户服务:
| |
cam -l 找不到 hi556
这不是虚拟摄像头层的问题。优先检查:
| |
确认当前内核和对应的 linux-headers-$(uname -r) 来自同一套 Deepin 更新。
qcam 正常,但会议软件仍看不到虚拟设备
| |
video42 和 video43 的 state 都必须是 capture,能力中应只有 Video Capture,不能处于仅 Video Output 状态。完全退出会议软件后再重新打开。
虚拟设备出现但始终黑屏
若仅腾讯会议黑屏,先确认是从开始菜单启动,并检查用户菜单覆盖:
| |
Exec 应包含 LD_PRELOAD=。若腾讯会议日志持续出现针对 /dev/video42 或 /dev/video43 的 Could not requeue buffer,说明兼容库没有被加载,请按第 13 节重新安装并彻底退出后重启腾讯会议。
如果所有应用都黑屏,再检查 GStreamer 插件:
| |
直接验证物理摄像头:
| |
再查看服务日志:
| |
内核升级后 v4l2loopback 消失
| |
若 0.15.4 不再兼容未来内核,从 v4l2loopback 官方仓库 选择支持该内核的新版本,并相应修改 /usr/src/v4l2loopback-<版本> 和 DKMS 版本号。
16. 完整卸载或回滚
停止并禁用用户服务:
| |
移除模块自动加载配置:
| |
若连手工安装的 DKMS 模块也要删除:
| |
恢复 Deepin 原始“相机”菜单入口:
| |
17. 最终文件清单
正常工作时应存在:
| |
18. Redrix 内置麦克风修复(独立于摄像头)
本机还有一条独立的 SOF 音频问题。Google Redrix rev3 的 ACPI 描述内置麦克风为 2ch-pdm0,内核日志会出现:
| |
对 Alder Lake/Brya 而言,缺少 NHLT 不能单独证明是故障,不要注入其他平台的 NHLT 表。本机实测的根因是:通用 UCM 暴露了无效 Mic2,PipeWire/WirePlumber 对四通道 hw:0,99 的默认初始化不稳定,且真实人声只在原始通道 1。全局启用的 filter-chain.service 还会抢占错误输入。以下是腾讯会议已经实际确认可用的低风险修复。
18.1 安装 Chromebook 音频基础配置
| |
Deepin 不在该项目当前列出的官方支持发行版中,但本机已成功安装。如脚本提示缺包,先按其输出安装依赖。
18.2 指定真实 DMIC 数量
创建 /etc/modprobe.d/99-redrix-sof-microphone.conf:
| |
重启后验证:
| |
预期输出 2。日志里仍出现 DMICs detected in NHLT tables: 0 不代表参数无效;该参数也只负责让驱动按两个 DMIC 处理,并不能单独解决 PipeWire 取流和通道映射问题。
18.3 隐藏无效 Mic2,提高 Mic1 优先级
创建 /etc/wireplumber/wireplumber.conf.d/52-redrix-microphone.conf:
| |
应用并选择真实输入:
| |
18.4 阻止错误的降噪代理再次抢占输入
本机的 filter-chain.service 是全局启用的用户服务,普通 disable 仍可能在下次登录时被全局预设拉起。为当前用户建立 mask:
| |
这只关闭额外的降噪/虚拟麦克风代理,不会关闭 PipeWire、扬声器或耳机。检查:
| |
正常时,三个音频核心服务都是 active,可见的原始内置麦克风只有 Mic1。
18.5 绕过不稳定的 UCM 四通道父节点
直接 ALSA 实测确认 hw:0,99 必须以 S32_LE / 48000 Hz / 4ch 打开:通道 1 含清晰人声,通道 0 非常小,通道 2/3 是无效直流电平。WirePlumber 默认 UCM 父节点曾使取流退化为底噪,因此创建 ~/.config/wireplumber/wireplumber.conf.d/53-redrix-direct-dmic.conf:
| |
18.6 按成功的 ALSA 参数创建单声道直连源
创建 ~/.config/pipewire/pipewire-pulse.conf.d/60-redrix-internal-microphone.conf:
| |
应用配置,为最终源增加数字增益,并把它设为系统默认麦克风:
| |
400% 在本机 PulseAudio 刻度上等于约 +21.67 dB,并会由 module-device-restore 记住,重启 PipeWire-Pulse 后仍能恢复。把 redrix_direct_mic 设为默认后,遵循系统默认输入源的普通应用也能使用有效通道;应用若提供麦克风列表,仍建议明确选择 Redrix_Direct_Microphone。
Deepin 语音记事本限制:
redrix_direct_mic是没有 PulseAudio 硬件端口的 remap 源,而语音记事本只接受默认源中带硬件端口的设备,因此会提示“未检测到录音设备”。若临时把原始 Mic1 设为默认,按钮会出现,但应用会显式连接到错误的原始 Mic1,录音仍没有有效人声。实测在录制中执行pactl move-source-output也没有得到可靠录音,不能作为解决方案。本文最终支持范围是腾讯会议等允许选择麦克风、或能正确遵循系统默认输入源的应用。要兼容语音记事本,需要另行实现带 ALSA 硬件端口的snd-aloop虚拟麦克风。
检查:
| |
预期同时出现:
redrix_raw4:内部四通道源,名称为Redrix_RAW_DO_NOT_SELECT,不要在应用中选它;redrix_direct_mic:最终1ch/48000 Hz麦克风,应用中显示为Redrix_Direct_Microphone。
两层空闲时都是 SUSPENDED,fuser /dev/snd/pcmC0D99c 无输出;只有应用实际录音时才打开底层 DMIC。
18.7 腾讯会议选择与验证
腾讯会议中建议手动选择 Redrix_Direct_Microphone。不要选 Redrix_RAW_DO_NOT_SELECT 或原始 Mic1;当前“系统默认”也指向直连麦克风,但明确选择设备名可以避免应用缓存旧的默认源。
命令行单独录音验证:
| |
本机在 2026-09-25 与腾讯会议并行录音时,实测人声峰值约 -22.25 dB、RMS 约 -41.04 dB。Wemeet VoiceEngine/RecordStream 显示 target.object = redrix_direct_mic、pulse.corked = false,用户已确认腾讯会议输入可用。
18.8 回滚麦克风修改
| |
只有确定要恢复系统默认降噪代理时,才执行 unmask。
19. 最终麦克风文件清单
| |