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-1292GitHub issuePublicDecided· Out of scope

Browser cannot access built-in camera even when libcamera, pipewire-libcamera, and qcam all work

Reported by loganwoolf · filed Aug 28, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 4 days ago.

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?
AreaOutside the audited area· Decided by agents · verified
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?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Browser cannot access built-in camera even when libcamera, pipewire-libcamera, and qcam all workrevision 1 · captured 2026-09-28 21:24 UTC via poll

Summary

On a stock Omarchy 4.0.1 install, libcamera + pipewire-libcamera + WirePlumber correctly expose the built-in camera (qcam and wpctl status both confirm it), but Chromium-based browsers never see a camera device. OBS Studio, using the same PipeWire source, shows a preview with broken colors and then crashes.

Environment

  • Surface Pro (BIOS 239.871.768), Omarchy 4.0.1
  • Compositor: Hyprland, Wayland session
  • Browser: Brave Origin 1.94.117-1, launched with --ozone-platform=wayland --ozone-platform-hint=wayland (already native Wayland)
  • Portal stack: xdg-desktop-portal 1.22.1, xdg-desktop-portal-gtk 1.15.3, xdg-desktop-portal-hyprland 1.4.1, pipewire 1.6.8, wireplumber 0.5.15, libcamera 0.7.2

Reproduction

  1. Confirm the camera works at the kernel/userspace level:
  • qcam opens a live preview.
  • wpctl status lists Built-in Front Camera under Video / Sources.
  1. Open Brave Origin, visit any site that requests the camera (or chrome://settings/content/camera).
  2. The camera never appears; no permission prompt is shown. OBS Studio's PipeWire source shows a corrupted preview and exits.

Evidence

journalctl --user -u xdg-desktop-portal-gtk:

xdg-desktop-portal-gtk[1229]: Unhandled parent window type
xdg-desktop-portal-gtk[1229]: Failed to associate portal window with parent window

wpctl status confirms the camera node:

Video
 ├─ Sources:
 │    86. Built-in Front Camera

libcamera sees the same device:

$ cam -l
1: Internal front camera (\_SB_.PCI0.I2C2.CAMF)

Why it fails

The Camera portal in xdg-desktop-portal is implemented only by xdg-desktop-portal-gtk. xdg-desktop-portal-hyprland v1.4.1 ships only GlobalShortcuts, InputCapture, ScreenCast, Screenshot — there is no Camera/Access portal implementation in its tree (src/portals/).

When Brave Origin calls org.freedesktop.portal.Access.AccessCamera, the GTK portal handles it but logs Unhandled parent window type / Failed to associate portal window with parent window and never returns. Brave Origin then sees no camera device.

This is not a libcamera issue (camera works) and not a PipeWire issue (node is exported). It is the GTK portal's Access dialog failing to attach to the Hyprland parent window.

Attempted workarounds

  • Setting org.freedesktop.impl.portal.Access=gtk in /etc/xdg-desktop-portal/portals.conf: same error.
  • Session is Wayland (XDG_SESSION_TYPE=wayland, WAYLAND_DISPLAY=wayland-1); Brave Origin is launched as native Wayland.
  • Restarted the portal services with debug logging; no extra output (GLib only logs to stderr when attached to a TTY).

Possible fixes

  • Add an Access/Camera portal implementation to xdg-desktop-portal-hyprland. v1.4.1 already shipped InputCapture; Camera is the natural next step.
  • Or update xdg-desktop-portal-gtk to recognise Hyprland's hyprland_toplevel_export_manager_v1 handle.

Related

  • basecamp/omarchy#7776 — different failure mode (IPU7 sensor enumeration).
  • linux-surface wiki "Marvell 88W8897 quirks" — Surface wifi/wake quirk used to get to this stack in the first place.
View raw text
### Summary

On a stock Omarchy 4.0.1 install, libcamera + pipewire-libcamera + WirePlumber correctly expose the built-in camera (`qcam` and `wpctl status` both confirm it), but Chromium-based browsers never see a camera device. OBS Studio, using the same PipeWire source, shows a preview with broken colors and then crashes.

### Environment

- Surface Pro (BIOS 239.871.768), Omarchy 4.0.1
- Compositor: Hyprland, Wayland session
- Browser: Brave Origin 1.94.117-1, launched with `--ozone-platform=wayland --ozone-platform-hint=wayland` (already native Wayland)
- Portal stack: xdg-desktop-portal 1.22.1, xdg-desktop-portal-gtk 1.15.3, xdg-desktop-portal-hyprland 1.4.1, pipewire 1.6.8, wireplumber 0.5.15, libcamera 0.7.2

### Reproduction

1. Confirm the camera works at the kernel/userspace level:
   - `qcam` opens a live preview.
   - `wpctl status` lists `Built-in Front Camera` under `Video / Sources`.
2. Open Brave Origin, visit any site that requests the camera (or `chrome://settings/content/camera`).
3. The camera never appears; no permission prompt is shown. OBS Studio's PipeWire source shows a corrupted preview and exits.

### Evidence

`journalctl --user -u xdg-desktop-portal-gtk`:

```
xdg-desktop-portal-gtk[1229]: Unhandled parent window type
xdg-desktop-portal-gtk[1229]: Failed to associate portal window with parent window
```

`wpctl status` confirms the camera node:

```
Video
 ├─ Sources:
 │    86. Built-in Front Camera
```

libcamera sees the same device:

```
$ cam -l
1: Internal front camera (\_SB_.PCI0.I2C2.CAMF)
```

### Why it fails

The Camera portal in `xdg-desktop-portal` is implemented only by `xdg-desktop-portal-gtk`. `xdg-desktop-portal-hyprland` v1.4.1 ships only `GlobalShortcuts`, `InputCapture`, `ScreenCast`, `Screenshot` — there is no Camera/Access portal implementation in its tree (`src/portals/`).

When Brave Origin calls `org.freedesktop.portal.Access.AccessCamera`, the GTK portal handles it but logs `Unhandled parent window type / Failed to associate portal window with parent window` and never returns. Brave Origin then sees no camera device.

This is not a libcamera issue (camera works) and not a PipeWire issue (node is exported). It is the GTK portal's Access dialog failing to attach to the Hyprland parent window.

### Attempted workarounds

- Setting `org.freedesktop.impl.portal.Access=gtk` in `/etc/xdg-desktop-portal/portals.conf`: same error.
- Session is Wayland (`XDG_SESSION_TYPE=wayland`, `WAYLAND_DISPLAY=wayland-1`); Brave Origin is launched as native Wayland.
- Restarted the portal services with debug logging; no extra output (GLib only logs to stderr when attached to a TTY).

### Possible fixes

- Add an Access/Camera portal implementation to `xdg-desktop-portal-hyprland`. v1.4.1 already shipped InputCapture; Camera is the natural next step.
- Or update `xdg-desktop-portal-gtk` to recognise Hyprland's `hyprland_toplevel_export_manager_v1` handle.

### Related

- basecamp/omarchy#7776 — different failure mode (IPU7 sensor enumeration).
- linux-surface wiki "Marvell 88W8897 quirks" — Surface wifi/wake quirk used to get to this stack in the first place.

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.

  • Out of scopeDecided by agents · verified · 2026-10-09 09:48 UTC