Mirrors/PowerToys
1
0
Fork 0
mirror of https://github.com/microsoft/PowerToys.git synced 2026-09-01 19:51:34 +02:00
Code Issues Packages Projects Releases Wiki Activity
9,565 Commits 719 Branches 148 Tags
ed0605a68ccaffd97b67dfd08fd43e8687fe34db
Commit Graph

3 Commits

Author SHA1 Message Date
moooyo
8f63402400 PowerDisplay: Adjust brightness by scrolling over the tray icon (#49446) 
## Summary of the Pull Request

Scrolling the mouse wheel over the Power Display tray icon adjusts
brightness, without opening the flyout.

- New **Tray icon mouse wheel** setting: `Off` / `Primary display` /
`All displays`, defaulting to **`Off`**. It is scoped to the tray icon —
the flyout sliders accept wheel input regardless, as they always have.
The existing **Mouse wheel increment** setting supplies the per-notch
step.
- **Off by default.** The gesture consumes a wheel notch that would
otherwise reach the window under the pointer, and acting on it installs
a system-wide `WH_MOUSE_LL` hook. Neither is something an existing
installation should acquire silently on upgrade. With the setting `Off`
no hook is ever installed and no notch is ever consumed, so this PR
changes no existing behaviour until the user opts in: 1958 insertions, 2
deletions, and both deletions are refactors of lines this feature
reuses.
- **No feedback UI.** Brightness is self-evidencing — you scroll and the
screen changes — so the display itself is the feedback. The notification
icon is untouched: same tooltip, same text, same legacy
notification-icon protocol.

## PR Checklist

- [x] Closes: #49410
- [ ] **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
- [x] **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

No new binaries or projects — everything lands in existing assemblies.
Communication is unchecked because #49410 is still Needs-Triage.

## Detailed Description of the Pull Request / Additional comments

### Why a low-level hook

The Shell does not forward `WM_MOUSEWHEEL` to a notification icon's
callback window under any `NOTIFYICON_VERSION`, and a click-through
overlay placed over the icon cannot receive wheel input either.
`TrayIconMouseWheelListener` therefore installs a `WH_MOUSE_LL` hook —
but only transiently, and only when it will act on the result:

- Nothing is installed at all while the setting is `Off`, which is the
default.
- Installed in `EnsureHook()` when the UI thread confirms the pointer is
inside the rectangle from `Shell_NotifyIconGetRect` **and**
`CanAdjustBrightnessFromTrayWheel` says some monitor can accept a
brightness write.
- Removed in `DisarmCore()` as soon as either condition stops holding,
the pointer leaves the rectangle, or the mode changes.
- A notch is consumed (the hook proc returns non-zero) only while armed
and only for points inside the armed rectangle, so a wheel event Power
Display will not act on still reaches the window under the cursor.

The hook runs on a dedicated background thread with its own message
loop; the proc itself only enqueues a sample and posts a drain request.
Deltas are marshalled to the UI thread in batches, and
`WheelDeltaAccumulator` folds high-resolution deltas (precision wheels,
touchpads) into whole notches. Each sample carries the hover generation
it was captured under, so samples from a hover the UI thread has already
retired are discarded rather than applied late.

### Hover detection

The Shell sends `WM_MOUSEMOVE` to the icon's callback window while the
pointer is over it. `TrayIconService.HandleTrayMouseMove` resolves the
rectangle with `Shell_NotifyIconGetRect` and caches it for a second,
because that message repeats for every pixel of travel.

`TrayIconService` gains nothing else: no protocol change, no new hover
UI, no polling. The rest of the file — and `MainWindow.xaml` — is
untouched.

### Linked brightness

While linked brightness is on, a notch has to move the whole group, so
it goes through `MainViewModel.LinkedBrightness` rather than the
individual monitor setters. The new master value is taken from the
planner's value for the monitor the wheel named, **not** from the
current master. The master is positional only —
`SeedInitialLinkedBrightness` takes it from the lowest-numbered linked
monitor and never writes hardware, and every monitor-list rebuild
re-seeds it — so it can sit arbitrarily far from the monitor the wheel
is aimed at. Stepping it relative to itself would apply a wrong-sized or
wrong-signed change, and a master already clamped at 0/100 would swallow
the notch while writing nothing at all.

The setting description calls out that linked brightness widens the
scope, so `Primary display` is not literally a single display while it
is on.

### What is deliberately not here

An earlier revision of this PR showed the target and percentage in a
custom overlay as you scrolled. Doing that meant the standard Shell
tooltip would not do (it cannot be shown on demand), which meant an own
window, which meant suppressing the Shell tooltip so the two did not
collide, which meant `NOTIFYICON_VERSION_4`, which changed the callback
packing and made the app responsible for all hover text — including for
keyboard and touch users, who never reach a cursor-anchored overlay and
would have been left with no visible tooltip at all.

That chain was about half the diff, for a readout that adds little on
top of watching the screen change. It is gone. If a readout is wanted
later it can be argued on its own merits, separately from this feature.

The same revision also gated the flyout sliders on this setting. That
bundled two unrelated things behind one switch — turning off tray
scrolling would also have stopped the contrast and volume sliders
responding to the wheel — so the setting is now scoped to the tray icon
and named accordingly.

An earlier revision also routed the tray **Exit** action through
`Shutdown()`. That fixes a pre-existing teardown leak which has nothing
to do with this feature, so it now lives in #49580 and is out of scope
here. This branch does not depend on it: the hook thread is a background
thread and the process is ending either way.

## Validation Steps Performed

- Unit tests: `PowerDisplay.Lib.UnitTests` 215 passed,
`Settings.UI.UnitTests` 165 passed.
- Builds: `PowerDisplay` and Settings UI, x64 Debug, no warnings.
- Automated coverage is in `PowerDisplay.Lib.UnitTests`: target
selection per mode, wheel accumulation including negative deltas,
partial notches and direction reversal, half-open rectangle containment,
and settings serialization and round-trip for the new mode, including
that a settings file predating the feature loads as `Off`.
`Settings.UI.UnitTests` covers the view-model index mapping and pins the
enum values to the ComboBox item order.
- The Win32 glue in `TrayIconService` and `TrayIconMouseWheelListener`
is not unit tested.

Manual passes performed: scrolling over the icon in both modes, the icon
parked in the notification overflow, high-resolution wheel input,
brightness boundaries, live monitor refresh while hovering, tray icon
hidden and re-enabled, Explorer restart, the context menu and
left-click, `Off` stopping tray scrolling while the flyout sliders keep
working, and confirming a notch that Power Display will not act on still
reaches the window under the cursor.

Not verified, needing hardware this branch has not been run on:

- Multiple taskbars, where the tray icon is on a secondary display and
`Primary display` mode adjusts a monitor the user may not be looking at.
- Mixed-DPI setups, for the `Shell_NotifyIconGetRect` rectangle and the
hook's physical-pixel hit test.

---------

Co-authored-by: Yu Leng <yuleng@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copilot-Session: 5d7f36fe-d175-4aa9-a3c7-b370d952d1d3
 2026-07-31 16:21:08 +08:00
moooyo
2b8e6247fc [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>
 2026-07-16 14:33:21 +08:00
moooyo
18efa0559c Introduce new utility PowerDisplay to control your monitor settings (#42642) 
<!-- 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
Introduce a new PowerToys' module PowerDisplay to let user can control
their monitor settings without touching monitor's button.

Support feature list:
Common:
1. Profiles support
2. Integration with LightSwitch (auto switch profile when theme change)
3. TrayIcon
4. Save and restore settings when startup
5. Shortcut
6. Rotation
7. GPO support
8. Auto re-discovery monitor when plugging and unplugging monitors.
9. Identify Monitors
10. Quick profile switch

Especially for DDC/CI monitor:
1. Brightness
2. Contrast
3. Volume
4. Color temperature (preset profile)
5. Input source
6. Power State (poweroff)


Design doc:
https://github.com/microsoft/PowerToys/blob/yuleng/display/pr/3/doc/devdocs/modules/powerdisplay/design.md

AOT compatibility:
I designed this module for AOT from the start, so I'm pretty sure at
least 95% of it is AOT compatible. But unfortunately, PowerToys still
have a AOT blocker to block this module publish with AOT.

Currently PowerToys will check the .net file version (file version not
lib version) to avoid crash. So, all modules should reference Common.UI
or add UseWPF to avoid overwrite the .net file with different version
(which may cause crash).

Todo:
- [ ] BugBash
- [ ] Icon
- [ ] IdentifyWindow UI improvement


Demo

Main UI:
<img width="546" height="671" alt="image"
src="https://github.com/user-attachments/assets/b0ad9ac5-8000-4365-a192-ab8c2d66d4f1"
/>

Input Source:
<img width="536" height="674" alt="image"
src="https://github.com/user-attachments/assets/80f9ccd7-4f8c-4201-b177-cc86c5bcc9e3"
/>


Settings UI:
<img width="1581" height="1191" alt="image"
src="https://github.com/user-attachments/assets/6a82e4bb-8f96-4f28-abf9-d7c45e1c8ef7"
/>

<img width="1525" height="1146" alt="image"
src="https://github.com/user-attachments/assets/aae81e65-08fd-453a-bf52-02a74f2fdea0"
/>



Closes: 
#42942
#42678
#41117
#38109
#35564
#34932
#28500
#1052
#18149

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [x] Closes: #1052
- [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
- [x] **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: Niels Laute <niels.laute@live.nl>
Co-authored-by: moooyo <lengyuchn@gmail.com>
Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
 2026-02-03 13:53:25 +08:00