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.