DaVinci-Resolve-Omarchy/omarchy-upstream-fixes/README.md

# Upstream fixes for Omarchy

Fixes found while getting DaVinci Resolve working on Omarchy that belong
**upstream in [omarchy](https://github.com/basecamp/omarchy)** rather than in
this installer script.

Each file here is a **self-contained handoff**: one numbered Markdown file per
fix, containing everything needed to raise the PR with no other context —
symptom, root cause with evidence, the exact patch, verification already
performed, how to re-verify, and reviewer caveats. Hand one file to a person or
an AI and they can open the PR from it alone.

| #   | Fix                                                              | Target file                                | Status         |
| --- | ---------------------------------------------------------------- | ------------------------------------------ | -------------- |
| 001 | [Resolve's main window is covered by the bar](001-resolve-bar-overlap.md) | `default/hypr/apps/davinci-resolve.lua` | raised ([#6429](https://github.com/basecamp/omarchy/pull/6429)) |
| 002 | [Resolve's dialogs trap the pointer](002-resolve-dialog-focus-trap.md) | `default/hypr/apps/davinci-resolve.lua` | raised ([#6430](https://github.com/basecamp/omarchy/pull/6430)) |

## Raising 001 and 002 — read first

Both fixes append to the **same file**, `default/hypr/apps/davinci-resolve.lua`,
and both diffs are anchored on the same context (`@@ -6,3 @@`, the end of the
original 8-line file). **Whichever lands first will make the other's patch fail
to apply.** They are otherwise independent — different properties, order between
them doesn't matter.

**Raise them as two PRs, 001 first. Do not combine them.**

Combining is tempting — same file, both small — and it does sidestep the patch
conflict. That's the weakest consideration: rebasing 002 after 001 lands means
appending two rules to the end of a file, with no semantic conflict.

The reason to keep them apart is that they carry very different risk:

| | 001 (bar overlap) | 002 (focus trap) |
|---|---|---|
| Nature | purely additive — a new rule for a window that had none | **narrows a rule a maintainer added deliberately** |
| Verified | end-to-end, including negative cases | end-to-end — cold-start A/B, plus hands-on main-window and popup checks |
| If wrong | fails safe — rule stops matching, old behaviour returns | popups vanish on mouse-out: worse than the bug being fixed |
| Likely review | uncontroversial | may attract debate (`mouse_refocus`, blocklist fragility) |

002 touches `stay_focused`, which exists for a documented reason, and carries an
open design question for a maintainer (see its §7). Coupling them makes the
clean, low-risk fix wait on the more debatable one for no benefit.

Both are now fully verified, so 002 no longer needs holding — raise them in
close succession, 001 first.

If a maintainer explicitly asks for them together, use the combined end state
below as the target — one PR, two commits.

### Combined end state (both fixes applied)

```lua
-- DaVinci Resolve window focus handling. Kept fully opaque: the default
-- translucency distorts colour-critical grading work.
o.window(".*[Rr]esolve.*", {
  float = true,
  stay_focused = true,
  tag = "-default-opacity",
  opacity = "1 1",
})

-- Resolve's floating main window ignores the bar's reserved zone, so the bar
-- covers its menu bar; fullscreen renders above top-layer surfaces. Scoped by
-- title so the splash and Project Manager keep their natural size.
o.window({ class = ".*[Rr]esolve.*", title = "^DaVinci Resolve - .+$" }, { fullscreen = true })

-- stay_focused above stops Resolve's transient popups closing on mouse-out
-- (hyprwm/Hyprland#12235), but pinning the windows they open over makes two
-- windows fight for focus and traps the pointer. Unpin the parents only.
o.window({ class = ".*[Rr]esolve.*", title = "^(DaVinci Resolve - .+|Project Manager)$" }, { stay_focused = false })
```

### State the testing accurately

Both fixes are verified end-to-end; each file's §5 lists exactly what was
measured and what was checked by hand. Two things are worth carrying into the
PR bodies rather than quietly dropping:

- 002's parent list is a **blocklist** that may need extending (its §7).
- 002 has an **open design question** — whether `input:mouse_refocus` makes the
  whole `stay_focused` rule obsolete on Hyprland 0.56.1. Not tested, because it
  is a global setting and that is a maintainer's call.

## Conventions

- **Filename:** `NNN-short-slug.md`, numbered in the order found.
- **Status:** `ready to raise` → `raised (#PR)` → `merged` / `rejected`. Update
  the table above when it changes.
- **Evidence over assertion.** Every claim about behaviour should be backed by
  command output pasted into the file (`hyprctl`, `grim` pixel samples, logs),
  so a reviewer can judge it without reproducing the setup.
- **State what was actually tested**, including the environment (Hyprland and
  Omarchy versions, GPU, resolution/scale). If something was reasoned about but
  not run, say so explicitly.
- **Record rejected alternatives** and why, in the caveats section — it saves
  the reviewer re-proposing them.

## Relationship to the installer

Until a fix lands upstream, `Omarchy_resolve_v2.sh` applies its own local
equivalent so the installer works today. Those local workarounds are marked in
the script with a comment pointing back to the fix number here. Once a fix is
merged upstream the local workaround becomes redundant — harmless, but it can
then be dropped.