Fix: System UI brightness slider has no effect while KompaktX is running - #4
Open
chadchad4423 wants to merge 2 commits into
Open
Conversation
added 2 commits
August 24, 2026 18:57
KompaktX's overlay-based brightness control (OverlayPanelManager) is the sole path that actually drives the physical backlight, via the screenBrightness field on a persistent overlay window. A ContentObserver on Settings.System.SCREEN_BRIGHTNESS was meant to reapply that value if something cleared it, but it fired on ANY external write to that setting -- including the one the stock System UI brightness slider makes -- and immediately stomped it back to KompaktX's last value. That's why the System UI slider appeared to do nothing while KompaktX was installed. Since applyBrightness() already sets currentBrightnessTarget before writing Settings.System.SCREEN_BRIGHTNESS, a self-triggered observer callback always finds sys == target and is a no-op. A callback where sys != target is therefore reliably an external change. Flip the observer to adopt that external value as the new target instead of reverting it, mirroring applyBrightness()'s side effects (overlay screenBrightness, lockscreen accessibility overlay, and persistence) so the change reaches the physical screen, survives a KompaktX process restart, and applies above the lockscreen too. No UI/range changes: brightness remains a plain linear 0-255 value in both directions, matching the existing stock-slider behavior.
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
1 participant
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.
Fix: Adaptive Brightness has no effect on physical brightness while KompaktX is running
KompaktX drives the physical backlight through a persistent 1x1 overlay window (
WindowManager.LayoutParams.screenBrightness), separate from Android's own brightness system. That overlay's brightness value was set once and never released, so even after a user turned Adaptive Brightness back on, the overlay kept pinning the screen to its last static value — physical brightness stopped responding to ambient light entirely, even though the Adaptive Brightness toggle itself correctly showed "on."A second, related path made this worse:
brightnessObserver(theContentObserverwatchingSettings.System.SCREEN_BRIGHTNESS) would react to any external brightness write — including the ones Android's own adaptive-brightness algorithm makes continuously — by re-pinning the overlay back to a stale target, fighting the system's live adjustments in real time.This PR:
ContentObserveronSettings.System.SCREEN_BRIGHTNESS_MODEthat releases the overlay/panel/lockscreen brightness overrides the moment Adaptive Brightness is turned on, so the physical backlight goes back to being fully system-controlled.isAdaptiveBrightnessOn()guard at the top ofbrightnessObserver'sonChange(), so it stops reacting toSCREEN_BRIGHTNESSwrites at all while adaptive mode is active — it no longer fights the system's own live adjustments.applyBrightness(forceManualMode = false), used byreapplyBrightness()/loadSavedBrightness()) to skip overlay pinning entirely while Adaptive Brightness is already on.Testing
Built on top of #5 (Fix 2) since this change depends on the
forceManualModeparameter it introduces. Verified on a physical Mudita Kompakt (MuditaOS K 1.5), standalone and combined with the other three fixes (Fix 1 + Fix 2 + Fix 3 + Fix 4 together, cherry-picked onto one branch):Note: This PR is stacked on PR #5 and includes its forceManualMode change, so it can be merged directly into main either before or after PR #5 is handled. It should also be reviewed alongside PR #4: both modify brightnessObserver. Their combined result has been tested successfully, although the second PR merged may require minor conflict resolution depending on merge strategy.