140 lines
5.7 KiB
Markdown
140 lines
5.7 KiB
Markdown
# Cameras on the Lenovo Duet 3 (`lenovo-wormdingler`) — TODO
|
||
|
||
The front and rear cameras do **not** work on the current Mobile NixOS image.
|
||
This file is a starting point for picking the work back up later, so we don't
|
||
have to re-diagnose from scratch.
|
||
|
||
## Current state (May 2026)
|
||
|
||
Empirical, taken on the running device:
|
||
|
||
```
|
||
$ uname -a
|
||
Linux ideapad 6.5.0 #1-mobile-nixos SMP Tue Jan 1 00:00:00 UTC 1980 aarch64 GNU/Linux
|
||
|
||
$ ls /dev/video*
|
||
/dev/video0 ← Qualcomm Venus video decoder (h.264/h.265 dec)
|
||
/dev/video1 ← Qualcomm Venus video encoder (h.264/h.265 enc)
|
||
|
||
$ ls /dev/media* # nothing — no media controller graph at all
|
||
$ lsmod | grep -i camss # nothing
|
||
$ wpctl status | grep -A1 Sources # nothing — PipeWire has no camera sources
|
||
```
|
||
|
||
Relevant kernel config bits in `/proc/config.gz` on the running image:
|
||
|
||
```
|
||
CONFIG_MEDIA_CAMERA_SUPPORT=y ← media framework is on
|
||
# CONFIG_VIDEO_QCOM_CAMSS is not set ← Qualcomm Camera Subsystem driver is OFF
|
||
# CONFIG_VIDEO_OV5675 is not set ← every relevant sensor driver is OFF
|
||
# CONFIG_VIDEO_OV13858 is not set
|
||
# CONFIG_VIDEO_HI556 is not set
|
||
# (full grep of `VIDEO_OV*` / `VIDEO_HI*` is all `not set`)
|
||
```
|
||
|
||
So the *media framework* is enabled, but the *ISP driver* (CAMSS) and every
|
||
plausible sensor driver are off, and no out-of-tree modules are shipped. The
|
||
two `/dev/video*` nodes are the Venus codecs, not cameras — that's why
|
||
`snapshot` reports "no camera found."
|
||
|
||
## Why this is non-trivial
|
||
|
||
1. **Kernel rebuild required.** `mobile-nixos` builds its own kernel for this
|
||
device (see `mobile.kernel.structuredConfig` in `hardware.nix`, where we
|
||
already enable `CIFS` and `EXFAT_FS`). Adding camera support means adding:
|
||
- `VIDEO_QCOM_CAMSS = module;`
|
||
- The right sensor driver(s) — and we don't currently know which ones the
|
||
Duet 3 actually uses. The `wormdingler` Chromium-OS DT references a pair
|
||
of OV-series sensors but the exact part numbers can vary by SKU and
|
||
production batch.
|
||
- Their dependencies (`I2C`, `V4L2`, `MEDIA_CONTROLLER`, etc. — most are
|
||
already pulled in by `MEDIA_CAMERA_SUPPORT`).
|
||
|
||
2. **Device-tree wiring.** Even with the drivers compiled in, the device tree
|
||
has to describe the CCI bus, the sensor I²C addresses, the regulators, the
|
||
reset/enable GPIOs, and the CSI port mapping. Mobile NixOS' DT for
|
||
wormdingler may or may not include these nodes — needs verification by
|
||
reading the upstream device file at
|
||
`${inputs.mobile-nixos}/devices/lenovo-wormdingler/`.
|
||
|
||
3. **libcamera is the user-space side.** CAMSS is not a "single v4l2 device"
|
||
driver — it exposes a media-controller graph that has to be configured by
|
||
libcamera (per-sensor IPA, format negotiation, etc.). Apps then talk to
|
||
libcamera via the `libcamerasrc` PipeWire module or directly. So the
|
||
user-space stack is:
|
||
- `pkgs.libcamera` (system-wide)
|
||
- `pkgs.pipewire` already running, but needs the libcamera module enabled
|
||
(`services.pipewire.libcamera = …` or equivalent — check current option
|
||
name)
|
||
- GUI: `snapshot`, `gnome-camera`, or anything that talks to PipeWire
|
||
video sources.
|
||
|
||
## Investigation checklist
|
||
|
||
When picking this up again, do these in order:
|
||
|
||
1. **Identify the actual sensors.** The cleanest way:
|
||
- Read the upstream Mobile NixOS device file for wormdingler
|
||
(`devices/lenovo-wormdingler/default.nix` and any `.dts` overlays).
|
||
- Cross-check with the Chromium OS overlay at
|
||
<https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/refs/heads/main/overlay-trogdor/>
|
||
and the upstream Linux DTS at
|
||
`arch/arm64/boot/dts/qcom/sc7180-trogdor-wormdingler-*.dts`.
|
||
- As a runtime cross-check, when CAMSS is eventually loaded, `dmesg | grep -i
|
||
-E 'cci|sensor|isp'` will print the I²C probe attempts.
|
||
|
||
2. **Enable kernel options** in `modules/hosts/ideapad/hardware.nix` under
|
||
`mobile.kernel.structuredConfig`:
|
||
|
||
```nix
|
||
(helpers: with helpers; {
|
||
VIDEO_QCOM_CAMSS = module;
|
||
# plus whatever sensors step 1 identified, e.g.:
|
||
# VIDEO_OV5675 = module;
|
||
# VIDEO_OV13858 = module;
|
||
})
|
||
```
|
||
|
||
Cross-build on the 14900k via the existing flow (binfmt aarch64 + push back).
|
||
Reboot, then check:
|
||
|
||
```
|
||
ls /dev/media* # expect at least /dev/media0
|
||
sudo dmesg | grep -i -E 'camss|sensor|isp|cci' # probe history
|
||
sudo modprobe -v qcom-camss # if not auto-loaded
|
||
```
|
||
|
||
3. **Install diagnostic tools** for this round of work (do **not** keep these
|
||
in the long-term config unless cameras actually work):
|
||
|
||
```nix
|
||
environment.systemPackages = with pkgs; [
|
||
v4l-utils # provides v4l2-ctl, media-ctl
|
||
libcamera # provides `cam`, `qcam`
|
||
];
|
||
```
|
||
|
||
Then:
|
||
|
||
```
|
||
v4l2-ctl --list-devices
|
||
media-ctl -p # dumps the full media-controller graph
|
||
cam -l # libcamera's view of available cameras
|
||
```
|
||
|
||
4. **Wire libcamera into PipeWire.** Once `cam -l` shows at least one camera,
|
||
enable PipeWire's libcamera module (option name may have shifted; current
|
||
nixpkgs typically has `services.pipewire.wireplumber.extraConfig` or
|
||
similar). Then `wpctl status` should show new Sources under "Video", and
|
||
`snapshot` will see them.
|
||
|
||
5. **Re-add a camera GUI** to `configuration.nix`. `snapshot` is the simplest
|
||
touch-first option; `gnome-camera` and `cheese` are alternatives.
|
||
|
||
## Why nothing else is being touched right now
|
||
|
||
Steps 1–4 above are speculative — there's no guarantee the Duet 3 cameras have
|
||
working mainline-Linux sensor drivers at all. The conservative move is to
|
||
leave the config tablet-usable without them, document the dead end, and revisit
|
||
when there's time for a real spike.
|