From 334e5d0ee06e896037a722f53fcd56caa8739593 Mon Sep 17 00:00:00 2001 From: Frank Date: Wed, 21 Oct 2026 01:06:04 -0700 Subject: [PATCH] docs(niri): the ultrawide's refresh ceiling was a typo, not a limit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The page asserted the Sceptre M34's EDID tops out at 180 Hz. Measured on blankpad after the merge, `niri msg outputs` lists 3440x1440@239.998 — the claim was false in main, and it was load-bearing: it is the reason nobody questioned the profile while the panel ran at 60 Hz for weeks. The real defect was one character: the profile asked for 239.999, the panel offers 239.998, and niri matches mode strings verbatim, falling back to *preferred* without failing. Corrected to the measured mode list, and the deployed 180 is now documented as a deliberate choice (the link is trained at x8 32.0 GT/s against a max of x16 and the display engine throws EINVAL), so the next reader neither "restores 240" blind nor re-pins 180 as a hardware ceiling. The kdl profile comment carries the same facts at the point of edit, because that is where the next change to this mode gets typed. Refs #60 --- .../niri/.config/niri/cfg/desk-1-home.kdl | 12 ++++--- omp-docs/tools/niri/displays.md | 32 +++++++++++++------ 2 files changed, 30 insertions(+), 14 deletions(-) diff --git a/dotfiles/zz-blankpad/niri/.config/niri/cfg/desk-1-home.kdl b/dotfiles/zz-blankpad/niri/.config/niri/cfg/desk-1-home.kdl index 96a4bcd..9558369 100644 --- a/dotfiles/zz-blankpad/niri/.config/niri/cfg/desk-1-home.kdl +++ b/dotfiles/zz-blankpad/niri/.config/niri/cfg/desk-1-home.kdl @@ -7,10 +7,14 @@ // requires: Lenovo Group Limited 0x40A9 Unknown // optional: HDMI-A-1 (PM1601, dock-dependent) -// This panel's EDID tops out at 3440x1440@180 (read live from niri: no 240 Hz mode -// exists). Ask for a mode the panel does not offer and niri does not fail — it logs -// "could not be found, falling back to preferred" and drops to 60 Hz on every -// reconnect. Keep 180 here unless a re-read EDID says otherwise. +// The panel offers 3440x1440@239.998 as well as @180.000 (`niri msg outputs`, 2026-10-21), and +// 180 is driven DELIBERATELY: the link trained at x8 32.0 GT/s against a max of x16 and the +// display engine is throwing DMCUB errors with EINVAL page flips after s2idle, so the 240-class +// mode stays undriven until a reboot clears that state. niri matches mode strings VERBATIM and +// does not round: "@239.999" is not "@239.998", and a mode it cannot find does not fail — it +// logs "could not be found, falling back to preferred" and drops the panel to 60 Hz on every +// reconnect, which is how this desk ran for weeks. Copy the string from `niri msg outputs`. +// Reasoning and triage: omp-docs/tools/niri/displays.md ("The config pattern", rules 4 and 5). output "Sceptre Tech Inc Sceptre M34 Unknown" { mode "3440x1440@180.000" scale 1 diff --git a/omp-docs/tools/niri/displays.md b/omp-docs/tools/niri/displays.md index 5de8498..6d7a41b 100644 --- a/omp-docs/tools/niri/displays.md +++ b/omp-docs/tools/niri/displays.md @@ -41,17 +41,19 @@ list it as an installed tool are stale. │ 1200x1920 │ landscape, scale 1 │ scale 1 │ │ rot 90 │ position 1581,-600 │ 5021,-240│ └──────────────┴──────────────────────────────┴──────────┘ - HDMI-A-1 DP-2 (focus-at-startup) eDP-1 (fallback focus) + HDMI-A-1 DP-1 (focus-at-startup) eDP-1 (fallback focus) +Connector names are today's (`niri msg outputs`, 2026-10-21). They reshuffle with +the dock and the cable, which is why the config keys on the EDID long name instead. ``` | Panel | EDID long name | Keyed by | Notes | |-------|----------------|----------|-------| -| Sceptre M34 ultrawide | `Sceptre Tech Inc Sceptre M34 Unknown` | identity | `mode "3440x1440@180.000"` — the EDID maximum; no 240 Hz mode exists — `focus-at-startup` | +| Sceptre M34 ultrawide | `Sceptre Tech Inc Sceptre M34 Unknown` | identity | `mode "3440x1440@180.000"`, **deliberate** — the panel also offers `3440x1440@239.998`, `144.001` and `120.000`; 180 is driven while the link is degraded (see the law below) — `focus-at-startup` | | PM1601 portrait | *not captured* | connector `HDMI-A-1` | dock-dependent; run `desk.sh capture` when plugged in, then re-key | | eDP-1 laptop panel | `Lenovo Group Limited 0x40A9 Unknown` | identity | scale **1.0** (deliberate; Ghostty grid at 1.25 rejected 2026-10-09), second `focus-at-startup` | -VRR: DP-2 supports it; **left disabled by decision** (2026-10-09). Add -`variable-refresh-rate` per output if that ever changes. +VRR: the M34 supports it (its connector today is `DP-1`); **left disabled by +decision** (2026-10-09). Add `variable-refresh-rate` per output if that ever changes. `focus-at-startup` on both M34 and eDP-1: niri focuses in config order, so the ultrawide wins when present and the laptop panel is the fallback. @@ -113,12 +115,22 @@ Four rules learned the hard way: 3. **Positions are absolute, not relational.** A disconnected panel leaves a hole; that is exactly why positions belong to the *desk profile*, not a global file. -4. **Ask only for modes the panel reports** (`niri msg outputs` → `Mode:` list). - A mode the panel never offered does **not** leave the output dark: niri logs - `configured mode … could not be found, falling back to preferred` and quietly - drives the panel at its EDID *preferred* mode — **60 Hz** on the M34. Nothing - looks broken except the refresh rate, and every reconnect repeats the - fallback. Check Hz, not just resolution, after any "monitor is acting up". +4. **Ask only for modes the panel reports, and copy the string exactly.** The M34's + `Available modes` (`niri msg outputs`, 2026-10-21) are `3440x1440@239.998`, + `3440x1440@180.000`, `144.001`, `120.000`, … with `59.998` marked preferred. niri + matches mode strings **verbatim** and does not round, so `239.999` — one digit from + the real mode, which is what this file and the config both carried for weeks — is not + `239.998`. A mode it cannot find does **not** leave the output dark: niri logs + `configured mode … could not be found, falling back to preferred` and quietly drives + the panel at its EDID *preferred* mode — **60 Hz**. Nothing looks broken except the + refresh rate, and every reconnect repeats the fallback. Check Hz, not just + resolution, after any "monitor is acting up". +5. **180 Hz here is a decision, not a ceiling.** The panel offers 239.998 and is driven + at 180.000 deliberately: the link trained at `x8 32.0 GT/s` against a max of `x16`, + and the display engine is throwing `DMCUB` errors with `EINVAL` page flips after + s2idle, so the 240-class mode is not driven until a reboot clears that state. Before + changing the mode, re-read `niri msg outputs` **and** the link sysfs; treat "restore + 240" as a change to verify on a healthy link, never as the obvious fix. Refs #60. ## "The monitors are broken" — three layers, three signatures