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

USB-C hub/dock monitors dead on Framework 13 (Tiger Lake) after linux 7.1.9 — ucsi_acpi never binds USBC000, /sys/class/typec empty

Reported by edlandm · filed Sep 1, 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

USB-C hub/dock monitors dead on Framework 13 (Tiger Lake) after linux 7.1.9 — ucsi_acpi never binds USBC000, /sys/class/typec emptyrevision 1 · captured 2026-09-28 21:24 UTC via poll

USB-C hub/dock monitors dead on Framework 13 (Tiger Lake) after linux 7.1.9 — ucsi_acpi never binds USBC000, /sys/class/typec empty

What happened

After updating to linux 7.1.9.arch1-2 (2026-08-31, same update pulled linux-firmware 20260810-2; Omarchy 4.0.2/Quattro), external monitors connected through a USB-C hub stopped working on a Framework Laptop 13 (11th gen, Tiger Lake, Iris Xe / i915). The hub's USB side is fully functional (hub enumeration, RTL8153 ethernet, card readers), but DisplayPort Alt Mode never starts, so both monitor outputs on the hub stay dark. Replugging does not help.

The same hub on the same port worked on linux 7.1.8.arch1-3 (last working use 2026-08-30, previous boot).

Root cause (diagnosed live on the affected machine)

  • All card1-DP-* DRM connectors stay disconnected; hyprctl monitors all shows only eDP-1.
  • /sys/class/typec/ is completely empty — no port objects exist at all, so DP Alt Mode can never be negotiated on any port. The hub falls back to USB-only.
  • The UCSI platform device USBC000:00 (HID USBC000, CID PNP0CA0, from the INSYDE TbtTypeC SSDT) exists, udev loads ucsi_acpi via its acpi:USBC000:PNP0CA0: modalias, but the driver never binds, so no typec ports are registered.
  • Manual bind is rejected by the kernel on 7.1.9:
  # echo USBC000:00 > /sys/bus/platform/drivers/ucsi_acpi/bind
  bash: echo: write error: No such device
  • modinfo ucsi_acpi on 7.1.9 shows its only match ID is acpi*:PNP0CA0:*. On other kernels, USBC000 devices bind ucsi_acpi fine (public reports below), so this looks like a 7.1.9 regression in the ACPI/platform match path (CID-based matching) rather than a hardware or config issue.
  • Thunderbolt is healthy and not the cause: both TGL TB4 NHI domains come up (domain0/domain1), and unbinding/rebinding the thunderbolt driver live made no difference to UCSI binding.
  • Also ruled out: the new MODULES+=(thunderbolt) initramfs drop-in shipped in omarchy-settings 4.0.2 (first effective in the same boot) — unbinding the driver did not restore typec registration.

Public reports of the same USBC000/ucsi_acpi breakage pattern across kernel updates:

  • Artix forum: "Latest linux kernel update fails to boot PPM init … ucsi_acpi USBC000:00: PPM init failed (-110)" (11th gen Intel laptop)
  • Red Hat Bugzilla 2248484: ucsi_acpi USBC000:00: UCSI_GET_PDOS failed after a kernel update; worked on the prior kernel series, fixed in a later kernel

Environment

  • Omarchy 4.0.2-1 (Quattro), fully updated 2026-08-31
  • Kernel: linux 7.1.9.arch1-2 (broken), linux 7.1.8.arch1-3 (working)
  • Hardware: Framework Laptop 13, 11th gen Intel (Tiger Lake, i915), INSYDE BIOS with TbtTypeC SSDT
  • Compositor: Hyprland; only eDP-1 present while affected

Workaround

  • Boot linux-lts (omarchy pkg add linux-lts), or
  • Downgrade: fetch linux-7.1.8.arch1-3 from the Arch Linux Archive, pacman -U it, and hold with IgnorePkg = linux until a fixed kernel lands in the repos (upstream stable already has 7.1.10).

Suggested Omarchy action

Consider a known-issues note for Quattro/4.0.2 users on Framework 11th-gen (and other USBC000-based Insyde/AMI BIOSes) who lose USB-C display output after the 7.1.9 update, pointing to linux-lts as the escape hatch until Arch ships 7.1.10+.

View raw text
# USB-C hub/dock monitors dead on Framework 13 (Tiger Lake) after linux 7.1.9 — ucsi_acpi never binds USBC000, /sys/class/typec empty

## What happened

After updating to `linux 7.1.9.arch1-2` (2026-08-31, same update pulled `linux-firmware 20260810-2`; Omarchy 4.0.2/Quattro), external monitors connected through a USB-C hub stopped working on a Framework Laptop 13 (11th gen, Tiger Lake, Iris Xe / i915). The hub's USB side is fully functional (hub enumeration, RTL8153 ethernet, card readers), but DisplayPort Alt Mode never starts, so both monitor outputs on the hub stay dark. Replugging does not help.

The same hub on the same port worked on `linux 7.1.8.arch1-3` (last working use 2026-08-30, previous boot).

## Root cause (diagnosed live on the affected machine)

- All `card1-DP-*` DRM connectors stay `disconnected`; `hyprctl monitors all` shows only `eDP-1`.
- `/sys/class/typec/` is completely empty — no port objects exist at all, so DP Alt Mode can never be negotiated on any port. The hub falls back to USB-only.
- The UCSI platform device `USBC000:00` (HID `USBC000`, CID `PNP0CA0`, from the INSYDE `TbtTypeC` SSDT) exists, udev loads `ucsi_acpi` via its `acpi:USBC000:PNP0CA0:` modalias, but the driver never binds, so no typec ports are registered.
- Manual bind is rejected by the kernel on 7.1.9:

  ```
  # echo USBC000:00 > /sys/bus/platform/drivers/ucsi_acpi/bind
  bash: echo: write error: No such device
  ```

- `modinfo ucsi_acpi` on 7.1.9 shows its only match ID is `acpi*:PNP0CA0:*`. On other kernels, `USBC000` devices bind `ucsi_acpi` fine (public reports below), so this looks like a 7.1.9 regression in the ACPI/platform match path (CID-based matching) rather than a hardware or config issue.
- Thunderbolt is healthy and not the cause: both TGL TB4 NHI domains come up (`domain0`/`domain1`), and unbinding/rebinding the `thunderbolt` driver live made no difference to UCSI binding.
- Also ruled out: the new `MODULES+=(thunderbolt)` initramfs drop-in shipped in `omarchy-settings 4.0.2` (first effective in the same boot) — unbinding the driver did not restore typec registration.

Public reports of the same `USBC000`/`ucsi_acpi` breakage pattern across kernel updates:

- Artix forum: "Latest linux kernel update fails to boot PPM init … `ucsi_acpi USBC000:00: PPM init failed (-110)`" (11th gen Intel laptop)
- Red Hat Bugzilla 2248484: `ucsi_acpi USBC000:00: UCSI_GET_PDOS failed` after a kernel update; worked on the prior kernel series, fixed in a later kernel

## Environment

- Omarchy 4.0.2-1 (Quattro), fully updated 2026-08-31
- Kernel: `linux 7.1.9.arch1-2` (broken), `linux 7.1.8.arch1-3` (working)
- Hardware: Framework Laptop 13, 11th gen Intel (Tiger Lake, i915), INSYDE BIOS with `TbtTypeC` SSDT
- Compositor: Hyprland; only `eDP-1` present while affected

## Workaround

- Boot `linux-lts` (`omarchy pkg add linux-lts`), or
- Downgrade: fetch `linux-7.1.8.arch1-3` from the Arch Linux Archive, `pacman -U` it, and hold with `IgnorePkg = linux` until a fixed kernel lands in the repos (upstream stable already has 7.1.10).

## Suggested Omarchy action

Consider a known-issues note for Quattro/4.0.2 users on Framework 11th-gen (and other `USBC000`-based Insyde/AMI BIOSes) who lose USB-C display output after the 7.1.9 update, pointing to `linux-lts` as the escape hatch until Arch ships 7.1.10+.

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 10:21 UTC