[PR #1932] Fix crash on NaN DDC value after display reconfiguration #1341

New issue

Open

opened 2026-10-27 22:00:44 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-10-27 22:00:44 -06:00

Owner

📋 Pull Request Information

Original PR: https://github.com/MonitorControl/MonitorControl/pull/1932
Author: @Bouke
Created: 10/27/2026
Status: 🔄 Open

Base: main ← Head: fix/nan-ddc-value-crash

📝 Commits (1)

9906864 Store maxDDC before converting the read DDC value

📊 Changes

2 files changed (+10 additions, -4 deletions)

View changed files

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

📄 Description

When a display shows up under a new prefs id (after wake or re-docking, for example), setupCurrentAndMaxValues converts the DDC value it just read before maxDDC is stored. With min and max both 0, convDDCToValue divides 0 by 0 and the NaN gets saved as the current value. The next brightness change then traps on UInt16(NaN) in convValueToDDC; the min/max clamps don't help, as they pass NaN through.

This PR stores maxDDC before converting the read value. A display that reports a maximum of 0 falls back to DDC_MAX_DETECT_LIMIT (I've seen an iiyama do this for volume over HDMI), and a NaN that earlier versions already saved is removed, so the value is read again.

I reproduced it on 4.4.0 by removing the maxDDC keys from the prefs: every command logged Current internal value: nan and the next brightness key press crashed. With this change the same steps give valid values. Probably the same crash as #1919. #1874 also guards against min == max in the conversions, but doesn't cover the ordering or the NaN values already in people's prefs.

_{🔄 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/1932 **Author:** [@Bouke](https://github.com/Bouke) **Created:** 10/27/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/nan-ddc-value-crash` --- ### 📝 Commits (1) - [`9906864`](https://github.com/MonitorControl/MonitorControl/commit/9906864c0d7cf6596dd860b5cef994850e24bbde) Store maxDDC before converting the read DDC value ### 📊 Changes **2 files changed** (+10 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `MonitorControl/Model/Display.swift` (+1 -1) 📝 `MonitorControl/Model/OtherDisplay.swift` (+9 -3) </details> ### 📄 Description When a display shows up under a new prefs id (after wake or re-docking, for example), `setupCurrentAndMaxValues` converts the DDC value it just read before `maxDDC` is stored. With min and max both 0, `convDDCToValue` divides 0 by 0 and the NaN gets saved as the current value. The next brightness change then traps on `UInt16(NaN)` in `convValueToDDC`; the `min`/`max` clamps don't help, as they pass NaN through. This PR stores `maxDDC` before converting the read value. A display that reports a maximum of 0 falls back to `DDC_MAX_DETECT_LIMIT` (I've seen an iiyama do this for volume over HDMI), and a NaN that earlier versions already saved is removed, so the value is read again. I reproduced it on 4.4.0 by removing the `maxDDC` keys from the prefs: every command logged `Current internal value: nan` and the next brightness key press crashed. With this change the same steps give valid values. Probably the same crash as #1919. #1874 also guards against min == max in the conversions, but doesn't cover the ordering or the NaN values already in people's prefs. --- <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-27 22:00:44 -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#1341

No description provided.

Rows
Columns