v1.4.6

UI responsiveness restored + CLI restored + temperature-policy fix.
v1.4.5's threading/safety sweep serialised hardware access correctly but left
the periodic EC/BIOS traffic on the WinForms UI thread, so a contended EC
mutex stalled the tray menu and window dragging for seconds (#98). v1.4.6
moves all periodic hardware access onto a dedicated background monitor
thread that publishes immutable sensor snapshots for the UI to render — the
message pump never waits on the EC again. On top of that: the CLI works again
(#101), a stuck EC temperature byte can no longer pin the fan curve (#97),
recoverable EC-lock timeouts no longer raise modal error boxes (#94), the
Set Display Off action no longer puts Modern Standby laptops to sleep (#103),
the model database gains 88ED and 8A3E, and 8A4F joins the 100 %-fan safety
list (#107).

Fixed

• Graphics → Set Display Off put the laptop to sleep (#103, reported by
  @Bart82). On Modern Standby (S0 low-power idle) systems Windows treats
  "display off" as the sleep entry point, so the SC_MONITORPOWER broadcast
  the action has always used now suspends the whole machine instead of just
  blanking the screen. OmenMon now holds ES_SYSTEM_REQUIRED on a dedicated
  background thread while the display is off and releases it on the first user
  input (which is also what wakes the display) — the screen turns off, the
  system keeps running, and normal sleep behaviour resumes the moment you
  return. Opt out with <DisplayOffKeepAwake>false</DisplayOffKeepAwake> in
  OmenMon.xml to restore the previous bare broadcast.
• CLI produced no output for any argument (#101, reported by @David112x).
  The redirection guard added to Cli.Initialize() in v1.4.2 (for the issue #76
  crash) early-returned whenever Console.IsOutputRedirected was true — but a
  GUI-subsystem process launched from cmd/PowerShell without redirection has
  NULL standard handles, which .NET also reports as "redirected". The console
  was therefore never attached and every CLI invocation (-Bios, -Ec,
  -Usage, …) wrote into the void. The guard now only skips attaching when a
  real non-console handle exists (Kernel32.GetStdHandle), so plain CLI use
  prints again while -Diag > file.md style redirection keeps working.
• Sluggish tray menu and "teleporting" window drag since v1.4.5 (#98,
  reported by @snowfallhateall). New GuiMonitor background thread owns all
  periodic hardware work — sensor sampling, the fan-program tick, thermal-panic
  checks, constant-speed countdown maintenance, and the BIOS heartbeat — and
  publishes an immutable MonitorSnapshot the UI thread renders lock-free. The
  tray menu and the main form no longer perform any EC/BIOS I/O on the UI
  thread during passive operation: opening the tray menu now requests one fresh
  sample off-thread and renders from the snapshot, instead of issuing EC reads
  (GetMode/GetMax/GetOff) that could block seconds behind the
  Global\Access_EC mutex. User-initiated control actions are serialised with
  the monitor through a single in-process hardware lock; balloon tips and
  fan-program status updates cross back to the UI thread via a message queue.
• CPU temperature stuck at a constant reading pinned the fan curve (#97,
  reported by @snowfallhateall, 8D87). On 8D87 the legacy CPUT register
  0x57 lands on firmware string data and reads a permanent 52 (ASCII '4').
  Platform.GetCpuTemperature() trusted CPUT whenever it was non-zero, so fan
  programs followed the 52 °C curve row while the die overheated. The CPU
  temperature is now the higher of CPUT and the WMI BIOS sensor — covering
  both known failure shapes (CPUT stuck non-zero, and CPUT reading 0xFF→0 as on
  8C9C/8BBE) with one policy that can only ever err towards more cooling.
• "Failed to acquire embedded controller exclusive lock" error boxes (#94,
  reported by @DreamStare0, also #96). EC-mutex timeouts on the periodic /
  recoverable paths (background monitor, AutoConfig startup thread, the
  Auto-Calibration worker) now degrade to a skipped operation that retries next
  tick, instead of a modal error box — the once-per-startup box (HP's own
  services hold Global\Access_EC at logon) and the repeated boxes during
  calibration sweeps are gone. User-initiated actions stay loud. Timeouts are
  counted and surfaced as a new "EC lock timeouts this session" row in -Diag
  so contention still shows up in field reports.
• Calibration pause race. GuiMonitor.Pause() could return while one last
  monitor pass was still about to start; the paused check now happens inside
  the pass gate, so after Pause() returns the wizard owns the hardware alone.

Added

• HP Victus 16-e0xxx (88ED, 2022) native model entry (#99, reported by
  @robbert1978). Classic 2022 layout (level 0x34/0x35, rate write
  0x2C/0x2D), 16-bit LE tachometers at 0xB0/0xB2 — exactly the preset
  the auto-detector chose on the reporter's machine, field-tested and now
  pinned natively.
• HP Victus 15-fb0102la (8A3E, 2023) read-only RPM mapping (#96, reported by
  @David112x). Confirmed 16-bit LE tachometers at 0xB0/0xB2 (CPU idle
  ≈435 — never fully stops — max ≈5404; GPU 0…≈5195 RPM), added to
  AutoCal.KnownBoards; fan control stays on the default 2022 layout the
  calibration sweep already drove successfully.
• HP Victus 15 (8A4F, 2023) added to the 100 %-fan safety list
  (FanArray.HasMaxFanFreeze) (#107, reported by @richardcofie). The
  auto-calibration plateau detector tripped at 30 %, with live RPM collapsing
  back to idle (CPU 5109→1585, GPU 4418→1597) rather than climbing — the
  physical-ceiling signature shared by the other rate-limiter boards. Fan
  registers are PeriodEncoded8 (CPU 0x2E, GPU 0x2F), so RPM stays
  sidecar-supported only (the <Models> schema is LE16-only) and the safety
  list is the protection that applies.
• -Diag: EC lock timeout counter in the Kernel Driver section (issue #94
  forensics).
• Model coverage notes (wiki): HP Omen 15-en0037AX (8787, #95) confirmed on
  the default 2022 layout — the probe's GetFanLevel "Unknown response from
  BIOS: 45" is expected on the 2020 generation and harmless; Victus 16-s1084AX
  (#100) documented as a pending second hardware variant behind 8C9C (real
  tachometers at 0xD6/0xD8) awaiting a -Diag Product ID confirmation
  before any shipped-mapping change.

v1.4.5: EC read-path hardening + field-report sweep

EC read-path hardening + field-report sweep. This release attacks the
root cause of the recurring "RPM = negative / millions" and bad-temperature
reports (#86) at the Embedded Controller read path itself, rather than per
board: a failed read now fails cleanly instead of returning a garbage byte,
16-bit reads are validated against torn high/low bytes, the monitoring tick
batches its reads under a single mutex hold, and the #88 busy-wait backoff is
graduated so it can no longer pin the EC mutex past its timeout. Plus a
lifecycle-lock and a memory-model fix on the threading side, a null-guard for
non-Optimus systems, a thermal-panic safety fix, a more robust auto-detector,
live fan telemetry in -Diag, and a batch of model-database / calibration
updates.

Fixed

• Garbage bytes after the EC wait fail-limit (A1, issue #86). WaitRead()
  returned true unconditionally once WaitReadFailCount exceeded EcFailLimit
  (15) — even though OutFull was never set — and the caller then read a
  stale/garbage Data byte. Because the counter only reset on success, a briefly
  wedged EC latched OmenMon permanently into the garbage path for minutes. This
  is the most likely common root cause of the recurring "RPM = negative /
  millions" and bad-temperature reports. A sustained wait-failure now returns
  false, so the retry wrapper keeps the last good value instead of fabricating
  one.
• Torn 16-bit reads (A2, issue #86). ReadWordImpl reads the low and high
  byte as two separate EC transactions, so an EC state change between them yields
  a self-inconsistent word (implausible RPM). ReadWord now requires two
  consecutive identical reads before trusting the value, falling back to the most
  recent successful read.
• Per-sensor EC lock churn on the monitoring path (A3, issue #86). Each
  EcComponent.Update() opened the driver and took/released the cross-process
  Global\Access_EC mutex on its own, so a monitor tick churned the lock once per
  sensor and widened the collision window with the kernel ACPI EC driver. New
  Hw.EcExecBatch() holds the EC open and the (reentrant) mutex for the whole
  tick; Platform.UpdateTemperature() reads the full sensor array inside one
  batch.
• EC wait backoff could exceed the mutex timeout (A4, issue #88). The #88
  backoff slept a full 1 ms per iteration while holding Global\Access_EC, so a
  Word read could pin the mutex past EcMutexTimeout (200 ms) and starve other
  waiters into ErrEcLock. Wait() now yields the timeslice (Sleep(0)) for a
  configurable EcWaitYieldCount (default 10) iterations before escalating to the
  1 ms sleep, cutting the worst-case per-Wait hold from 25 ms to 15 ms.
• EC lifecycle race (B1). Initialize()/Close() checked and set
  IsInitialized without synchronisation while reads ran from the GUI tick,
  AutoConfig thread, key handler and heartbeat — a use-after-close window. Both
  now run under a per-singleton lifecycle lock.
• gpuTempObserved data race (B2). The sticky observed-GPU-temperature flag
  is now volatile so its first-non-zero transition publishes deterministically.
• NullReferenceException in NvMuxGetState() on non-Optimus systems (C1).
  The mux registry key only exists on NV-Optimus laptops; the method now returns
  NvMuxState? and yields null when the key/value is absent instead of
  dereferencing it.
• Thermal-panic protection was tied to the dynamic tray icon (C3). The
  forced temperature read and CheckThermalPanic() lived inside the
  if(Icon.IsDynamic) branch, so turning the dynamic icon off silently disabled
  over-temperature protection. Thermal panic now runs on every icon tick whenever
  enabled (or a latched panic needs clearing), independent of icon mode, while
  still skipping the EC read when neither the icon nor panic needs it.
• 8A18 (OMEN 17 ck1000nw) post-calibration fan lock (issue #84). The
  confirmed 0xB0/0xB2 tachometers are now pinned in AutoCal.KnownBoards too,
  so Load()'s collision self-heal always has a verified built-in mapping to fall
  back to and a stale/foreign sidecar can no longer relock the fans.
• GPU fan row showed garbage on single-fan boards (issue #81, 8BB3). A
  Mapping.SingleFan flag now makes Prime() mirror the resolved CPU mapping onto
  the GPU when the board is single-fan and the GPU has no override, so both rows
  report the one real fan instead of decoding 0xF1 as a word.

Added

• More robust EC layout auto-detection (issue #37). The 2022 match no longer
  requires a live tachometer (idle fans / off-0xB0 tachs made it misfire to the
  2023 layout); a plausible fan level at the layout's setpoint register is required
  instead, and a fan-level fallback tier now handles boards whose CPUT is neither
  a valid temperature nor the 0xFF sentinel. Read-only and conservative.
• Live Fan Telemetry section in -Diag (issue #49). Per-fan BIOS level,
  duty-cycle rate, resolved live speed, and the exact register/mode/multiplier
  Fan.GetSpeed() used — so a wrong RPM is immediately traceable to the register.
• Native HP Omen Max 16 (8D41, 2025) entry (issues #87, #90). Graduated from
  the read-only AutoCal RPM mapping to a full <Model> entry with the confirmed
  16-bit LE tachometers at 0x5C (CPU) / 0x9F (GPU). Fan-control registers are
  the legacy defaults the unknown-model fallback already applied (non-regressive
  for control) and remain flagged unverified pending an owner -Diag.
• Omen 16-am1001nw coverage (issue #31). Documented as covered by the existing
  8E71 (Omen 16-am1xxx) entry; @Bart82's board is the same #88 EC-timeout
  reporter and benefits from the A4 backoff fix.
• EcWaitYieldCount configuration knob in OmenMon.xml (default 10), wired
  through Config/ConfigData, plus documentation of the EC-timing knobs and an
  RPM/temperature troubleshooting section (issue #14).
• HP OMEN 16 wd0xxx (8BA9, 2024) RPM read mapping (Library/AutoCal.cs
KnownBoards, issue #92 reported by @M1918IIBAR). The Auto-Calibration scan found
  a single 16-bit LE tachometer at 0xF1 and no GPU fan. The raw EC dumps confirm it:
  EC[0xF1..0xF2] decodes to 0x0701 = 1793 RPM at 0% (idle) and 0x1405 = 5125 RPM
  at 100% (max), matching the reported idle/max exactly and rising monotonically across
  the 0/30/70/100% steps — LE16, not the DirectMultiplier8 single-byte read 8BB3 uses
  (which would decode the 100% step as 0x05 × 100 = 500 RPM). Added as a read-only
  KnownBoards mapping flagged SingleFan, so RPM now displays correctly out of the box
  and the GPU row mirrors the one real fan instead of decoding 0xF1 as a second word
  (#81 pattern). No <Model> entry / fan-control registers are committed for this board —
  a wrong ManualReg/ModeReg could lock the EC — so fan control stays on the
  auto-detector's safe legacy fallback pending a confirmed register map.

Deferred (need confirmed data before a code change is safe)

• HP Omen 16-wd0004nw (#51 model / #75 calibration), xd0020ax (#77), and the
  AMD Ryzen 9 7945HS SKU (#85). No confirmed Product ID + register dump is
  available, and HP recycles Product IDs across regional/CPU variants — a prior
  7945HS-class report (#76/#85 on 8BCA) already gave conflicting tachometer
  layouts. Shipping a guessed register map risks garbage RPM or a fan-controller
  lock on other owners' machines. All are usable today via the read-only
  auto-detector + the Auto-Calibration wizard; documented under "Pending field
  reports" in wiki/Model-Database.md with exactly the -Diag/calibration data
  needed to promote each to the shipped database.

v1.4.4

Post-v1.4.3 field-report sweep. A small patch closing the non-pending issues that arrived after v1.4.3: a new board for the native model database, a tray-menu fan-control gap that left fans pinned at maximum after switching to an automatic mode, and a misleading Auto-Calibration report on boards whose RPM is already handled by a built-in mapping. No hardware-control behaviour changes beyond releasing Max Fan when the user picks a fan mode.

Fixed

• Fans stayed pinned at maximum after switching to an automatic mode from the tray menu (issue #77, reported by @AbhinavGenos on 8BCD). "Max Fan" is a separate BIOS toggle (SetMaxFan) from the fan mode (SetFanMode), and the tray fan-mode submenu's EventActionFanMode only called SetMode() — so choosing Auto/Default (or any mode) while Max Fan was engaged left the fans running at maximum. The main-window "Automatic" path already released Max Fan before switching (GuiFormMain), so this only affected the tray submenu. EventActionFanMode now releases a manually-engaged Max Fan when the user selects a mode, then re-asserts the mode so the fans return to the automatic curve. The release runs even when the chosen mode equals the current one — Max Fan can sit on top of any mode (the "already in Default, toggled Max Fan, now click Default to go back" case, where SetMode alone is a no-op). An active Thermal Panic is left untouched: it is a safety feature with its own max-fan state machine that would simply re-assert on the next hot tick. The change only ever lowers fan speed, so it cannot trigger the 100%-fan EC-freeze quirk on FanArray.HasMaxFanFreeze boards.
• Auto-Calibration report raised a false "no plausible registers / share your dumps" alarm on boards with a built-in RPM mapping (issue #81, reported by @jpcaldwell30 on 8BB3). The EcDiffScanner heuristic only recognises 16-bit LE tachometers, so single-fan boards that report RPM via DirectMultiplier8 (8BB3 at EC[0xF1]) or BiosLevelMirror (8C9C) always scanned blank — even though their live RPM is already correct from AutoCal.KnownBoards. The wizard now detects a KnownBoards match (AutoCal.IsKnownBoard) and, when the scan finds nothing, prints an "this is expected, RPM is already handled natively" note instead of the alarming default text. RPM behaviour is unchanged; this is a report-clarity fix only.

Added

• HP Omen (8A14, 2021) in the native model database (OmenMon.xml, issue #82 reported by @BinaryRider). Confirmed via the user's Auto-Calibration report: the raw EC dumps decode exactly to the reported live RPM for a 16-bit LE tach at 0xB0/0xB2 — at 100 % EC[0xB0..B1]=0A 0F → 3850 RPM (CPU) and EC[0xB2..B3]=D4 0E → 3796 RPM (GPU), matching the report's CPU max=3850 / GPU max=3796, with the idle step reading 0/0. FanLevel 0x34/0x35 tracks the commanded step and FanRate 0x2C-0x2F mirrors the percent, i.e. the canonical 2022 layout (identical register set to the 8A18 / 8A42 entries). The mode/switch/manual/countdown registers are inferred from the 2022 template and mirror what v1.4.1 auto-detection already applied for this ProductId, so the entry is non-regressive.

v1.4.3

Auto-Calibration clarity + crash patch. A field-report sweep (#74 / #76 plus a direct e-mail report on 88D2) showed the Auto-Calibration Wizard was working as designed on several boards but communicating badly — a deliberately-skipped 100% step read as "stuck at 70%", and a benign top-step RPM match raised a scary "PLATEAU DETECTED — add this board to the freeze list" alarm on healthy hardware. This release fixes the messaging, relabels two misidentified info fields, makes the wizard teardown release the fan rate registers (not just the level registers), and hardens the CLI exit path against an "invalid handle" crash. No new features; no hardware-control behaviour changes beyond the teardown completion.

Fixed

• CLI crash Exception: Nieprawidłowe dojście / "invalid handle" after a console command (issue #76, reported by @simoliguori). Cli.RestorePrompt() — the cosmetic "make the command prompt reappear" hack run on the first-instance CLI path (and from App.Exit()) — read Console.CursorTop, which calls GetConsoleScreenBufferInfo under the hood and throws a WinIOError when standard output is not a real console screen buffer (output redirected to a file/pipe, or the process launched without an inheritable console). That exception escaped to Main() and surfaced as the crash dialog in the screenshot. RestorePrompt() now wraps its console access in a best-effort try/catch (consistent with the codebase's graceful-degradation style) — when there is no usable console buffer there is simply nothing to restore, and the work the command already did is unaffected.
• Auto-Calibration report read as "stuck at 70%" on max-fan-freeze boards (issue #74, reported by @MartinSalg818, 8BAD). On a board in FanArray.HasMaxFanFreeze, the wizard intentionally filters the 100% step out of its profile (commanding 100% locks the EC until reboot on these models — the safety behaviour added in v1.4.1). But the report just showed Profile: 0% → 30% → 70% with no explanation, so a truncated sweep looked like a malfunction. The wizard now records that the omission was deliberate (CalibrationOutcome.MaxStepSkippedForFreeze) and the report carries a clear "100 % step intentionally skipped — <ProductId> is on the known freeze list, this is expected and not a malfunction" note above the Device block.
• False "PLATEAU DETECTED at 100 %" alarm on healthy boards (direct e-mail report, 88D2 HP Omen 15). The wizard's plateau detector fired on the final step too, where it could not prevent anything (the 100% command had already run) and where "top step ≈ previous step" is the normal case on boards whose manual fan-level scale already reaches the physical ceiling. The result was a prominent "the board is at its physical fan ceiling — please add 88D2 to FanArray.HasMaxFanFreeze" call-out on a board that is not freeze-prone (the owner confirmed the fans audibly spin faster at manual max). Plateau detection now only raises that alarm — and the safety-list recommendation — when a higher step was actually skipped (an actionable, freeze-preventing plateau). A no-gain reading on the last step is recorded as a neutral, informational note that explicitly does not recommend a safety-list addition, and points out the one case worth a closer look (a register mirroring the commanded level rather than a true tachometer).
• Auto-Calibration report labelled the BIOS born-date as "BIOS Build Date" (issue #74). The value comes from GetBornDate() — the factory manufacture/"born" date — not the firmware build or version. The mislabel led the reporter to flag 20240904 as wrong against their actual BIOS build (20260421). The report now reads BIOS Born Date with an inline "(factory manufacture date — not the firmware build/version)" clarification.
• Auto-Calibration Wizard could leave the fans pinned at the last commanded step after running (issue #74, reported by @MartinSalg818, 8BAD — follow-up to the v1.4.2 #65 fix). ApplyLevel() drives both the fan level registers and the per-fan rate registers on every sub-100% step, but the v1.4.2 teardown only released the level registers (writing 0xFF, 0xFF). On boards whose EC keeps driving the fans from the rate register after manual mode is released, the stale rate write left the fans stuck at the last step ("locks at 70%"). The wizard now captures each fan's rate register before the sweep and restores it in the teardown finally{}, symmetric with the existing level restore. Best-effort: a genuinely frozen EC ignores the restore writes and still requires a reboot, but a board that merely had a sticky rate register now recovers cleanly.
• GUI system-info line showed a bare CPU PL4 wattage that read as the power-adapter rating (issue #74). The main window printed GetDefaultCpuPowerLimit4() (the CPU Power Limit 4, in watts) as an unlabelled "200W" immediately before the AC-adapter status, so the reporter read it as a "200 W power brick" and flagged it against their real 330 W HP adapter. The wattage is now prefixed with a CPU PL4 label so it is no longer mistaken for the charger rating. (OmenMon does not read or display the AC-adapter's wattage — HP's smart-adapter BIOS call only returns a sufficient/insufficient status, not a rating.)

OmenMon v1.4.2-reborn: AC-flicker fan-switch fix & hibernation-guard hardening

OmenMon-Reborn v1.4.2

Power-management reliability release: stops spurious fan-profile switching from rief AC dropouts, hardens the hibernation guard, and adds three more laptop models.

Highlights

• No more random fan-profile switches mid-game from brief AC dropouts (#70).
  Some Omen/Victus SKUs report AC as "Offline" for a few seconds while still
  plugged in; OmenMon now debounces this (10 s hold + multi-sample confirmation +
  multi-source AC check + passive poll) instead of instantly swapping
  Power↔Silent and throttling the CPU.
• Hibernation / battery-glitch guard hardened (#59). The wake-lock that
  suppresses Windows' bogus Critical-Battery hibernate now asserts and releases
  reliably (no leaks, no phantom-active state). BatteryGlitchGuardHoldAlways is
  now an independent "never sleep while OmenMon runs" switch — the bulletproof
  option if your machine still misreports battery.
• GPU fan no longer ramps on CPU temperature when the dGPU is idle/off (#66).
• Auto-Calibration fixes: detects low idle-RPM fans (#64) and no longer
  leaves fans locked at ~3500 RPM after a run (#65).

New laptop models

• HP OMEN 17 ck1000nw (8A18) — #72
• OMEN 16z-n000 (8A42, 2022) — #68
• HP Victus 16 (8BB3, 2024 AMD) — #64
• HP Victus 16 (88F4, 2022)

New configurable settings (OmenMon.xml)

AcFlickerGuard, AcFlickerHoldMs, AcFlickerConfirmSamples,
AcFlickerConfirmIntervalMs, AcFlickerMaxDeferralMs, AcFlickerPassivePoll,
plus BatteryGlitchGuardOnBattery / DisableTimeout / HoldAlways. See the
Battery-Glitch-Guard wiki page.

Closes #59, #64, #65, #66, #68, #70, #72.

Fixed

• Random fan-profile switches mid-game caused by brief AC dropouts (issue #70, reported by @MartinSalg818; #59 reported by @NotDarkn confirms the cluster). Some HP Omen / Victus laptops occasionally report PowerLineStatus as Offline for a few seconds even though the laptop is physically plugged in (confirmed in the user's powercfg /batteryreport against AC adapter telemetry). Before this fix, SystemEvents.PowerModeChanged → GuiTray.EventPowerChange → GuiOp.PowerChange() reacted immediately and — when AutoConfig=true and a fan program was active — switched from FanProgramDefault (Power) to FanProgramDefaultAlt (Silent → caps the system to Base Power), producing visible CPU/power-throttling stutters during gameplay until AC was reported back ~2 s later. The same handler also flipped the BIOS heartbeat enable/disable state. The fix is a five-layer defence:

  1. AC-flicker debounce. On a StatusChange event the actual reaction (fan-program switch + heartbeat toggle + main-form refresh) is deferred to the next EventTimerTick that arrives after AcFlickerHoldMs (default 10000 ms — bumped from the first-pass 8 s after re-reading the field reports, several of which describe ~10 s flickers).
  2. Multi-sample confirmation. When the hold window elapses the deferred handler now reads IsFullPowerConfirmed AcFlickerConfirmSamples times (default 3) with AcFlickerConfirmIntervalMs (default 250 ms) between reads and only acts if every sample agrees. A dissenter re-queues the deferral; the cascade caps at AcFlickerMaxDeferralMs (default 60000 ms) so a pathological flapper still reaches a decision in bounded time.
  3. Multi-source AC check (Settings.IsFullPowerConfirmed). Cross-references three independent signals — Windows PowerLineStatus, BatteryChargeStatus.Charging, and the HP firmware smart-adapter query (BIOS Cmd Legacy 0x0F) — and treats AC as connected when any of them confirm it. The BIOS call is gated so it only runs when both Windows signals report battery, keeping the common-case cost identical to IsFullPower. Used by the new confirmation gate, the passive poll, the heartbeat-resume path, and Op.PowerChange.
  4. Passive AC-state poll. The GUI timer tick now checks PowerLineStatus and synthesises a deferred change when the live state diverges from Op.FullPower without a PowerModeChanged event already in flight, recovering from cases where Windows drops or coalesces the event during rapid-fire flickers. Controlled by AcFlickerPassivePoll (default true).
  5. PowerGuard AC-offline release debounce. The percent-glitch guard's "release wake-lock on AC offline" branch (which existed to ensure a genuine critical-battery state could still hibernate) used to fire the instant PowerLineStatus flipped to Offline, silently defeating the guard whenever an AC flicker coincided with a percent torn-read (#59-style symptom on the same SKUs). The release is now gated on AcFlickerHoldMs of sustained Offline and an IsFullPowerConfirmed cross-check. Inside that window the percent-glitch state machine keeps running normally so a coinciding torn percent read is still detected.

  Configurable in OmenMon.xml: AcFlickerGuard (boolean, default true), AcFlickerHoldMs (default 10000, range 0..60000), AcFlickerConfirmSamples (default 3, range 1..20), AcFlickerConfirmIntervalMs (default 250, range 10..2000), AcFlickerMaxDeferralMs (default 60000, range 1..60000), AcFlickerPassivePoll (boolean, default true). Set AcFlickerGuard=false or AcFlickerHoldMs=0 to restore the immediate-switch behaviour from earlier builds. The guard is independent of the existing BatteryGlitchGuard (which targets a different symptom — a torn battery-percent read while still on AC) and the two run side by side; the PowerGuard change above is the bridge that makes them coexist correctly when both fire at once.

• Auto-Calibration Wizard locked fans at ~3500 RPM after running (issue #65, reported by @MartinSalg818). In the wizard teardown finally cleanup block, if the system was on automatic BIOS control before running calibration, OmenMon now writes 0xFF, 0xFF to clear custom levels and release control back to the BIOS.

• GPU fan curves reacted to CPU temperature when GPU is idle/off (issue #66, reported by @Bart82). Gated the CPU temperature fallback in FanProgram.Update() using a new helper Platform.HasObservedGpuTemperature(), which returns true once GPTM has produced a single non-zero reading since startup. When a physical GPU is present but powered off (0 °C), the flag stays latched true from earlier samples and the GPU fan stays at idle instead of ramping up under CPU load; on boards that genuinely have no GPU temp sensor the flag never latches and the CPU-temp fallback runs as in v1.4.1. (Initial v1.4.2 PR proposed a HasGpuTemperatureSensor() helper that inspected the configured sensor list, but the default global <Temperature> config always contains GPTM regardless of hardware, so the check evaluated true everywhere — Copilot review #1 on the v1.4.2 PR; corrected before release.)

• PowerGuard.AssertGuard could leave internal state ahead of OS state (Copilot review #3 on the first v1.4.2 PR pass + Copilot review #1 on the second pass). Two bugs in the same code path: (1) when the underlying SetThreadExecutionState P/Invoke threw, the original BatteryGlitchGuardHoldAlways branch still wrote guardUntil = DateTime.MaxValue, so IsGuardActive() would have returned true permanently while the OS never received the wake-lock request; and (2) SetThreadExecutionState actually signals failure via its return value + GetLastWin32Error() rather than by throwing, so the first-pass fix that only caught exceptions still rubber-stamped failed calls as successful. AssertGuard now returns bool reflecting real success: it captures the ExecutionState return value, and when it is None (0) disambiguates a genuine failure from the legitimate "previous state was None on the first call after process start" case via Marshal.GetLastWin32Error(). The P/Invoke in External/Kernel.cs was already declared SetLastError=true for exactly this purpose. HoldAlways and transient-glitch latches both only advance on a confirmed success. Round-3 re-review hardened this further: (a) the last-error is now explicitly cleared via a new Kernel32.SetLastError(0) P/Invoke immediately before the call, because Windows does not guarantee clearing last-error on success and a stale value would otherwise misread the "previous state was None" path as a failure; (b) BatteryGlitchGuardHoldAlways is now evaluated before the BatteryGlitchGuard master-switch early-return, so it works as an independent "block sleep/hibernate while OmenMon runs" toggle even when the percent-glitch guard is disabled; and (c) IsGuardActive() now keys off guardUntil rather than the config flags, so a failed SetThreadExecutionState is never reported as an active guard.

• Auto-Calibration Wizard failed to detect CPU fan on low idle speeds on 8BB3 (issue #64, reported by @jpcaldwell30). Lowered DirectMultByteMin threshold in EcDiffScanner.cs from 10 to 2 to support low fan idle speeds (e.g. 300 RPM / 0x03). Also fixed the 2023+ Layout B heuristic check in AutoDetector.cs to allow cput == 0x0F (observed on AMD-based 8BB3).

Added

• HP Victus 16 (8BB3, 2024, AMD) in the native model database (OmenMon.xml). Stamped CPU fan speed register at 0xF1 (DirectMultiplier8) and mapped it natively in AutoCal.KnownBoards.
• OMEN by HP Gaming Laptop 16z-n000 (8A42, 2022) in the native model database (OmenMon.xml, issue #68 reported by @GGoose). Confirmed via the user's -Diag report: AutoDetector matched the canonical 2022 layout — CPUT plausible at 0x57, 16-bit LE tach at 0xB0/0xB2 — and BIOS reports GetFanCount=2, GetGpuMode=Optimus, Fan1=Cpu / Fan2=Gpu. GPTM at 0xB7 flips between 0x00 and ~0x27 (39 °C) as the discrete GPU parks under Optimus, so the new HasObservedGpuTemperature st...

OmenMon v1.4.1-reborn: v1.4.1-reborn — Microsoft Defender cleared, VirusTotal 0/76, first-week field-report sweep

First-week-after-v1.4.0 field-report sweep. Patch release addressing the cluster of issues that arrived once the Auto-Calibration Wizard reached users on entry-level Victus 15/16 SKUs whose physical fan ceiling sits below the BIOS rate-limiter's threshold — plus a CLI redirection fix, a GpuMode-detection fix and a Battery-glitch-guard hardening pass surfaced while triaging issue #37 and Copilot's review on PR #60.

---

🛡️ Independently verified — clean on every engine surveyed

Check	Result	Reference
Microsoft Defender	✅ Cleared by Microsoft analyst — "do not meet our criteria for malware or potentially unwanted applications. The detection has been removed."	Submission ID 504e5120-8e6f-46c6-bf5f-da34a0176fca
VirusTotal	✅ 0 / 71 detections across all engines queried	view full report
Kernel access	Microsoft-signed PawnIO driver only — no proprietary .sys shipped	Resources/PAWN_BUILD.md

If Defender still flags it on your machine

The detection is already cleared on Microsoft's end — your locallient may just be holding a cached signature. From an elevatedommand prompt:

cd "C:\Program Files\Windows Defender"
MpCmdRun.exe -removedefinitions -dynamicsignatures
MpCmdRun.exe -SignatureUpdate

Expected output: Dynamic Signature removal — Done! followed bySignature update finished. Full background in
SECURITY.md.

How to verify your download

This release ships a SHA256SUMS.txt asset (auto-generated by CI)alongside the .zip. Verify the integrity of your download:

# Windows / PowerShell
Get-FileHash -Algorithm SHA256 .\OmenMon-v1.4.1-reborn-Release.zip

# Linux / WSL / Git Bash
sha256sum -c SHA256SUMS.txt

A new build always produces a new hash (AssemblyFileVersion is stamped per build). The SHA256SUMS.txt is the single source of truth for this release — verify against it, not against an older release's hash.

---

Fixed

• Defensive 100 %-fan safety entry for HP Omen 16-wf1012nl (8C77)
  (issue #50, @stf1o). 8C77 added to FanArray.HasMaxFanFreeze. Raw EC dumps show the rate-limiter footprint at EC[0xD2] (PeriodEncoded8): the period byte goes 0xB2 → 0xD0 → 0x99 → 0xEC across 0/30/70/100 % — 100 % reads slower than idle, matching 8C30 / 8D07 / 8BAD / 8E35. Sidecar-supported, not native — the shipped <Model> schema only supports LE16, so a native entry would silently override the sidecar with junk LE16 readouts.

• Auto-Calibration Wizard misidentified CPU/GPU RPM on HP Omen(8D87, 2025)
  (issue #61, @snowfallhateall). 8D87 added natively with the real 16-bit LE registers (0x70 / 0x9F).

• Auto-Calibration Wizard misidentified CPU/GPU RPM on HP Omen 17(8600, 2019)
  (issue #42, @duskw4lker). 8600 added natively with the real 16-bit LE registers (0x45 / 0x47, revealed only under stress-test load).

• EC freeze on 8D07 and 8BAD during the wizard's 100 % step
  (issues #56 @ghend-oss, #58 @MartinSalg818). Both boards share the firmware rate-limiter signature of 8C30 — now in the safety list.

• Auto-Calibration Wizard misidentified CPU RPM at 0x30 on 8E35
  (issue #57, @ClockworkNirvana). 8E35 added natively (0xB0 / 0xB2 LE16) and included in HasMaxFanFreeze.

• GPU fan speed followed CPU temperature in custom fan curves
  (issue #62, @Bart82). FanProgram.Update() now performs two independent per-tick curve lookups using Platform.GetCpuTemperature() / GetGpuTemperature() instead of feeding GetMaxTemperature() to both fans. GPU falls back to CPU temp if its sensor returns 0.

• OmenMon.exe -Probe > probe.txt produced an empty file
  (issue #37, @Byteme-dot). App/Cli/Cli.cs now skips AttachConsole / AllocConsole when stdout or stderr is redirected, preserving OS-provided handles. Symmetric IsAttached tracking on the Close() path.

• GetGpuMode() always returned Discrete on newer boards
  (issue #37, @Byteme-dot). Hardware/BiosCtl.cs now tries Cmd.GpuMode / 0x52 first (matching the SetGpuMode side) and falls back to Cmd.Legacy only if the modern call fails.

Added

• HP Omen (8D87, 2025), HP Omen 17 (8600, 2019), HP Victus 15 (8E35) in the native model database.

• Wizard plateau detection (App/Cli/CliOpCalibration.cs).
  Generic detector: after each commanded fan step, the wizard reads
  live tachometer RPM. When both fans show <150 RPM gain compared
  to the highest prior step (and the latest reading is ≥ 1500 RPM),
  the wizard aborts higher steps. Catches future SKUs with the
  same firmware signature without needing a hardcoded
  HasMaxFanFreeze entry. Markdown report includes a "PLATEAU
  DETECTED — please report so <ProductId> can be added" callout.

• Battery-glitch hibernation guard (Library/PowerGuard.cs,
  issue #59). Watches SystemInformation.PowerStatus per GUI tick.
  If Windows reports a ≥ BatteryGlitchDropPercent battery drop
  within BatteryGlitchWindowMs while on AC, OmenMon tells
  Windows to skip the Critical Battery Action via
  SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED) for
  BatteryGlitchHoldMs, with a balloon tip showing before/after.
  AC-only by hard invariant — releases the held wake-lock
  immediately if AC is unplugged mid-glitch so a real
  critical-battery transition can still hibernate. Configurable via
  BatteryGlitchGuard, BatteryGlitchDropPercent,
  BatteryGlitchWindowMs, BatteryGlitchHoldMs in OmenMon.xml.

Hardened

• AutoCal.Prime() skips zero-register placeholder mappings.
  New guard requires either a non-zero CPU/GPU register or the
  BiosLevelMirror mode (which legitimately uses Reg = 0).
  Forward-protection for any future KnownBoards entry that uses a
  sentinel zero for one fan while configuring the other.

• Config.BatteryGlitchHoldMs bounds aligned with the ushort
  parser. Documented and enforced upper bound lowered to 60000 ms
  (was inconsistently documented as 600000 but loaded via
  GetWord / ushort). All three battery-glitch knobs now have
  matching, documented [1, 60000] (or [1, 100]) checks.

• CI auto-generates SHA256SUMS.txt as a release asset, so
  every release ships with a verifiable digest of the published
  .zip and the inner OmenMon.exe.

Deferred

• HP Omen 8BCD native database entry (issue #37, @Byteme-dot).
  Two independent reports against the same ProductId disagree on
  the fan-register layout — shipping either natively would put
  garbage RPM on the other user's machine. Both users'
  Auto-Calibration sidecars (OmenMon-AutoCal.xml) keep their
  installs working in the meantime. Resolution waits on
  independent confirmation of either layout from a third 8BCD
  owner.

Known issues (no actionable code fix yet)

• Random fan spikes during light browsing on 8DCD (issue #49,
  @LightningFang). Diagnosed as an EC polling collision between
  OmenMon and a concurrent EC consumer (MSI Afterburner with an
  active overclock was the confirmed culprit in the reported case).
  Mitigation is environmental: close any third-party software
  polling the EC at sub-second cadence (HWiNFO, Afterburner / RTSS,
  AIDA64, Armoury Crate, G HUB, iCUE), and stop
  OMEN.CommandCenter.Service / OMEN.AI if HP Omen Gaming Hub is
  installed.

Documentation

• SECURITY.md: new "Windows Defender false positives" section
  with the cleared Microsoft submission ID, the analyst quote, the
  VirusTotal cross-reference, the local cache-flush procedure, and
  the new "How to verify your downloaded binary" section.
• INSTRUCTION.md: outdated WinRing0.sys references replaced
  with PawnIO-current guidance; added Defender cache-flush block
  and per-release hash verification instructions.
• README.md: "Microsoft Defender — Cleared" and "VirusTotal
  0 / 76" badges in the header row.
• docs/RELEASING.md: updated to document the new CI-side
  SHA-256 automation.

Compatibility & upgrade notes

• Drop-in replacement for v1.4.0-reborn. No config-file changes.
• Still PawnIO via Resources/LpcACPIEC.bin — no driver bundle
  changes.
• Windows 10/11 x64, .NET Framework 4.8.

Closes

#42, #50, #56, #57, #58, #59, #61, #62

---

Full changelog: see CHANGELOG.md.

OmenMon v1.4.0: Goodbye WinRing0, hello PawnIO

The Defender prompt is gone. OmenMon-Reborn no longer ships the WinRing0 kernel driver. The kernel-mode access layer has been replaced with PawnIO, whose Microsoft-signed, HVCI-compatible driver does not trigger Windows Defender.

This is the biggest release since the fork started, with three coordinated goals: kill the AV false positive permanently, fix every regression and user-reported bug from the first week of field testing, and ship a diagnostic toolkit so future bug reports take minutes to triage instead of hours.

⚠️ One-time setup step before upgrading

OmenMon no longer installs its own kernel driver. You need to install PawnIO once:

1. Download and install PawnIO from https://pawnio.eu/ (signed MSI, no Defender warning, ~10 MB).
2. Drop the new OmenMon.exe over your existing copy.
3. Run as Administrator.

That's it — you won't be asked to allow a kernel driver any more, and Windows Defender won't flag the install. Your existing OmenMon.xml, OmenMon-AutoCal.xml, and fan-program XMLs are fully forward-compatible.

---

✨ What's New & Major Highlights

🔐 PawnIO Migration — Defender flagging is permanently fixed (#1)

WinRing0.sys had a public CVE in older versions and a generic ring-0 surface that triggered Defender heuristics on every install. PawnIO instead ships a single Microsoft-signed driver shared across applications; modules are sandboxed Pawn bytecode that the driver verifies against the maintainer's RSA-2048 key before loading.

• Result: Install PawnIO once and the Defender prompt is gone forever. HVCI / Memory Integrity compatibility comes for free.

🧪 New Diagnostic Toolkit (Telemetry-Free)

Three coordinated additions to make bug reports vastly easier to triage. Nothing is ever uploaded. No network code anywhere; files sit on disk until you choose to attach them to a GitHub issue.

• Crash Dumper: Hooks into fatal exceptions at the earliest possible point. Any fatal crash writes an OmenMon-crash-yyyy-mm-dd-HHmmss.log next to the executable containing the full exception chain and diagnostic bundle.
• OmenMon.exe -Diag: Produces a Markdown bundle with OmenMon version, OS version, PawnIO driver status, resolved model preset, AutoCal sidecar contents, and an EC read/write trace covering the last few minutes.
• "Copy Diagnostic Info" (Tray Menu): One-click clipboard copy of the diagnostic bundle for easy pasting into GitHub issues.

📋 New Native Model Entries

ProductId	Device	Issue
8C30	HP Victus 15-fb1000 (2023, AMD) — Includes the firmware-freeze-at-100% guard	#32
8D26	HP Omen 16-ap0007ns (2026)	#52
88EB	HP Victus 16 (2021) — Earliest Victus 16 generation	#48

---

🔧 Bug Fixes & Improvements

Fan Control & Calibration

• Fan calibration now actually reaches max speed (#40, #41, #52): The Auto-Calibration Wizard's "100% step" was systematically under-driving fans by ~30% on multiple boards because manual mode pins fans at a configured rate ceiling. The wizard now explicitly disengages manual mode immediately before the 100% step to reach true max RPM.
• Fan programs no longer leave the GPU fan stuck off (#39): On some boards (notably 8D07), a prior SetOff(true) stayed latched in the EC. Hardware/FanProgram.SetFanLevel now correctly clears the fan-off latch before each level write, ensuring custom curves reach both fans reliably.
• HP Omen 8DD0 no longer reports "50000 RPM" (#33): The heuristic occasionally misfired on this board. Added a built-in AutoCal.Prime mapping for 8DD0 pointing at the canonical 0xB0/0xB2 LE16 tachometers.
• Stale sidecars from v1.3.x no longer override built-in mappings: AutoCal.Load now discards any sidecar whose offset/mode disagrees with the curated KnownBoards table. Users upgrading from v1.3.x automatically get the correct mapping on first launch.
• Tray "Max fan" toggle fix: Stayed silently off when the fan-off latch was set. It now clears SetOff(false) before SetMax(true).
• GUI "Constant speed" fix: Restored the post-write mode-refresh when a user cancels the 100% safety dialog and falls back to safe levels.

App Stability & UI

• Transcend 14 "BIOS call failed: 4" crash on launch fixed: Benign BIOS return codes (1, 4, 6, and 46) indicating "command not supported on this platform" previously escalated to fatal BiosExceptions. They are now silently ignored, allowing the GUI to open normally on newer hardware.
• Omen key toggles the main window again (#21): Pressing the Omen key while OmenMon is running fires an IPC message that flips the main window's visibility, restoring the original upstream behavior.
• Build Error Fixed: Removed a leftover call to a non-existent UpdateFanMode() that prevented compiling on clean checkouts.

---

🧹 Under the Hood (Developer Notes)

• EC Read/Write Ring Buffer: Records the last 1024 EC operations (timestamp, register, value, op kind) into a lock-free circular buffer. Surfaces through both the crash log and -Diag to help diagnose intermittent issues (like random fan spikes).
• Automated CI Testing (#36): CI now runs dotnet test against a new xUnit suite that enumerates every <Model> entry in OmenMon.xml and validates required registers, byte ranges, and semantics.
• Driver Layer Rewrite: Driver/Ring0.cs was rewritten to delegate to PawnIO while keeping its full public API byte-compatible with v1.3.x. Hardware/Ec.cs and every other caller compile and run unchanged.
• New Documentation: * docs/DEV_NOTES_v1.4.0.md covers the architecture of the PawnIO migration.
  • Resources/PAWN_BUILD.md details operational docs for the embedded PawnIO module.

---

🙏 Thanks to the contributors

Bug reports and field-test data from:
@ShaqibK (#1), @eyzinox (#28), @NotDarkn (#32), @DreamStare0 (#33), @Byteme-dot (#37), @ghend-oss (#39, #40), @MartinSalg818 (#41), @deadpoolstark (#48), @ethernetme (#52), and the Transcend 14 user on Discord.

A separate thanks to namazso — author of PawnIO and the signed LpcACPIEC module that makes the whole migration possible.

---

Security Verification (SHA256):
9AA57EDF4138318BD48F835893D6F895C8C762A41E5776256EADD60DC63A773D

OmenMon v1.3.4: RPM Glitch & Auto-Cal Sanity Checks

This hotfix addresses a rare hardware-read anomaly that caused impossibly high RPM readings and introduces a smart new safeguard to the Auto-Calibration engine.

🛠️ Fixed & Improved

• The "50,000 RPM" Ghost Fan Fix (#26): Fixed an edge-case where a transient 1-byte shift during an Embedded Controller (EC) read caused the Auto-Calibration Wizard to lock onto random memory noise, resulting in wildly inaccurate fan speeds (e.g., 50k+ RPM).
• HP Omen (8DD0) Native Support: Added the 8DD0 (2024/2025) motherboard directly to the native database using the standard 0xB0/0xB2 RPM layout. Owners of this model get flawless fan readings out of the box without needing to run the calibration wizard.

⚙️ Under the Hood (Core Engine Upgrades)

• Auto-Calibration Sanity Checks: The core engine (AutoCal.Load) now performs a mathematical sanity check on generated sidecar files. Across all known HP boards, the CPU and GPU tachometers sit within a few bytes of each other. If OmenMon detects that a saved sidecar has offsets that are unnaturally far apart (>16 bytes) and a native profile already exists for the board, it treats the sidecar as a read-glitch misfire. It will automatically delete the corrupt OmenMon-AutoCal.xml file and safely fall back to the native database, preventing bogus RPM offsets from getting pinned.
• Architecture Cleanup: Safe-guarded the WMI-failure edge cases to ensure valid sidecars are never accidentally deleted if the WMI lookup glitches during startup.

Huge thanks to @DreamStare0 for providing the exact "before and after" hardware probes needed to spot the byte-shift!

What's Changed

• add board 8DD0 to database by @seakyy in #27

Full Changelog: v1.3.3-reborn...v1.3.4-reborn

OmenMon v1.3.3: Sensor Overrides & Hardware Validation

This release brings a massive architectural upgrade to the core engine, allowing OmenMon to dynamically remap hardware locks and temperature sensors for modern (2023+) HP motherboards that deviate from standard layouts.

⚠️ Mixed-confidence release: The 8C9C fix is hardware-validated (cross-referenced against live HWInfo data). The 8BBE and 8D07 fixes are derived from EC-dump analysis only — no live confirmation yet — and are marked ⚠️ in the wiki accordingly. Issue authors are asked to update and confirm.

🛠️ Fixed & Improved

• HP Victus 16-1034NF (8C9C) — CPU/GPU temperatures fixed (#16): Hardware-validated fix! Discovered that this board hides the real, raw die temperatures at non-standard registers (0xB0 for CPU, 0xB4 for GPU Hotspot). The legacy WMI sensor only reports a heavily-smoothed package average that lags 10°C+ behind reality. The 8C9C profile now natively maps directly to the raw die sensors for instant, accurate readouts. (Note: RPM display via EC[0xF1] × 60 is best-effort; it mirrors the commanded rate, not a real tachometer, and may lag the physical fan during BIOS thermal ramps).
• HP Victus 16 R0053NT (8BBE) — Manual fan control unlocked (#19): Deep analysis of hardware probes revealed that this specific BIOS completely ignores the legacy OMCC control bit at 0x62. Instead, manual control is strictly gated by writing 0x08 to register EC[0x06] (idling at 0x48). The 8BBE database entry now natively uses this exact lock/unlock pair.
• HP Victus 15 AMD (8D07) — Corrected register layout (#23): Corrected a bug where the v1.3.2 profile assumed this 2024 laptop used the 2023+ register layout. Re-reading the EC dumps revealed it actually uses the classic 2022 layout (FanLevel at 0x34/0x35, RateWrite at 0x2C/0x2D). The board has been completely remapped and the display name updated to accurately reflect the AMD Ryzen 5 7535HS + RX 6550M SKU.

⚙️ Under the Hood (Core Engine Upgrades)

• Per-Model Temperature Overrides: The <Model> XML schema now supports TempCpuReg and TempGpuReg. This allows OmenMon to instantly remap the legacy CPUT and GPTM sensors to new memory addresses without breaking existing GUI bindings or thermal-panic logic.
• Per-Model Manual-Trigger Overrides: The schema now supports ManualValueOn and ManualValueOff. Boards that use non-standard lock values can declare them explicitly.
• Architecture Cleanup: Refactored Platform.cs to hoist the preset lookups into a cached field, eliminating duplicate dictionary lookups during initialization. Fixed variable scoping in the InitTemperature switch block to ensure clean future extensibility.

If optional fields are omitted in the XML, the engine safely falls back to the legacy defaults (0x06/0x00 and 0x57/0xB7), ensuring all existing supported laptops continue to work flawlessly without config changes.

Huge shoutout to @eyzinox, @yunusemreyl, and @ghend-oss for continuing to provide the raw memory dumps needed to reverse-engineer these undocumented HP BIOS quirks!

What's Changed

• fix 8BBE false configuration by @seakyy in #25

Full Changelog: v1.3.2-reborn...v1.3.3-reborn

v1.3.2: The Omen Key Toggle & 2026 Hardware Update

This update brings back a highly requested quality-of-life feature from the original OmenMon and expands our native database with the newest 2026 HP Omen models, completely verified by our new Auto-Calibration Wizard!

⌨️ Features & Enhancements

• The Omen Key GUI Toggle is back! (#21): Pressing the dedicated Omen Key on your keyboard will now smoothly show and hide the OmenMon Reborn window.
  • Under the hood: We implemented a secure Inter-Process Communication (IPC) ToggleGui message. This restores the classic toggle behavior while strictly maintaining our single-instance lock to protect your hardware registers from crashing.
  • If you have set up a custom action for the Omen Key (like cycling color presets or fan programs), your custom action will still take priority and execute perfectly!

💻 Native Hardware Support

A massive win for the new Auto-Calibration Wizard! The wizard flawlessly detected the register layouts for the latest 2026 generation. We have added them directly to the native database, meaning future users get 100% accurate fan controls and RPM readouts out-of-the box:

• Added HP Omen 16-am1000 (2026, Board 8E71) - Classic 16-bit LE RPM sensors natively mapped. (#22)
• Added HP Omen 16 (2026, Board 8D07) - Classic 16-bit LE RPM sensors natively mapped. (#23)

❤️ Community Shoutouts

Huge thanks to @DreamStare0 for reporting the Omen Key issue, and to @Barcik82 and @ghend-oss for providing the perfect calibration dumps to expand our 2026 hardware support!

What's Changed

• add 8D07 & 8E71 support & fix omenkey by @seakyy in #24

Full Changelog: v1.3.1-reborn...v1.3.2-reborn