[PowerDisplay] Detect built-in panel when driven by the discrete GPU

[moooyo]

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

• Closes: PowerDisplay unable to detect monitor when using GPU instead of iGPU on laptop #48587
• 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 (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 PowerDisplay unable to detect monitor when using GPU instead of iGPU on laptop #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).

[github-actions]

@check-spelling-bot Report

🔴 Please review

See the 📂 files view, the 📜action log, 👼 SARIF report, or 📝 job summary for details.

Unrecognized words (3)

eca
Miracast
misrouting

These words are not needed and should be removed

DISPLAYPORT JPN LVDS miracast SVIDEO

To accept these unrecognized words as correct and remove the previously acknowledged and now absent words, you could run the following commands

... in a clone of the git@github.com:microsoft/PowerToys.git repository
on the yuleng/pd/f/12 branch (ℹ️ how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/cfb6f7e75bbfc89c71eaa30366d0c166f1bd9c8c/apply.pl' |
perl - 'https://github.com/microsoft/PowerToys/actions/runs/27536878797/attempts/1' &&
git commit -m 'Update check-spelling metadata'

OR

To have the bot accept them for you, comment in the PR quoting the following line:
@check-spelling-bot apply updates.

If the flagged items are 🤯 false positives

If items relate to a ...

• binary file (or some other file you wouldn't want to check at all).

  Please add a file path to the excludes.txt file matching the containing file.

  File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

  ^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

• well-formed pattern.

  If you can write a pattern that would match it,
  try adding it to the patterns.txt file.

  Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

  Note that patterns can't match multiline strings.