moooyo
90d · built 2026-07-24
90-day totals
- Commits
- 25
- Grow
- 17.5
- Maintenance
- 4.8
- Fixes
- 0.9
- Total ETV
- 23.3
Where this dev ranks
Percentile against the global top-100 leaderboard (all-time totals).
- By commits
- Top 100 %
- By Growth share
- Top 11 %
30-day trajectory
Last 30 days vs. the 30 days before. Up arrows on Growth and ETV mean improvement; up arrow on Fixes share means more time on fixes (worse).
↓-16.7 %
vs 6 prior
↑+87.1 pp
recent vs prior
↓-29.9 pp
recent vs prior
Daily performance
Daily ETV, stacked by Growth, Maintenance and Fixes.
Work-mix over time
Share of Growth / Maintenance / Fixes over a rolling 7-day window. Reads as 'where is effort flowing right now'.
Repository spread
Where this developer's commits land. Concentrated work (top1 > 80%) vs polymath spread (top1 < 30%).
Most impactful commits
Top 20 by ETV in the 90-day window.
- 11.5ETVfeat(powerdisplay): add CLI for monitor control (#48632) ## Summary of the Pull Request Adds `PowerToys.PowerDisplay.Cli.exe`, a scriptable interface for controlling monitors through the running PowerDisplay process. It supports `list`, `get`, `set`, `up`, `down`, `capabilities`, `profiles`, and `apply-profile`. The CLI communicates over an authenticated, per-session named pipe; PowerDisplay remains responsible for DDC/CI and WMI access. ## PR Checklist - [x] Closes: #48713 - [x] **Communication:** Discussed with core contributors - [x] **Tests:** Added/updated and all pass - [x] **Localization:** Core errors are localizable; some help and output text remains English-only - [ ] **Dev docs:** N/A; built-in CLI help is the command reference - [x] **New binaries:** Added on the required places - [x] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) - [x] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetupVNext/Resources.wxs) - [x] **YML for CI pipeline:** N/A; test assemblies are auto-discovered - [x] **YML for signed pipeline:** N/A; signing is driven by `ESRPSigning_core.json` - [ ] **Documentation updated:** N/A ## Detailed Description of the Pull Request / Additional comments - Adds an AOT-compatible CLI and shared request/response contracts. - Uses a secured named-pipe server in PowerDisplay, with stable exit codes and a bounded request timeout. - Supports saved profiles by their existing stable profile IDs. - Adds solution, signing, installer, and unit-test project integration. ## Validation Steps Performed - PowerDisplay Lib, Contracts, CLI, and IPC unit-test suites pass. - Native AOT publish completes without analyzer warnings. - Manually validated the CLI on two DDC/CI monitors, including the PowerDisplay-unavailable path. - Rebuilt the PowerDisplay GUI after the shared-library changes. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>github.com-microsoft-PowerToys · 5c9c93d5 · 2026-07-16
- 2.8ETV[PowerDisplay] Add stable profile IDs (#49175) ## Summary of the Pull Request Gives every saved PowerDisplay profile a stable, auto-incrementing integer ID and makes the app address profiles by that ID instead of by name. Duplicate profile names are allowed, renames preserve identity, and LightSwitch stores stable profile references. > Split out of the PowerDisplay CLI branch (#48632). CLI-specific contracts and commands remain in that stacked PR. ## PR Checklist - [x] **Closes:** N/A - split from #48632. - [x] **Communication:** Discussed with core contributors. - [x] **Tests:** Added and passing in `PowerDisplay.Lib.UnitTests`. - [x] **Localization:** The composed profile label uses a shared localized format resource. - [x] **New binaries:** None. - [x] **Documentation updated:** `doc/devdocs/modules/powerdisplay/design.md`. ## Implementation ### Profile model and persistence - `PowerDisplayProfile.Id` is the stable JSON `id`; `0` means unassigned. - `PowerDisplayProfiles.NextId` is monotonic and IDs are never reused. - `SetProfile` assigns IDs to new profiles and replaces existing profiles by ID. - Duplicate names are supported; name lookup remains only for migration of legacy references. - `ProfileStore` serializes cross-process load/modify/save operations with a named mutex and atomically replaces `profiles.json`. - Production callers use asynchronous `ProfileHelper` APIs. ### Migration and application - Initial PowerDisplay discovery assigns missing profile IDs and migrates legacy monitor IDs. - LightSwitch legacy name references are reconciled to IDs and written back to the current typed settings schema. - Native LightSwitch publishes pure light/dark theme events; PowerDisplay exclusively validates profile enablement and stable IDs. - Settings UI and Named Pipe ApplyProfile actions send invariant positive profile IDs. - PowerDisplay validates the ID, loads the current profile, and applies its monitor settings. ### Settings UI - Create, edit, apply, and delete operations use stable IDs. - LightSwitch selectors store profile IDs and keep legacy name fields only for migration. - Profile lists use a localized name-and-ID label so duplicate names remain distinguishable. ## Accepted Trade-offs - Profile ID migration remains dependent on the initial monitor discovery; a failed or delayed discovery can temporarily hide legacy ID-less profiles. - The one-time PowerDisplay LightSwitch migration rewrites the complete current typed settings object and does not add a new cross-process settings transaction. ## Validation - Built the affected x64 Debug projects with the repository build scripts. - `PowerDisplay.Lib.UnitTests`: 186 passed, 0 failed. --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>github.com-microsoft-PowerToys · 2b8e6247 · 2026-07-16
- 1.2ETV[PowerDisplay] Pre-classify internal/external displays at discovery (#47740) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Adds an explicit Phase 0 classification step in `MonitorManager` that uses `DISPLAYCONFIG_VIDEO_OUTPUT_TECHNOLOGY` (from `QueryDisplayConfig`) to label every connected display as **internal** (built-in) or **external** before any controller runs. Each controller is then dispatched a strictly-scoped target list: - **WMI controller** → only internal displays - **DDC/CI controller** → only external displays Two practical wins: 1. **Performance** — DDC/CI's ~4-second I2C capabilities probe (per monitor) is now skipped entirely for internal laptop panels, which never respond to DDC/CI in the first place. On a typical laptop with one built-in panel + one external monitor, discovery is noticeably faster. 2. **Layering** — `WmiController` no longer reaches into the `Drivers/DDC/` namespace to call `DdcCiNative.GetAllMonitorDisplayInfo()`. Both controllers receive their input from `MonitorManager` via a single `QueryDisplayConfig` call. Strict classification is enforced: a display classified as internal but not returned by `WmiMonitorBrightness` is dropped + logged (Warning), with **no fallback to DDC/CI**. This is a deliberate design choice — the spec discusses the trade-off in detail. Adds a Phase 0 classification log (Info level) so misclassifications are diagnosable from logs alone: ``` [DisplayClassification] Found 2 displays: [Path 1] \\.\DISPLAY1 / "Built-in display": OutputTechnology=0x80000000 → Internal [Path 2] \\.\DISPLAY2 / "Dell U2723QE": OutputTechnology=10 → External [DisplayClassification] Summary: 1 internal, 1 external ``` The classification rule (in `DisplayClassifier.IsInternal`) is deliberately conservative — misclassifying an external display as internal would silently drop it from DDC/CI discovery with no fallback, so we err on the side of external: - **Internal**: the bare `INTERNAL` flag (`0x80000000`) alone, the `INTERNAL` flag combined with a documented embedded subtype (`DISPLAYPORT_EMBEDDED` 11 or `UDI_EMBEDDED` 13), or one of those embedded subtypes on its own - **External**: everything else, including the `INTERNAL` flag combined with an undocumented subtype (HDMI, DP_EXTERNAL, MIRACAST, etc.) - LVDS (6) is intentionally **not** classified internal — the [Microsoft docs](https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ne-wingdi-displayconfig_video_output_technology) describe it only as a connector type, not as an internal-display marker <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>github.com-microsoft-PowerToys · 3796b244 · 2026-05-12
- 1.0ETV[PowerDisplay] Auto-disable on detected DDC/CI capability fetch crash (#47556) (#47734) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary Mitigation for issue #47556 — `KERNEL_SECURITY_CHECK_FAILURE` BSOD originating in `win32kfull!DdcciGetCapabilitiesStringFromMonitor` when PowerDisplay calls DDC/CI capability APIs against monitors with malformed capability strings. After a detected crash, PowerDisplay auto-disables itself via `settings.json`, shows an error InfoBar at the top of the PowerDisplay settings page (page is locked except the Ignore button), so users can avoid getting stuck in an infinite reboot loop after a crash. And the user must explicitly dismiss the warning before re-enabling the module. The actual kernel-side fix is the Windows team's responsibility — this PR only prevents users from BSOD-ing repeatedly on the same monitor without warning. settings page: <img width="1743" height="1475" alt="image" src="https://github.com/user-attachments/assets/8cf1b72f-c51a-4955-82d7-213cae49fd4e" /> ## Mechanism 1. `CrashDetectionScope` IDisposable wraps Phase 2 capability fetch in `DdcCiController.DiscoverMonitorsAsync`, writing `discovery.lock` (`WriteThrough` + `Flush(flushToDisk: true)`) before, deleting it on Dispose. 2. If the process is killed externally (BSOD, FailFast), the lock survives. 3. On next PowerDisplay.exe startup (Phase 0), `CrashRecovery` detects the orphan lock and runs a strict fail-fast sequence: write `crash_detected.flag` → set `enabled.PowerDisplay=false` in global `settings.json` → signal the new `POWER_DISPLAY_AUTO_DISABLE_EVENT` → delete the lock (commit point). 4. The runner-loaded `PowerDisplayModuleInterface.dll` runs a one-shot listener thread that wakes on the event and calls `disable()` to sync `m_enabled`. 5. `PowerDisplayViewModel` reads the flag at construction and binds `IsCrashLockActive` to lock the page. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #47556 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · 8e74eb2b · 2026-05-20
- 0.9ETV[PowerDisplay] Detect built-in panel when driven by the discrete GPU (#48637) ## Summary of the Pull Request On dual-GPU laptops, Power Display stopped detecting the built-in panel (and adjusting its brightness) when the **discrete GPU** drives the display — it showed "can't detect the display". This fixes that by classifying displays by **capability** (does WMI brightness work on it?) instead of by the nominal `OutputTechnology` value, which the discrete GPU misreports for the internal panel. ## PR Checklist - [x] Closes: #48587 - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized (no new user-facing strings added) - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places ## Detailed Description of the Pull Request / Additional comments ### Root cause On a hybrid / MUX laptop, when the **discrete GPU** drives the built-in eDP panel, `QueryDisplayConfig` reports the panel's `DISPLAYCONFIG_VIDEO_OUTPUT_TECHNOLOGY` as `DISPLAYPORT_EXTERNAL` (`10`) instead of the `INTERNAL` flag (`0x80000000`) it reports under the integrated GPU. It is the *same physical panel* (same EDID) — only the reported connector type changes with the active GPU. PR #47740 introduced a strict classifier: `OutputTechnology` → internal/external, then **internal → WMI-only, external → DDC/CI-only, with no fallback**. So under the discrete GPU the built-in panel was classified *external* and sent to DDC/CI only — but a laptop eDP panel does not speak DDC/CI, so it was dropped and Power Display reported it couldn't detect any monitor. (`WmiMonitorBrightness` still exposes that panel regardless of which GPU drives it, so the panel was actually controllable — it just never got routed to WMI.) ### Fix: classify by capability, not by nominal output technology - **`MonitorManager`** now runs **WMI discovery first** over the full `QueryDisplayConfig` inventory. Every display `WmiMonitorBrightness` exposes is treated as internal (WMI-controlled); whatever WMI does **not** claim is routed to DDC/CI. The `OutputTechnology`-based classifier is gone. - **`WmiController`** matches the system-wide `WmiMonitorBrightness` results against the full inventory by `Monitor.Id`. The persisted `Monitor.Id` is still taken from the matched `DevicePath` (byte-identical to the DDC route and to prior releases), so saved brightness/per-monitor settings survive upgrades. - New **`MonitorIdentity.FromInstanceName`** reduces a WMI `InstanceName` to the same canonical `Monitor.Id` as `FromDevicePath`; the separate `PnpHardwareKey` helper is removed. - **Deleted** `DisplayClassifier` and `MonitorDisplayInfo.IsInternal` (net ~150 fewer lines). ### Accepted trade-off A monitor that exposes **both** `WmiMonitorBrightness` **and** DDC/CI is now controlled via WMI only and won't get DDC-only features (contrast / volume / input source / color temperature / power). This is uncommon (typical laptop panels are WMI-only; typical external monitors are DDC-only) and is a deliberate decision: it removes the entire class of `OutputTechnology` misclassification bugs while keeping the performance win of not DDC-probing internal panels. ## Validation Steps Performed - Built the Power Display app (`PowerDisplay.csproj`) and `PowerDisplay.Lib.UnitTests` (x64 / Debug) with MSBuild — both succeed, including after merging latest `main` (Windows App SDK 2.2.0). - Ran the unit test suite: **128/128 pass**, including new `FromInstanceName` tests — the `FromInstanceName == FromDevicePath` equivalence invariant and a concrete #48587 regression case (the BOE panel reported as `OutputTechnology=10`). - Traced the fix against the reporter's diagnostic logs: the panel that previously went `OutputTechnology=10 → External → DDC → dropped` is now claimed by WMI and controllable. - Reviewed the diff for regressions (Monitor.Id persistence, monitor blacklist, mirror mode, dual-internal-panel devices, external-only desktops). --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · 32ad98a0 · 2026-06-22
- 0.9ETV[Quick Accent] Migrate UI to WinUI 3 (#48891) ## Summary of the Pull Request Migrates the **Quick Accent (PowerAccent)** module's UI from WPF (`System.Windows.*`) to **WinUI 3 (Windows App SDK)**, following the pattern used by other migrated modules (ImageResizer, PowerDisplay). The accent selector is now a self-contained WinUI 3 app (`PowerToys.PowerAccent.exe`) shipped under `WinUI3Apps`, and `PowerAccent.Core` is UI-framework-agnostic. demo: https://github.com/user-attachments/assets/400c33ee-0fc0-491e-841b-a546438edf91 ## PR Checklist - [x] Closes: #48889 - [x] **Communication:** Tracked task (#48889) agreed with core contributors - [x] **Tests:** Added/updated and all pass — new `PowerAccent.Core.UnitTests` (21 tests for the positioning / DPI math); existing `PowerAccent.Common.UnitTests` unaffected - [x] **Localization:** No new localizable end-user strings — new accessibility metadata uses non-localized `AutomationProperties.AutomationId`, and the window title is the brand name `"Quick Accent"` (literal, matching ColorPicker) - [x] **Dev docs:** Updated `doc/devdocs/modules/quickaccent.md` - [x] **New binaries:** Added on the required places - [x] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json): the `WinUI3Apps\` PowerAccent payloads are listed in `ESRPSigning_core.json` - [x] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs): no manual `Product.wxs` entry — the self-contained `WinUI3Apps` output (exe + `.pri` + Windows App SDK runtime) is harvested by the `WinUI3ApplicationsFiles` glob (same as ImageResizer) - [x] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml): no change needed — `PowerAccent.Core.UnitTests` is discovered by the existing `**\*UnitTest*.dll` VSTest glob - [x] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml): covered by `ESRPSigning_core.json`; no `release.yml` change needed - [ ] **Documentation updated:** N/A — internal UI-framework migration with no user-facing behavior change ## Detailed Description of the Pull Request / Additional comments The migration spans three areas (tracked in #48889): **UI (WPF → WinUI 3)** - `PowerAccent.UI` is now a WinUI 3 app shell (custom `Program.Main`, `WindowsPackageType=None`, `WindowsAppSDKSelfContained=true`). - The accent selector is a non-activating `TransparentWindow` overlay shown with `SW_SHOWNA` (never steals focus). It is made always-on-top only while shown — the WinUIEx `WindowEx.IsAlwaysOnTop` property is toggled `true` on show / `false` on hide in `OnChangeDisplay` (matching the WPF original's `Topmost = isActive`), so the dormant, never-destroyed overlay does not pin a discrete GPU awake on hybrid-graphics laptops (issue #34849 / PR #41044). - The accent "pill" selection visual is reproduced with `VisualStateManager` (WinUI 3 has no `Style.Triggers`). - **WinUI 3 gotcha:** x:Bind on a Window-rooted XAML initializes only on `Window.Activated`, which never fires for this `SW_SHOWNA` overlay — so the selector calls `Bindings.Update()` after `InitializeComponent()`; without it the `ListView` renders empty. - **Theme:** the long-lived, never-activated process follows the system app theme automatically — `App.xaml` leaves `Application.RequestedTheme` unset, so WinUI re-resolves the `{ThemeResource}` brushes (and retints the acrylic) on a live light/dark switch with no manual `ThemeListener` needed. - **Layout parity with the WPF original:** the bar width hugs its content (`itemCount × 48`, clamped to the monitor width — computed, not measured, to avoid a racy `ListView` measure), and each cell pins `MinWidth=48` (WinUI's `ListViewItem` defaults to 88, which would otherwise leave wide gaps). - **Accessibility:** UIA window name + `AutomationId`s on the character list and description. **Dependency** - `PowerAccent.Core` no longer depends on WPF — it raises events and takes an injected UI-thread marshaller. - WinForms `SendKeys` → `SendInput` (CsWin32 P/Invoke); WPF-UI (Lepo) removed; language data moved to the UI-/WinRT-agnostic `PowerAccent.Common`. - MVVM via CommunityToolkit.Mvvm with `[ObservableProperty]` **partial properties** (WinRT-correct, clears MVVMTK0045). **CI / Build / Installer** - Signing config, WinUI3Apps glob harvest, and the new unit-test project — see the checklist above. ## Validation Steps Performed - **Build:** `x64 Debug` builds with **0 warnings / 0 errors**. - **Unit tests:** `PowerAccent.Core.UnitTests` — **21/21 pass** (9 anchor positions × DPI 1.0/1.5/2.0, the offset and negative-origin monitors, caret centering + edge clamping + flip-below). - **XamlStyler:** `PowerAccentXAML/MainWindow.xaml` passes the passive format check (CI mode). - **Manual (single monitor, Top-center, light theme):** - Accent popup appears with the full accent list rendered. - Bar hugs the characters and is centered; cell spacing matches the WPF original. - Switching the system theme (light/dark) is followed live by the popup. - With `show_description` enabled, the description row is wide (≥600px) and readable, with the accent bar centered above it. - **Remaining manual validation** (tracked in #48889): multi-monitor, per-monitor DPI, all 9 `toolbar_position` values, and high-contrast theme. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>github.com-microsoft-PowerToys · 9039451e · 2026-07-03
- 0.8ETVfeat(PowerDisplay): migrate legacy "{Source}_{EdidId}_{N}" Ids to new stable ID (#47977) Carry per-monitor user preferences from the pre-#47712 Id format onto the current DevicePath-based Ids by matching on EdidId. Without this, every upgrade silently resets Enable* toggles (input source, color temperature, power state) for monitors users had already opted in on, because the direct-Id lookup in ApplyPreservedUserSettings can never match the old "DDC_DELD1A8_1" / "WMI_BOE0900_2" keys. <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · f117bfc6 · 2026-05-21
- 0.8ETV[PowerDisplay] Add max compatibility mode setting (#47875) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request 1. Adds an opt-in Max compatibility mode in PowerDisplay's Advanced settings. When enabled, DDC discovery probes monitors that don't advertise capabilities, picking up displays that would otherwise be skipped. 2. Toggling the setting triggers an immediate rescan via a new RescanPowerDisplayMonitorsEvent IPC event from Settings to PowerDisplay. 3. Hides the brightness slider on monitors that lack VCP 0x10. Also fixed animation issue #47868 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #47878 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>github.com-microsoft-PowerToys · c5d17913 · 2026-05-14
- 0.6ETV[PowerDisplay] Fix brightness/contrast/volume on monitors with native max != 100 (#47679) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Fixes #47458 — on monitors that advertise a non-100 raw VCP maximum (e.g. Samsung S27DG602SN reports 50), the DDC controller was writing the slider's 0–100 percentage directly as the raw VCP value. Anything above the device's max was silently clamped, so only the bottom half of the brightness / contrast / volume sliders had any visible effect. The same root cause affects all three continuous-range VCPs (0x10 brightness, 0x12 contrast, 0x62 volume). - Capture the device-reported `max` at discovery into new `Monitor.{Brightness,Contrast,Volume}VcpMax` fields. - Add `VcpFeatureValue.FromPercentage(percent, max, min)` as the symmetric inverse of the existing `ToPercentage()`. - Scale percent → raw inside `DdcCiController.Set{Brightness,Contrast, Volume}Async` before each `SetVCPFeature` call. - WMI is unaffected — Windows already standardises WMI brightness to 0–100. The whole stack above the controller (ViewModel, MonitorManager, slider, settings persistence, IPC) stays in the percent domain. The only place percent ↔ raw conversion happens is the controller boundary. #47458 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: # <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · 3d96d525 · 2026-05-08
- 0.6ETV[PowerDisplay] Stable monitor Id + survive transient discovery failures (#47712) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Fixes #47665 — users report the per-monitor "Show input source control" / "Show power state control" toggles silently revert to off over time. Three independent log captures pin the root cause to two layers in `MainViewModel`: - **Data-loss layer**: `SaveMonitorsToSettings` rebuilds `settings.Properties.Monitors` from the currently-discovered list and only re-adds entries with `IsHidden=true`. Whenever monitor discovery transiently fails (DDC `GetPhysicalMonitors` NULL handle, DDC `empty capabilities string`, WMI 4200 — all common in production logs), affected monitors get **deleted** from settings.json. Next successful discovery initialises them with the post-#47303 defaults (`EnableInputSource=false`, `EnableColorTemperature=false`, `EnablePowerState=false`), and `ApplyPreservedUserSettings` cannot recover what is no longer there. - **Identity layer**: `Monitor.Id` is `{Source}_{EdidId}_{MonitorNumber}` — `EdidId` is not unique for identical-model monitors, and `MonitorNumber` is OS-assigned and changes after sleep/wake / GPU reset / display reorder. Even fixing the data-loss layer would still apply preserved settings to the wrong physical monitor for users with multiple identical displays. This PR addresses both layers: - **30-day retention** — `MonitorSettingsRebuilder` (in `PowerDisplay.Lib`) replaces the inline `IsHidden`-only loop. Currently-discovered monitors get a fresh `LastSeenUtc` stamp; missing-but-recent (< 30 days) entries are preserved with all `Enable*` flags intact; missing-and-stale entries are dropped with a single info log. `IsHidden=true` entries are still preserved unconditionally. - **DevicePath-based Id** — `Monitor.Id` is now the Windows `DevicePath` minus the trailing device-class GUID (e.g. `\\?\DISPLAY#DELD1A8#5&abc&0&UID12345`). The middle PnP-instance segment is unique per (physical device × physical port) and stable across reboots, sleep/wake, and OS-level reordering — `MonitorDisplayInfo.DevicePath` already carries this value from `QueryDisplayConfig`; it just wasn't being used as the Id. The order of commits keeps the app behaviourally identical to today through the first 8 commits (only adds dormant helpers / fields / wiring); the actual ID-format flip is the very last commit. Bisect-friendly. #47599 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: # <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · 95b70555 · 2026-05-08
- 0.4ETV[Power Display] Built-in monitor blacklist to mitigate DDC/CI BSOD (#47556, #47968) (#48051) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Adds a built-in monitor blacklist that skips known-bad monitor models at the DDC/CI discovery stage — before PowerDisplay sends any capabilities request to the firmware. Matches by EdidId (the PnP manufacturer + product code from EDID). Two entries pre-populated from existing crash reports: | EdidId | Reported in | Notes | |-----------|-------------|------------------------------------------------------------------------| | `LTM2C02` | #47556 | Counterfeit-EDID LG 27MR400 (PnP claims Litemax 40" 2011, actual hw is LG 27" 2024) | | `GSM7714` | #47968 | LG UltraWide HDR WFHD | Also logs `[EdidId=…] [FriendlyName=…] [DevicePath=…]` immediately before each `GetCapabilitiesString*` syscall in `DdcCiController`. If the kernel call BSODs (`win32kfull` stack-cookie overrun), that is the last log line that survives — adding a new blacklist entry then takes one PR to `BuiltInMonitorBlacklist.json` instead of a memory-dump triage. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Mitigates: #47556 - [x] Mitigates: #47968 - [x] **Communication:** This is the "Add blacklist and prevent the API call on broken monitor" mitigation outlined in [#47556 (comment)](https://github.com/microsoft/PowerToys/issues/47556#issuecomment-4505498427). The underlying `win32kfull!DdcciGetCapabilitiesStringFromMonitor` stack overrun is tracked separately by the Windows team. - [x] **Tests:** 6 new MSTest unit tests under `PowerDisplay.Lib.UnitTests`. All 120 PowerDisplay tests pass on x64 Debug. - [ ] **Localization:** N/A — this PR ships no end-user-facing strings (no UI surface). - [ ] **Dev docs:** N/A. - [ ] **New binaries:** N/A. Data ships as an `<EmbeddedResource>` inside the existing `PowerDisplay.Models.dll`; no new .dll, no installer change. - [ ] **Documentation updated:** N/A. <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments ### Threat model Some retail monitor firmwares ship non-conformant DDC/CI capabilities strings — typically oversized, not NUL-terminated, or otherwise malformed. When PowerDisplay calls `GetCapabilitiesStringLength` / `CapabilitiesRequestAndCapabilitiesReply` on these monitors, the request flows into `win32kfull!CPhysicalMonitorHandle::DdcciGetCapabilitiesStringFromMonitor`, which copies the reply into a stack buffer without bounding the length. The kernel detects its own stack cookie corruption on the epilogue check and `__fastfail`s with `BUGCHECK 0x139 / 2 (STACK_COOKIE_CHECK_FAILURE)`. The kernel-side overrun is a Windows defect, not PowerDisplay's, but PowerDisplay is currently the most widely deployed consumer of this API on hot-plug. Until the Windows team fixes the kernel, the only safe mitigation in user space is to **never call** the capabilities API on monitor models known to trigger it. ### Architecture | File | Role | |---|---| | `PowerDisplay.Models/MonitorBlacklistEntry.cs` | POCO: `{ edidId, comments }` | | `PowerDisplay.Models/BuiltInMonitorBlacklist.json` | Data file (embedded resource) | | `PowerDisplay.Models/BuiltInMonitorBlacklist.cs` | Lazy-loaded reader, AOT-safe (source-gen `JsonSerializerContext`); silent fallback to empty list on any IO/parse failure | | `PowerDisplay.Lib/Services/MonitorBlacklistService.cs` | `IsBlocked(monitorId)` — extracts EdidId via `MonitorIdentity.EdidIdFromMonitorId`, checks a `HashSet<string>` with `OrdinalIgnoreCase` | | `PowerDisplay/Helpers/MonitorManager.cs` | Filters QueryDisplayConfig inventory by EdidId **before** any controller (DDC/CI or WMI) is dispatched; logs each skip with `[MonitorBlacklist] Skipping ...` | | `PowerDisplay.Lib/Drivers/DDC/DdcCiController.cs` | Logs EdidId + FriendlyName + DevicePath immediately before the first capabilities syscall per-monitor | Matching is **model-level granularity** (EdidId, e.g. `GSM7714`) rather than device-level (full DevicePath). One entry covers every physical port and every machine with the same monitor model. ### Adding new entries Once the kernel overrun is fixed this list can shrink. Until then, when a new BSOD surfaces: 1. User reports BSOD, attaches PowerDisplay log 2. The last line before the crash now reads `DDC: probing capabilities [EdidId=XXXXXX] [FriendlyName='...'] [DevicePath=...]` 3. Add `{ "edidId": "XXXXXX", "comments": "See #issue" }` to `BuiltInMonitorBlacklist.json` 4. Submit PR, ship in next release ### Scoped out (deliberate) A user-customized blacklist surface (Settings UI dialog) was prototyped and hit multiple WinUI 3 dialog parse / measure crashes inside a `ContentDialog`. The custom-list code path was reverted in favor of "built-in only" for v1 reliability. UI can be re-added later on top of this foundation if needed — the data model and service already support it. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed 1. **Unit tests:** `dotnet test` on `PowerDisplay.Lib.UnitTests` → **120/120 pass** (including 6 new tests for loader + service: built-in JSON loads, EdidIds are normalized to upper-case, no blank entries, `Lazy<>` cache returns same instance, `IsBlocked` returns `false` for empty built-in list and for unidentifiable monitor IDs). 2. **Clean x64 Debug build** via `tools\build\build-essentials.cmd` + per-project `tools\build\build.cmd`: - `PowerDisplay.Models` — 0 warning, 0 error - `PowerDisplay.Lib` — 0 warning, 0 error - `PowerDisplay` (app) — 0 warning, 0 error 3. **Smoke test (manual):** launched PowerDisplay, confirmed every connected monitor produces a `DDC: probing capabilities [EdidId=…] [FriendlyName=…] [DevicePath=…]` log line right before its caps request. 4. **Empty-list case:** `BuiltInMonitorBlacklist.json` with no entries → `IsBlocked` returns `false` for any input (verified via unit test). 5. **Non-empty case (manual):** temporarily added a connected monitor's EdidId to the built-in JSON → that monitor disappears from `MonitorManager.Monitors` and `[MonitorBlacklist] Skipping ...` log line appears; removed the entry → monitor reappears, all per-monitor settings intact. --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>github.com-microsoft-PowerToys · 4edfcee8 · 2026-05-22
- 0.4ETV[PowerDisplay] Fix false-positive crash detection on cooperative shutdown (#48173) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Cooperative shutdowns of `PowerDisplay.exe` — Runner's `TerminateApp` NamedPipe message, the `Terminate` named event, tray-quit, Runner-exit detection, and PowerToys upgrades — all call `Environment.Exit(0)` immediately. If DDC/CI discovery is mid-flight, that path skips the `try/finally` that owns `CrashDetectionScope`, leaving `discovery.lock` on disk. Phase 0 at the next `PowerDisplay.exe` startup then treats this orphan as evidence of a real crash and auto-disables the module, surfacing the "PowerDisplay has crashed" InfoBar in Settings UI. This PR adds an `AppDomain.ProcessExit` safety-net inside `CrashDetectionScope`. ProcessExit fires for `Environment.Exit` but **not** for `FailFast` / BSOD / external `TerminateProcess` — exactly the partition we need: cooperative exit → best-effort delete the lock; involuntary kill → leave the lock for Phase 0 to detect (original design intent preserved). <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #48169 - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized <!-- no user-facing strings changed --> - [x] **Dev docs:** Added/updated <!-- inline XML doc on CrashDetectionScope explains the ProcessExit partition --> - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments ### Root cause `CrashDetectionScope.Begin()` writes `discovery.lock` before DDC/CI capability fetch and `Dispose()` deletes it when the `using` block exits. The lock is intentionally designed to survive any code path that cannot run user-mode cleanup (BSOD, kernel OOM, `TerminateProcess`), so that the next `PowerDisplay.exe` start can see it and run Phase 0 (write `crash_detected.flag`, set `enabled.PowerDisplay=false` in global `settings.json`, signal `AutoDisablePowerDisplayEvent`). The bug is that several **cooperative** shutdown paths route to `Environment.Exit(0)` immediately: | Path | Code | |---|---| | Runner's `TerminateApp` NamedPipe | `App.xaml.cs::OnNamedPipeMessage` → `Shutdown()` → `Environment.Exit(0)` | | `Terminate` named event | `App.xaml.cs::OnLaunched` → `RegisterEvent(..., () => Environment.Exit(0), "Terminate")` | | Tray-quit | `TrayIconService` callback → `Environment.Exit(0)` | | Runner-exit detection | `RunnerHelper.WaitForPowerToysRunner` callback → `Environment.Exit(0)` | `Environment.Exit` calls `ExitProcess` under the hood, which terminates all threads abruptly. Background `Task.WhenAll` doing DDC capability fetch is killed mid-flight; the `finally` block that calls `scope.Dispose()` never runs; `discovery.lock` orphans; Phase 0 next time false-positives. Concrete repro from logs: - `15:08:42.510` lock written - `15:08:42.79` probe monitor #1 - `15:08:46.92` probe monitor #2 (started, not finished — typical probe takes ~5s) - `15:08:49.03` `TerminateApp` received → `Environment.Exit(0)` → no `Dispose` log line - `15:10:10.03` next startup: Phase 0 sees orphan lock with `pid:17712, startedAt:2026-05-28T07:08:42Z` → writes `crash_detected.flag` → auto-disables ### Fix `CrashDetectionScope.Begin()` now also subscribes to `AppDomain.CurrentDomain.ProcessExit`. The handler does a best-effort `File.Delete(_lockPath)` (swallowing exceptions, as required for ProcessExit handlers). `Dispose()` unsubscribes before deleting. An `Interlocked.Exchange` guards the race between Dispose and ProcessExit so only one of the two performs the delete. ProcessExit's semantics match the cooperative/involuntary partition exactly: | Shutdown path | ProcessExit fires? | Behavior after this PR | |---|---|---| | `Environment.Exit(code)` (all 4 paths above) | yes | lock deleted by handler | | `Environment.FailFast` | no | lock survives → Phase 0 catches it (correct: explicit FailFast = real failure) | | BSOD / external `TerminateProcess` / kernel OOM | no | lock survives → Phase 0 catches it (correct: original design) | | Discovery completes normally / throws | n/a | `try/finally` calls `Dispose()` as before; handler unsubscribed first | ### Testability A new `IProcessExitHook` interface abstracts the subscription so unit tests can simulate ProcessExit without terminating the test runner. Production code uses the default `AppDomainProcessExitHook` singleton; tests inject a fake whose `RaiseExit()` invokes subscribed handlers synchronously. ### Files touched - `src/modules/powerdisplay/PowerDisplay.Lib/Services/IProcessExitHook.cs` *(new)* — interface + production singleton - `src/modules/powerdisplay/PowerDisplay.Lib/Services/CrashDetectionScope.cs` — subscribe in `Begin`, unsubscribe in `Dispose`, add `OnProcessExit` handler, expanded class doc - `src/modules/powerdisplay/PowerDisplay.Lib.UnitTests/CrashDetectionScopeTests.cs` *(new)* — 10 unit tests <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed ### Automated 10 new unit tests in `CrashDetectionScopeTests`, all passing: ``` Passed Begin_WritesLockFileAtomically Passed Begin_SubscribesToProcessExit Passed Dispose_UnsubscribesFromProcessExit Passed Dispose_DeletesLockFile Passed ProcessExitFired_BeforeDispose_DeletesLock (core scenario) Passed ProcessExitFired_AfterDispose_DoesNothing Passed Dispose_AfterProcessExit_DoesNotThrow Passed ProcessExitFired_LockFileMissing_DoesNotThrow Passed Dispose_IsIdempotent Passed MultipleScopes_DoNotShareState ``` Full `PowerDisplay.Lib.UnitTests` suite: **129 / 132 passing**. The 3 failures (`DetectOrphanAndDisable_RunsFullSequenceWhenOrphanPresent`, `DetectOrphanAndDisable_HandlesUnknownVersionAsOrphan`, `DetectOrphanAndDisable_LeavesLockIntactOnSignalFailure`) are **pre-existing on `main`** — they fail with `REGDB_E_CLASSNOTREG` from `Constants.AutoDisablePowerDisplayEvent()` (WinRT activation factory not COM-registered in the test environment). Verified by stashing this PR's changes and re-running the same 3 tests on baseline `main` — same failures, same cause, unrelated to this change. ### Manual 1. Reproduced the original false-positive on `main`: - Enable PowerDisplay → open Settings UI → quickly toggle PowerDisplay off - Observe `discovery.lock` left in `%LOCALAPPDATA%\Microsoft\PowerToys\PowerDisplay\` - Re-enable PowerDisplay → Phase 0 writes `crash_detected.flag` → InfoBar appears 2. Repeated the same steps with this branch: - Toggling PowerDisplay off cleanly deletes `discovery.lock` (ProcessExit handler ran) - Re-enabling PowerDisplay shows no InfoBar, no `crash_detected.flag` created 3. BSOD path is unchanged (verified by inspecting the conditional logic — `AppDomain.ProcessExit` does not fire for involuntary terminations; the lock survives just as before). --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · cd5027fa · 2026-05-28
- 0.4ETV[PowerDisplay] Rescan monitors on display wake (#47876) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request 1. Subscribes to GUID_CONSOLE_DISPLAY_STATE so PowerDisplay rescans monitors when the console display wakes from sleep — previously, woken monitors stayed unrecognized until the user manually re-triggered discovery. 2. Locks the PowerDisplay UI immediately on wake to block stale interactions before the rescan completes. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #47951 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · 38882fd3 · 2026-05-18
- 0.3ETV[PowerDisplay] Add configurable mouse wheel increment for slider controls (#49002) ## Summary of the Pull Request Adds a Settings option that controls how much the PowerDisplay flyout sliders (brightness, contrast, volume) change per mouse-wheel notch. The value is chosen from a **preset dropdown** (`1, 2, 5, 10, 15, 20, 25`) and defaults to **5**, preserving today's behavior. Previously the per-notch step was hardcoded as `helpers:SliderExtensions.MouseWheelChange="5"` in four places in the flyout. <img width="1282" height="620" alt="image" src="https://github.com/user-attachments/assets/3b299a47-eb7b-4b53-b3dc-0540fbb25bfc" /> ## PR Checklist - [x] Closes: #48805 - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass — _added `MouseWheelIncrementSettingsTests` to the existing `PowerDisplay.Lib.UnitTests`; passing via `vstest.console.exe`._ - [x] **Localization:** All end-user-facing strings can be localized — _new `PowerDisplay_MouseWheelIncrement.Header`/`.Description` in `en-us/Resources.resw`, surfaced via `x:Uid`._ - [ ] **Dev docs:** Added/updated — _N/A: small settings addition, no behavioral/architecture docs affected._ - [ ] **New binaries:** Added on the required places — _N/A: no new binaries or projects (the unit test was added to an existing test project)._ - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** _N/A._ ## Detailed Description of the Pull Request / Additional comments A single `int MouseWheelIncrement` is added to `PowerDisplayProperties` and persisted to `settings.json` under `mouse_wheel_increment`; it is edited in the Settings UI and read by the flyout app. The value applies uniformly to all four flyout sliders. **Data model** — `src/settings-ui/Settings.UI.Library/PowerDisplayProperties.cs` - `MouseWheelIncrement` (`int`, `[JsonPropertyName("mouse_wheel_increment")]`, default `5` set in the constructor, mirroring `MonitorRefreshDelay`). Old `settings.json` without the key deserializes to `5` (no migration). The whole type is already registered with the source-generated JSON contexts, so the new property serializes on both the Settings and flyout sides with no context change. **Settings UI (write side)** — `src/settings-ui/Settings.UI/...` - `PowerDisplayViewModel`: `MouseWheelIncrement` (get/set via `SetSettingsProperty`, calls `SignalSettingsUpdated()` so an open flyout updates live) and `MouseWheelIncrementOptions` = `{ 1, 2, 5, 10, 15, 20, 25 }`. - `PowerDisplayPage.xaml`: a `ComboBox` `SettingsCard` in the flyout-settings expander, immediately after "Monitor refresh delay", matching that card's markup. - `Strings/en-us/Resources.resw`: `Mouse wheel increment` + description. **Flyout (read side)** — `src/modules/powerdisplay/PowerDisplay/...` - `MainViewModel`: `[ObservableProperty] int MouseWheelIncrement` (default 5), loaded from settings in `LoadUIDisplaySettings()` (runs at startup and on the settings-updated IPC event, so the all-displays slider updates live). - `MonitorViewModel`: a read-only proxy `MouseWheelIncrement => _mainViewModel?.MouseWheelIncrement ?? 5` plus `RefreshMouseWheelIncrement()`, called from `ApplySettingsFromUI`'s per-monitor loop so the per-monitor sliders update live. - `MainWindow.xaml`: the four sliders' `SliderExtensions.MouseWheelChange` now bind to the setting — the all-displays slider to `ViewModel.MouseWheelIncrement`, the three per-monitor sliders (brightness/contrast/volume, inside the `MonitorViewModel` `DataTemplate`) to `MouseWheelIncrement`. ## Validation Steps Performed **Automated** - Unit tests (`PowerDisplay.Lib.UnitTests/MouseWheelIncrementSettingsTests.cs`), run via `vstest.console.exe` — passing: - default value is `5`; - legacy `settings.json` missing the key deserializes to `5` (no migration); - round-trip preserves a non-default value; - serialization emits the `mouse_wheel_increment` snake_case key. - `PowerToys.Settings` and the PowerDisplay flyout app both compile clean (the XAML compiler validates the new `x:Bind` bindings). - Confirmed the property flows through the source-generated JSON contexts (whole-type `[JsonSerializable(typeof(PowerDisplaySettings))]`) on both the Settings and flyout sides. **Pending (manual, on-device — reason this PR is a draft)** - [ ] Settings: the dropdown shows `5` on a fresh profile; changing it writes the new `mouse_wheel_increment` value to `settings.json`. - [ ] Flyout: scrolling each slider (all-displays brightness, per-monitor brightness/contrast/volume) steps by the selected value, including live update while the flyout is open. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · 28a9bbe8 · 2026-06-29
- 0.2ETV[PowerDisplay] Confirm before enabling module; log EdidId in Phase 0 (#48111) ## Summary of the Pull Request Two crash-correlation aids for the kernel-side DDC/CI BSOD mitigated by #47734: 1. Log EDID hardware ID (manufacturer + product code, e.g. `DELD1A8`) during Phase 0 monitor classification, before any DDC/CI capability fetch enters the BSOD risk window. 2. Show a confirmation dialog before turning the Power Display module on from the Settings page, so the user understands the BSOD risk before the first capability fetch runs. ## PR Checklist - [ ] Closes: #xxx - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx ## Detailed Description of the Pull Request / Additional comments ### 1. Phase 0 EdidId logging `MonitorIdentity.EdidIdFromDevicePath` parses the EDID hardware ID segment from a DevicePath of the form ``\?\DISPLAY#DELD1A8#5&abc&0&UID12345#{guid}`` and returns ``DELD1A8``. The 3-letter PNP manufacturer code + 4-hex product code is identical for every physical unit of the same model, so it identifies the *model* without leaking per-unit identifiers. `MonitorManager` logs the EdidId on the existing Phase 0 classification line. Phase 0 uses `QueryDisplayConfig`, which reads OS-cached EDID and cannot BSOD, so this line is guaranteed on disk before the crash-prone Phase 2 capability fetch starts. If a machine crashes during enumeration, the recovered log identifies every attached model (including same-model duplicates), which makes it possible to correlate crash reports to specific monitor models even when the user can't tell us which monitor caused the crash. ### 2. Enable-module confirmation dialog `PowerDisplayViewModel.IsEnabled` setter is refactored to follow the same two-phase pattern already used by `MaxCompatibilityMode`: - `false → true` does not commit immediately; it kicks off `ConfirmAndEnableModuleAsync`, which awaits the existing `DangerousFeatureWarningDialog` (resource prefix `PowerDisplay_EnableModule`) and either commits or reverts the ToggleSwitch via `OnPropertyChanged`. - `true → false` commits unconditionally — we never block a user who wants to turn the module off. - App-startup loads via `InitializeEnabledValue()` / `RefreshEnabledState()` assign the `_isEnabled` field directly, bypassing the setter, so the dialog never fires on settings restore or GPO refresh. - GPO-configured state still short-circuits before any dialog logic. The dialog reuses the existing `DangerousFeatureWarningDialog` injected by `PowerDisplayPage.xaml.cs`. The 5 new `PowerDisplay_EnableModule_*` strings explain that the BSOD is in Windows (not Power Display), that Power Display will auto-disable itself after a detected crash, and that the user has to re-enable + dismiss the warning each time. ## Validation Steps Performed - Built `src/settings-ui` and `src/modules/powerdisplay` locally. - Unit tests: added `EdidIdFromDevicePath_*` cases to `MonitorIdentityTests`, all green. - Settings UI manual: toggling Power Display ON now shows the warning dialog. Pressing Cancel reverts the ToggleSwitch visually; pressing Enable commits and the module starts. Toggling OFF does not prompt. Restarting Settings UI with PowerDisplay enabled does not prompt. GPO-disabled state still locks the toggle. - Log inspection: `MonitorManager` Phase 0 log now shows `EdidId=...` for each path before any capability fetch. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · 273d735a · 2026-05-25
- 0.2ETV[Skills] Update WinUI3 migration skills to add more migration mapping item (#47043) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #46464 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · d221f84d · 2026-06-18
- 0.2ETV[PowerDisplay] Default-off and confirm dialog for InputSource/ColorTemp/PowerState (#47303) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Three per-monitor PowerDisplay features have failure modes recoverable only via physical buttons: Input Source — switching to an input with no signal goes black; PowerToys can no longer drive a panel that isn't displaying its own signal Color Temperature — some monitors apply changes that cannot be reset via DDC/CI; OSD reset required Power State — VCP 0xD6 standby may not respond to subsequent DDC/CI wake commands This PR: Defaults all three features off for newly-discovered monitors. Supports* derivation from VCP capabilities is unchanged — unsupported checkboxes are still greyed out. Pops a confirmation dialog when a user toggles any of them on in Settings, mirroring the existing Color Temperature warning. Cancel reverts the checkbox; Enable keeps it. Refactors the existing Color Temperature click handler into a shared HandleDangerousFeatureClickAsync(sender, resourceKeyPrefix, setter) helper. All three feature handlers now reuse it. Renames PowerDisplay_ColorTemperature_EnableButton → PowerDisplay_Dialog_Enable so the three dialogs share one button-text resource (paralleling the existing shared PowerDisplay_Dialog_Cancel) <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · e6d346a5 · 2026-04-29
- 0.1ETV[PowerDisplay] Use localized "Built-in Display" name for internal display (#47321) Set all WMI monitor's name to "Built-in Display" to avoid confusing. related discussion: #47255 <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: # <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Niels Laute <niels.laute@live.nl>github.com-microsoft-PowerToys · 2aece748 · 2026-04-29
- 0.1ETV[PowerDisplay] Allow waking a monitor from standby via power-state On (#48628) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Power Display could put a monitor to sleep but never wake it back up. Selecting **On** in the per-monitor power-state list was a hard-coded no-op, so the DDC/CI wake command (VCP `0xD6` = `0x01`) was never sent. This removes that guard so selecting **On** wakes the display, and cleans up the dead code/comment left behind by the original one-directional design. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #48428 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments `MonitorViewModel.HandlePowerStateSelectionChanged` early-returned when the selected power state was **On** (`0x01`), so `SetPowerStateAsync` was never called for On and the wake write never reached the monitor. As a result Power Display's power control was one-directional: it could send Standby/Suspend/Off but could never turn a monitor back on. The guard dates back to the very first power-state commit and was paired with a single-monitor assumption — *"the monitor must be on to see the UI"*, so On was treated as the always-current state and skipped. A later change made the selection reflect the monitor's real power state (so a monitor in the list can legitimately be asleep), and multi-monitor support means the flyout can be shown on monitor A while the user wants to wake monitor B. Those changes invalidated the assumption, but the action-side guard survived a subsequent refactor. The lower layers already do the right thing: `MonitorManager.SetPowerStateAsync` → `DdcCiController.SetPowerStateAsync` → `SetVcpFeatureAsync(monitor, 0xD6, value)` passes the value through unchanged, so the fix is purely removing the UI-layer guard. DDC/CI stays reachable while the panel is in Standby/Suspend/Off(DPM), so writing `0x01` turns it back on (this is the same mechanism Twinkle Tray uses). `Off (Hard)` / `0x05` may still require a physical wake on some monitors, since that state can cut the DDC command channel. Cleanup included in this PR: - Removed the now-unused `PowerStateItem.PowerStateOn` constant (its only consumer was the deleted guard). - Removed the dead `SetPowerState` `[RelayCommand]` (the generated `SetPowerStateCommand` had zero references — the XAML wires `SelectionChanged`, not a command). - Updated the `SetPowerStateAsync` doc comment from the one-directional framing to a neutral bidirectional description. Net change: 2 files, +5 / −24. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - **Build:** `MSBuild PowerDisplay.csproj -p:Platform=x64 -p:Configuration=Debug` (CoreCompile) — **0 errors / 0 warnings**. - **Static check:** repo-wide grep confirms no remaining references to `PowerStateOn` or `SetPowerStateCommand`; the power-state ListView binds only `ItemsSource` + `SelectionChanged` (no `SelectedItem` binding), so opening the flyout cannot spuriously re-fire a selection. - **Manual (requires a DDC/CI monitor):** enable *Power state control* for a monitor → open its flyout and select **Standby** or **Off (DPM)** (screen blanks) → reopen the flyout and select **On** → the display wakes. No automated test was added: with the guard removed the handler is an unconditional pass-through (identical in shape to `HandleInputSourceSelectionChanged`), and it is an `async void` WinUI event handler over real DDC/CI hardware, which is outside the `PowerDisplay.Lib` unit-test seam. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · ff3c1f92 · 2026-06-15
- 0.0ETV[PowerDisplay] Add more log for PowerDisplay (#47270) Users have reported missing monitors but the existing logs lack the information needed to diagnose. Add discovery-phase logs that record the raw MCCS capabilities string from the monitor, the parsed feature support flags (brightness/contrast/color temperature/volume), the specific reason a monitor is ignored, and DDC/CI API failures. <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>github.com-microsoft-PowerToys · f5a294bb · 2026-04-28