fix(windows): explicit DDC/HMONITOR pairing + About v-prefix (v7.0.11)#2
Merged
Merged
Conversation
Three independent fixes bundled per the user's request.
1) About page: Latest version no longer rendered with leading "v"
- The Latest row pulled the GitHub release tag verbatim ("v7.0.10")
while Version came from `tauri.conf.json` without prefix ("7.0.10").
They now both render unprefixed; semver comparison still uses the
raw tag, so update detection is unchanged. New regression test in
`AboutPanel.test.tsx`. Engine label updated from the stale "Tauri +
Rust Sidecar" to "Tauri + Rust (in-process)" — v7.0.0 dropped the
sidecar; the label was lying.
2) Verified no server / sidecar is spun up
- `grep -r 'SERVER_PORT|externalBin|tauri-plugin-shell|find_available_port'`
across `src-tauri/` finds zero matches. Auto-update doesn't need a
local server — `AboutPanel.tsx` queries
`api.github.com/repos/synle/display-dj/releases/latest` directly.
Also refreshed `sidecar_cache.rs` docstring (now an in-process
cache, name retained from v6.x).
3) Windows external brightness: explicit DDC ↔ HMONITOR pairing
- Previous code called `ddc_winapi::Monitor::enumerate()` and
`enum_hmonitors()` independently, then `zip`'d the two Vecs by
index. `EnumDisplayMonitors` is not documented to return the same
callback order across two separate invocations — when the orders
drift, `SetVCPFeature` targets the wrong physical monitor and the
gamma write goes to the correct HMONITOR (i.e. opposite displays),
giving a visible no-op on the panel the user is actually adjusting.
- Fix: enumerate HMONITORs once, then per HMONITOR call
`ddc_winapi::get_physical_monitors_from_hmonitor(hm)` and wrap each
`PHYSICAL_MONITOR` via `Monitor::new`. Pairing is now explicit and
per-HMONITOR — orderings can no longer drift.
- Same strategy applied to `WinPlatform::debug_info()`; each DDC
entry now carries `hmonitor_index` so future diagnostic dumps
anchor DDC results to specific physical displays.
- Added `hmonitor_to_winapi()` helper for the `windows` → `winapi`
HMONITOR pointer cast.
- Documented the local patch in `VENDORING.md` so a future vendor
refresh re-applies (or upstreams) it.
Tests
- `cargo test --lib`: 236 passed
- `npm test`: 116 passed (added one regression test for the v-prefix
strip in `AboutPanel.test.tsx`).
Version
- 7.0.10 → 7.0.11 (`tauri.conf.json`, single source of truth)
Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com>
synle
added a commit
that referenced
this pull request
May 13, 2026
Rolls forward from 7.0.11 (#2) so /release-official has a clean version to dispatch against; v7.0.11 was never published (the dispatched build was cancelled). Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com>
synle
added a commit
that referenced
this pull request
May 13, 2026
The flexi_logger experiment (v7.0.16 + v7.0.17) was reverted in the two prior commits because the v7.0.16 build hung on the Ubuntu CI runner (24 min vs 7 min baseline on the same matrix; v7.0.17 retry hung again at 5+ min after a clean redispatch). Linux Tauri builds on `ubuntu-22.04` runners are sensitive to slow-to-compile transitive deps; flexi_logger 0.31 pulls `notify-debouncer-mini`, `nu-ansi-term`, `crossbeam-channel`, and a few others that bloated the dep graph. Rather than spend another release cycle debugging the dep tree, roll back to the v7.0.15 logging stack — env_logger + the custom TeeLogger fanout into `write_debug_log_unbound`. Slower-on-paper than buffered async writes, but builds cleanly on every platform and is the configuration that was actually shipping logs to disk for the user. Skipping 7.0.16 (published) and 7.0.17 (draft) since those tag names are already claimed on GitHub releases. v7.0.18 is the next clean slot. The Linux force-mode DDC fix (v7.0.14), Windows DDC pairing fix (#2 → v7.0.11), and Windows force-mode DDC write + verify-read + TeeLogger setup (v7.0.13 + v7.0.15) all remain on `main`. Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three independent fixes bundled per a single user request.
vfrom the GitHub release tag so the Latest row aligns with the Version row (both render7.0.11, notv7.0.11). Semver comparison still uses the raw tag so update detection is unchanged. Also updated the staleTauri + Rust Sidecarengine label toTauri + Rust (in-process)— v7.0.0 dropped the sidecar; the label was lying.src-tauri/forSERVER_PORT|externalBin|tauri-plugin-shell|find_available_portreturns 0 hits). Auto-update doesn't need one —AboutPanel.tsxqueries the public GitHub releases API directly. Refreshed the now-misleadingsidecar_cache.rsdocstring (now a pure in-process cache, name retained from v6.x).ddc_winapi::Monitor::enumerate()andenum_hmonitors()independently and zipped them by index, relying onEnumDisplayMonitorsreturning the same callback order across two separate invocations (not documented to be stable). When the orderings drift,SetVCPFeaturetargets the wrong physical monitor while the gamma write goes to the correct HMONITOR — visible no-op on the panel the user is actually adjusting. The fix enumerates HMONITORs once, then per HMONITOR callsddc_winapi::get_physical_monitors_from_hmonitor(hm)and wraps eachPHYSICAL_MONITORviaMonitor::new. Pairing is now explicit. Same strategy applied todebug_info(); each DDC entry now carrieshmonitor_indexso future dumps anchor DDC results to specific displays. Documented the local patch inVENDORING.mdfor the next vendor refresh.Test plan
cd src-tauri && cargo test --lib— 236 passednpm test— 116 passed (added regression test for the v-prefix strip)7.0.11(no leadingv) and Engine readsTauri + Rust (in-process).ddc_monitors[*]entry includeshmonitor_indexpointing at the matchinghmonitors[*]row.vcp_brightnessis paired with its own HMONITOR (in which case the panel genuinely doesn't expose DDC and we'd need a different write path).🤖 Generated with Claude Code