Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-4372GitHub issuePublicReceived

omarchy webcam picker offers unusable IPU6 raw Bayer node alongside real capture device

Reported by oren · filed May 10, 2026Closed upstream on 2026-08-13 by the merge of PR #6732 (closed by dhh). GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
Not yet mapped to any requirement or component.
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

omarchy webcam picker offers unusable IPU6 raw Bayer node alongside real capture devicerevision 1 · captured 2026-10-04 11:56 UTC via poll

Summary

On Intel IPU6 laptops (most 11th-gen+ Intel hardware), omarchy-menu's
"With desktop + microphone audio + webcam" flow opens a webcam picker
that lists the IPU6's raw Bayer-only /dev/video0 alongside the actual
capture device (typically a v4l2loopback node fed by v4l2-relayd +
icamerasrc). Picking /dev/video0 produces a black overlay or
STREAMON: Link severed because that node only advertises raw sensor
formats. Users have to know which entry is the real camera.

Reproduction

On an IPU6/IPU7 laptop with the Intel camera HAL stack installed
(intel-ipu6-camera-bin, intel-ipu6ep-camera-hal-git, icamerasrc-git,
v4l2loopback-dkms, v4l2-relayd), v4l2-ctl --list-devices returns
two camera groups:

ipu6 (PCI:0000:00:05.0):
        /dev/video0
        /dev/video1
        ...
        /dev/video31
        /dev/media0

Built-in Camera (platform:v4l2loopback-042):
        /dev/video42

get_webcam_list collapses each group to its first device, so the
picker shows two entries:

/dev/video0   ipu6 (PCI:0000:00:05.0)
/dev/video42  Built-in Camera (platform:v4l2loopback-042)

Picking /dev/video0 opens ffplay against an output-only / raw-Bayer
node and yields a black overlay; only /dev/video42 works.

Related: omarchy-capture-screenrecording auto-detect

The auto-detect path in omarchy-capture-screenrecording's
start_webcam_overlay (around line 54) is also affected, and arguably
worse - it does:

WEBCAM_DEVICE=$(v4l2-ctl --list-devices 2>/dev/null \
  | grep -m1 "^[[:space:]]*/dev/video" | tr -d '\t')

which always picks /dev/video0 on this hardware (the first
indented /dev/video* line in the output). So --with-webcam without
--webcam-device always lands on the broken IPU6 raw node. The user
gets a black overlay with no error.

Suggested fix

Filter both paths to entries whose Device Caps include Video Capture.
Either parse v4l2-ctl --device=$dev --info, or check the udev
ID_V4L_CAPABILITIES property - IPU6 ISP nodes report Video Output /
I/O MC only, while the v4l2loopback node reports Video Capture.

On a clean IPU6 + loopback setup this collapses the picker list to a
single entry (/dev/video42) and the existing count == 1 auto-pick
path takes over. On a UVC-only laptop (current behavior), the single
/dev/video0 entry still passes the filter. No UX changes for non-IPU6
users.

Environment

  • Omarchy 3.8.0
  • Intel Core i7-1370P (Raptor Lake-P, IPU6EP)
  • Driver/HAL: intel-ipu6-dkms-git, intel-ipu6-camera-bin, intel-ipu6ep-camera-hal-git, icamerasrc-git
  • Camera surfaced via v4l2-relayd to /dev/video42 (v4l2loopback)
View raw text
### Summary

On Intel IPU6 laptops (most 11th-gen+ Intel hardware), `omarchy-menu`'s
"With desktop + microphone audio + webcam" flow opens a webcam picker
that lists the IPU6's raw Bayer-only `/dev/video0` alongside the actual
capture device (typically a `v4l2loopback` node fed by `v4l2-relayd` +
`icamerasrc`). Picking `/dev/video0` produces a black overlay or
`STREAMON: Link severed` because that node only advertises raw sensor
formats. Users have to know which entry is the real camera.

### Reproduction

On an IPU6/IPU7 laptop with the Intel camera HAL stack installed
(`intel-ipu6-camera-bin`, `intel-ipu6ep-camera-hal-git`, `icamerasrc-git`,
`v4l2loopback-dkms`, `v4l2-relayd`), `v4l2-ctl --list-devices` returns
two camera groups:

```
ipu6 (PCI:0000:00:05.0):
        /dev/video0
        /dev/video1
        ...
        /dev/video31
        /dev/media0

Built-in Camera (platform:v4l2loopback-042):
        /dev/video42
```

`get_webcam_list` collapses each group to its first device, so the
picker shows two entries:

```
/dev/video0   ipu6 (PCI:0000:00:05.0)
/dev/video42  Built-in Camera (platform:v4l2loopback-042)
```

Picking `/dev/video0` opens ffplay against an output-only / raw-Bayer
node and yields a black overlay; only `/dev/video42` works.

### Related: `omarchy-capture-screenrecording` auto-detect

The auto-detect path in `omarchy-capture-screenrecording`'s
`start_webcam_overlay` (around line 54) is also affected, and arguably
worse - it does:

```bash
WEBCAM_DEVICE=$(v4l2-ctl --list-devices 2>/dev/null \
  | grep -m1 "^[[:space:]]*/dev/video" | tr -d '\t')
```

which always picks `/dev/video0` on this hardware (the first
indented `/dev/video*` line in the output). So `--with-webcam` without
`--webcam-device` always lands on the broken IPU6 raw node. The user
gets a black overlay with no error.

### Suggested fix

Filter both paths to entries whose `Device Caps` include `Video Capture`.
Either parse `v4l2-ctl --device=$dev --info`, or check the udev
`ID_V4L_CAPABILITIES` property - IPU6 ISP nodes report `Video Output` /
`I/O MC` only, while the v4l2loopback node reports `Video Capture`.

On a clean IPU6 + loopback setup this collapses the picker list to a
single entry (`/dev/video42`) and the existing `count == 1` auto-pick
path takes over. On a UVC-only laptop (current behavior), the single
`/dev/video0` entry still passes the filter. No UX changes for non-IPU6
users.

### Environment

- Omarchy 3.8.0
- Intel Core i7-1370P (Raptor Lake-P, IPU6EP)
- Driver/HAL: `intel-ipu6-dkms-git`, `intel-ipu6-camera-bin`, `intel-ipu6ep-camera-hal-git`, `icamerasrc-git`
- Camera surfaced via `v4l2-relayd` to `/dev/video42` (`v4l2loopback`)

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

No decision has been recorded yet.