[PR #1898] [MERGED] Fix uneven fine scale brightness steps #1325

Closed
opened 2026-10-02 22:09:48 -06:00 by gitea-mirror · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/MonitorControl/MonitorControl/pull/1898
Author: @anandghegde
Created: 9/14/2026
Status: ✅ Merged
Merged: 9/15/2026
Merged by: @waydabber

Base: main ← Head: fix-fine-scale-brightness-steps


📝 Commits (1)

  • 443ad9e Fix uneven fine scale brightness steps

📊 Changes

2 files changed (+2 additions, -5 deletions)

View changed files

📝 MonitorControl/Model/Display.swift (+1 -4)
📝 MonitorControl/Model/OtherDisplay.swift (+1 -1)

📄 Description

Fixes #1759

Two small bugs that together cause the uneven steps described in the issue.

Built-in / software-dimmed displays (Display.calcNewBrightness)

The fine scale step is 1/64, but the snapping tolerance (delta) was taken from the coarse step (1/16 / 4 = 1/64). So with fine scale on, tolerance and step were the same size and there was no slack at all. Brightness read back from DisplayServices is often a tiny bit off the 1/64 grid (on my Mac, setting 2/64 reads back as 0.031250004), and whenever it lands just above a boundary the next press jumps two steps. The coarse scale already uses a quarter-step tolerance; this makes the fine scale do the same.

Simulating 64 presses with the read-back noise I measured:

  • before, fine up: 62 presses, 1,2,4,5,7,8,9,...; fine down: 55 presses, ...57,55,54,...
  • after: 64 presses both ways, every step 1/64

Coarse stepping is unchanged (16 steps either way).

DDC displays (OtherDisplay.convValueToDDC)

The value was converted to an integer by truncating. Fine scale adds 0.01 each press, and in Float 0.29 + 0.01 is 0.29999998, which becomes DDC 29 again. Stepping up from 0 with a max of 100, truncation gives: 4 sent twice, 15 skipped, 29 sent twice, and it tops out at 99. That's exactly the "repeated 4%, skipped 15, repeated 29" from the issue. Rounding gives 1..100 with no repeats or skips. It also means a value read from the display and written back now maps to the same DDC value.

This doesn't address the one-off "59 sets the monitor to 100%" from the issue; I couldn't reproduce that from the code path.

Testing

  • Builds with xcodebuild -scheme MonitorControl -configuration Debug (signing disabled).
  • SwiftFormat --lint and SwiftLint: no issues in the changed files.
  • There's no test target, so I checked both changes with small standalone Swift scripts that copy the old and new functions (results above). I don't have a DDC monitor here, so I haven't tested on real DDC hardware.

Implemented with Claude Code; I reviewed and tested the change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MA8JGs7pCoXFL2W6jEJ8sD


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/MonitorControl/MonitorControl/pull/1898 **Author:** [@anandghegde](https://github.com/anandghegde) **Created:** 9/14/2026 **Status:** ✅ Merged **Merged:** 9/15/2026 **Merged by:** [@waydabber](https://github.com/waydabber) **Base:** `main` ← **Head:** `fix-fine-scale-brightness-steps` --- ### 📝 Commits (1) - [`443ad9e`](https://github.com/MonitorControl/MonitorControl/commit/443ad9ecc34a4c7509dc8d238420a9e3fa6f7512) Fix uneven fine scale brightness steps ### 📊 Changes **2 files changed** (+2 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `MonitorControl/Model/Display.swift` (+1 -4) 📝 `MonitorControl/Model/OtherDisplay.swift` (+1 -1) </details> ### 📄 Description Fixes #1759 Two small bugs that together cause the uneven steps described in the issue. **Built-in / software-dimmed displays (`Display.calcNewBrightness`)** The fine scale step is 1/64, but the snapping tolerance (`delta`) was taken from the coarse step (1/16 / 4 = 1/64). So with fine scale on, tolerance and step were the same size and there was no slack at all. Brightness read back from DisplayServices is often a tiny bit off the 1/64 grid (on my Mac, setting 2/64 reads back as 0.031250004), and whenever it lands just above a boundary the next press jumps two steps. The coarse scale already uses a quarter-step tolerance; this makes the fine scale do the same. Simulating 64 presses with the read-back noise I measured: - before, fine up: 62 presses, `1,2,4,5,7,8,9,...`; fine down: 55 presses, `...57,55,54,...` - after: 64 presses both ways, every step 1/64 Coarse stepping is unchanged (16 steps either way). **DDC displays (`OtherDisplay.convValueToDDC`)** The value was converted to an integer by truncating. Fine scale adds 0.01 each press, and in `Float` 0.29 + 0.01 is 0.29999998, which becomes DDC 29 again. Stepping up from 0 with a max of 100, truncation gives: 4 sent twice, 15 skipped, 29 sent twice, and it tops out at 99. That's exactly the "repeated 4%, skipped 15, repeated 29" from the issue. Rounding gives 1..100 with no repeats or skips. It also means a value read from the display and written back now maps to the same DDC value. This doesn't address the one-off "59 sets the monitor to 100%" from the issue; I couldn't reproduce that from the code path. **Testing** - Builds with `xcodebuild -scheme MonitorControl -configuration Debug` (signing disabled). - SwiftFormat `--lint` and SwiftLint: no issues in the changed files. - There's no test target, so I checked both changes with small standalone Swift scripts that copy the old and new functions (results above). I don't have a DDC monitor here, so I haven't tested on real DDC hardware. Implemented with Claude Code; I reviewed and tested the change. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01MA8JGs7pCoXFL2W6jEJ8sD --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
gitea-mirror 2026-10-02 22:09:48 -06:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
github-starred/MonitorControl#1325
No description provided.