DaVinci-Resolve-Omarchy/omarchy-upstream-fixes

Upstream fixes for Omarchy

Fixes found while getting DaVinci Resolve working on Omarchy that belong upstream in 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	default/hypr/apps/davinci-resolve.lua	ready to raise
002	Resolve's dialogs trap the pointer	default/hypr/apps/davinci-resolve.lua	ready to raise

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)

-- 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.