[PR #1915] Restart the brightness job after sleep on Intel Macs #1332

New issue

Open

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

gitea-mirror commented

2026-10-02 22:09:50 -06:00

Owner

📋 Pull Request Information

Original PR: https://github.com/MonitorControl/MonitorControl/pull/1915
Author: @Blizzeq
Created: 9/24/2026
Status: 🔄 Open

Base: main ← Head: fix/1911-restart-job-after-sleep

📝 Commits (1)

ac29990 Restart the brightness job after sleep on Intel Macs

📊 Changes

1 file changed (+5 additions, -3 deletions)

View changed files

📝 MonitorControl/Support/AppDelegate.swift (+5 -3)

📄 Description

Fixes #1911

After display or system sleep, soberNow() restarted job() only when the displays needed reconfiguration or on Apple silicon. On an Intel Mac with no reconfiguration the loop that ended during sleep never came back, so syncing brightness from the built-in display stopped until a relaunch, as @LuisMa9L traced in the issue. This restarts the job in that case too and keeps the AVServices update Apple silicon only. job(start:) already returns early when the loop is still running, so a quick wake does not start a second loop.

Testing

Builds with xcodebuild -scheme MonitorControl -configuration Debug (signing disabled; with Xcode 27 I had to pass MACOSX_DEPLOYMENT_TARGET=12.0 on the command line, the project itself is unchanged).
SwiftFormat --lint: no issues. SwiftLint reports the same two existing opening_brace warnings in AppDelegate.swift as on main.
There's no test target, so I checked the control flow with a small standalone Swift model of job(), sleepNotification() and soberNow(). Before the change, Intel with no reconfiguration and the loop stopped during sleep ends with no running job; after it, every combination of architecture, reconfiguration and wake timing ends with exactly one running loop. I'm on Apple silicon, so I couldn't reproduce the Intel case on hardware.

_{🔄 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/1915 **Author:** [@Blizzeq](https://github.com/Blizzeq) **Created:** 9/24/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/1911-restart-job-after-sleep` --- ### 📝 Commits (1) - [`ac29990`](https://github.com/MonitorControl/MonitorControl/commit/ac299904fc2fa422ec5b98b0badfa10debc2d0de) Restart the brightness job after sleep on Intel Macs ### 📊 Changes **1 file changed** (+5 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `MonitorControl/Support/AppDelegate.swift` (+5 -3) </details> ### 📄 Description Fixes #1911 After display or system sleep, `soberNow()` restarted `job()` only when the displays needed reconfiguration or on Apple silicon. On an Intel Mac with no reconfiguration the loop that ended during sleep never came back, so syncing brightness from the built-in display stopped until a relaunch, as @LuisMa9L traced in the issue. This restarts the job in that case too and keeps the AVServices update Apple silicon only. `job(start:)` already returns early when the loop is still running, so a quick wake does not start a second loop. **Testing** - Builds with `xcodebuild -scheme MonitorControl -configuration Debug` (signing disabled; with Xcode 27 I had to pass `MACOSX_DEPLOYMENT_TARGET=12.0` on the command line, the project itself is unchanged). - SwiftFormat `--lint`: no issues. SwiftLint reports the same two existing `opening_brace` warnings in `AppDelegate.swift` as on `main`. - There's no test target, so I checked the control flow with a small standalone Swift model of `job()`, `sleepNotification()` and `soberNow()`. Before the change, Intel with no reconfiguration and the loop stopped during sleep ends with no running job; after it, every combination of architecture, reconfiguration and wake timing ends with exactly one running loop. I'm on Apple silicon, so I couldn't reproduce the Intel case on hardware. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

gitea-mirror added the

pull-request

label

2026-10-02 22:09:50 -06:00

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#1332

No description provided.

Rows
Columns