mirror of
https://github.com/MonitorControl/MonitorControl.git
synced 2026-10-23 08:07:35 -06:00
[PR #1898] [MERGED] Fix uneven fine scale brightness steps #1325
Labels
No labels
Status: Abandoned
arm64
beta
beta
bug
done
duplicate
enhancement
feedback needed from reporter
in progress
information
invalid
investigating
known Issue
monitor Issue
pull-request
translation
unable to reproduce
unreleased
x86
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
github-starred/MonitorControl#1325
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 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)
443ad9eFix 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:
1,2,4,5,7,8,9,...; fine down: 55 presses,...57,55,54,...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
Float0.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
xcodebuild -scheme MonitorControl -configuration Debug(signing disabled).--lintand SwiftLint: no issues in the changed files.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.