Repository navigation
Conversation
On first setup (or when a display reports a maximum of 0) the read value was converted using a maxDDC of 0, saving NaN to the prefs. Converting that back to a DDC value traps, crashing the app on the next brightness change. Existing NaN prefs are removed on setup, so affected users recover without resetting their settings.
Member
|
Thanks for the fix! The ordering change and One small edge case: with Once this is fixed, I'll merge it. Thanks! |
Author
|
Good catch; any min override of 100 or more ended up there, as the detect limit also clips the reported max. The effective max is now forced above the min before saving. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a display shows up under a new prefs id (after wake or re-docking, for example),
setupCurrentAndMaxValuesconverts the DDC value it just read beforemaxDDCis stored. With min and max both 0,convDDCToValuedivides 0 by 0 and the NaN gets saved as the current value. The next brightness change then traps onUInt16(NaN)inconvValueToDDC; themin/maxclamps don't help, as they pass NaN through.This PR stores
maxDDCbefore converting the read value. A display that reports a maximum of 0 falls back toDDC_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
maxDDCkeys from the prefs: every command loggedCurrent internal value: nanand 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.