omencore

OmenCore is an independent control center for HP OMEN and Victus systems. It focuses on the local workflows people actually use in OMEN Gaming Hub: fan control, performance profiles, telemetry, keyboard lighting, OSD, power tools, diagnostics, and safe cleanup of HP background software.

It runs without ads, account prompts, cloud telemetry, or OMEN Gaming Hub. Hardware access is handled through local WMI BIOS, EC, PawnIO, Linux sysfs, and platform backends when the device exposes them.

More screenshots (CPU/GPU Tuning)

At A Glance

Why People Use It

Current Release

Version: 4.3.1

Released: 2026-09-15

Status: Test-verified (1455/1455 tests, 0 build warnings). Patch release that grew into a broader maintenance cycle: a real, provable config-persistence data-loss bug, a broken auto-updater SHA256 check (and the release-process bug behind it), an OMEN-key WMI event bug, two MainViewModel/SystemControlViewModel decomposition passes, three board database entries, and two rounds of cross-project review against a similar tool ("Ohman"). Every fan/EC/thermal/OC/UV-behavior change has field validation except one, stated honestly rather than glossed over: the OMEN-key fix (#193) is root-caused with strong evidence but not yet reconfirmed by the reporter on their board (8D2F) as of release.

Release notes: docs/CHANGELOG_v4.3.1.md

Roadmap: docs/ROADMAP_v4.3.1.md

v4.3.1 started as field-report fixes for two GitHub issues opened right after v4.3.0 shipped and grew from there. The standout is a real, provable data-loss bug: ConfigurationService was handing out a fresh, detached copy of the config on every load instead of a shared instance, so at least three parts of the app could each hold a stale snapshot and silently overwrite whatever a different part had just saved — a custom fan curve or AMD power limit that "vanished" after doing something unrelated elsewhere in the app was this, not user error. Also fixed: the auto-updater's SHA256 check had been silently matching nothing since the release-notes hash-table format changed, so it always fell back to manual-download-only regardless of content — and the release-process bug that caused past release notes to carry the wrong hash in the first place is fixed at the source (this release's own hashes are generated by CI from the exact published files, not hand-copied from a separate local build). An OMEN-key WMI event bug is fixed for boards where the keyboard hook never sees the physical key. Two rounds of cross-project review against a similar open-source tool ("Ohman") produced a GPU-idle-polling backoff and a firmware-aware fix for unverified boards' fan-control assumptions.

v4.3.1 Highlights

• Fixed (data loss): saved settings — a custom fan curve, a custom AMD CPU Power Limit — could silently revert after doing something unrelated elsewhere in the app, reported independently by two users on two different boards (#191). Root cause: ConfigurationService handed out a brand-new, detached config object on every load instead of a shared instance, so whichever of several stale in-memory copies saved last silently overwrote every other part's changes. Fixed by making every load converge on one shared, always-current object.
• Fixed: the auto-updater's SHA256 extraction regex never matched the release-notes hash table's actual format, so update checks always reported "missing SHA256" and fell back to manual-download-only regardless of content (#192).
• Fixed (release process): the hash mismatch above had a second half — past release notes carried hashes hand-copied from a separate local build, which don't match what CI independently rebuilds and publishes (#194). build-installer.ps1 now generates a real SHA256 for both Windows artifacts, and the release workflow publishes hashes read back from the exact files it just built — this release's own hash table above is proof it works.
• Fixed: OMEN key WMI events were being unconditionally discarded whenever the keyboard hook was active, on the assumption the hook would also catch the key — on boards where the physical key produces no keyboard-observable code at all, that threw away the only real signal (#193).
• Fixed: the entire Settings → Notifications section (master switch, Game/Mode-change notifications, Temperature warnings) saved correctly but was never applied to the live notification service, at startup or after being changed.
• Fixed (Ohman cross-check): unverified boards no longer assume software fan control works when HP's own firmware-authored SystemDesignData explicitly says it doesn't — narrowly scoped to never second-guess a hand-verified board and never grant a capability a template didn't already claim.
• Fixed (Ohman cross-check): GPU telemetry now backs off to a 2-minute cadence once confirmed idle (3 consecutive low-utilization/low-power samples), since polling a discrete GPU at all can keep it out of its deepest idle power state.
• Added: four-zone keyboard lighting gets an actual drawn keyboard to click zones on, instead of four labeled rectangles — matching the per-key editor's existing visual approach.
• Added: Dashboard's CPU/GPU temperature numbers are bigger (32px → 52px), and the Razer Devices card uses Razer's real logo instead of a placeholder.
• Model database: board 8BAD was displaying as "OMEN 15" on a real 17" laptop, fixed; board 8C9C gets a real, field-confirmed database entry (two Guided Fan Verification runs, 84-88/100) instead of generic family fallback; board 8E35's notes corrected to flag a CPU-identity conflict between two independent reports instead of asserting either one.
• Architecture: MainViewModel (6,275 → 4,665 lines, -26%) and SystemControlViewModel (5,610 → 5,290 lines) both decomposed further — UpdateViewModel, GpuClampViewModel, and SystemMaintenanceViewModel extracted, plus dead-code deletion. Pure structural refactors, no fan/EC/thermal/undervolt/GPU-OC write path touched.

Full detail on every item in docs/CHANGELOG_v4.3.1.md.

v4.3.0 Highlights (previous release)

• Fixed (safety): the Quiet Safety Monitor's "power mode retained" guarantee during a Max-fan safety override was silently undone by Fan/Performance linking, cascading into an unwanted performance-mode switch on a transient CPU spike (#181). Fixed with an explicit suppress-linked-sync flag threaded through the one caller that needs it; every user-initiated Max Fan trigger is unaffected.
• Fixed (Linux, high-severity safety): switching Max → Auto under load could leave both fans at 0 RPM indefinitely on a board with degraded ACPI, ending in a real thermal shutdown (#183). Now polls RPM after the write and falls back to the board's own confirmed-working Max path if both fans are still dead above a conservative safety bar.
• Fixed (stability): a recurring native AccessViolationException in the AMD ADL telemetry path on hybrid AMD+NVIDIA hardware — killed 3 of 4 full test runs before being traced and quarantined the same way the out-of-process hardware worker already protects itself.
• Fixed: Power Automation force-applied the configured AC/Battery preset on every startup regardless of whether the power source had actually changed, silently discarding a manual mid-session profile choice. Now compares against the last-confirmed power state and no-ops when nothing changed.
• Fixed: built-in "Night Mode"/"Work" RGB scenes shipped with a baked-in, un-opt-out-able daily schedule and zero UI to see or disable it — every install silently changed keyboard lighting at 10PM/9AM regardless of what the user had manually set, including explicitly off. The default schedule is removed; both scenes remain manually selectable.
• Fixed: model-capability fallback logic (used for any board without an exact database entry) defaulted to optimistic instead of conservative, claiming GPU Power Boost, independent fan curves, undervolt, and more as "Supported" on hardware never confirmed to have them (#182). Both fallback paths now assume nothing beyond WMI fan control and performance profiles by default.
• Fixed (Linux): GPU telemetry never queried NVML, so a real, working NVIDIA GPU read as 0°C/unavailable in both the CLI and GUI (#186) — fixed in three independent places that all had the same gap, plus GPU name/power/utilization now shown.
• Fixed (Linux): the OMEN key WMI watcher could register cleanly and then never receive a single event on some boards (#187) — traced to a server-side WQL filter silently never matching on affected hpqBEvnt schemas; the existing client-side validation already made a broader subscription safe.
• Fixed: 88EC (HP Victus 16-e0xxx) performance-mode switches did nothing at all — missing the same one-flag WMI-fallback fix already shipped for four sibling boards (#128 follow-up).
• Fixed: a Corsair DPI-editor write could show a confirmation dialog and update saved state for a write that silently never reached the mouse, plus a fabricated 100% battery reading; GPU Power Boost's wattage badge was hardcoded regardless of level, now level-aware with a firmware-ceiling caveat.
• Fixed: capability classifier's "Full Control" reason text could name the wrong control mechanism on Linux (#127, #126) — diagnostic-text only, no classification change.
• Added: four more automation trigger types promoted to the Settings UI (Temperature, Idle, Process, WiFi SSID — two of which had real bugs fixed as part of promoting them) plus a new Lid-close trigger, completing all seven backend trigger types shipped.
• **Add