-
Jakob Petsovits authored
This fixes applying display brightness from the current profile configuration at startup. This had failed on Wayland since 6.2 when KWin brightness integration was added. Here's why. In a Wayland session, the `ScreenBrightnessControl` action will not initially announce itself as supported because KWin outputs are only known after a brief asynchronous delay. Instead, it gets enabled as a reaction to the first `displayAdded`/`displayIdsChanged` signal. The `refreshActions()` slot that handles this would create and register the action object, but the action's `loadAction()` and `onProfileLoaded()` methods were not called. Because the profile was already loaded earlier, these methods would not get called until the next profile change (or wake-up from sleep). We now take care to call these action methods, but only when the profile is active. They won't be called during Core initialization, and if the login session is currently inactive. BUG: 497362
Jakob Petsovits authoredThis fixes applying display brightness from the current profile configuration at startup. This had failed on Wayland since 6.2 when KWin brightness integration was added. Here's why. In a Wayland session, the `ScreenBrightnessControl` action will not initially announce itself as supported because KWin outputs are only known after a brief asynchronous delay. Instead, it gets enabled as a reaction to the first `displayAdded`/`displayIdsChanged` signal. The `refreshActions()` slot that handles this would create and register the action object, but the action's `loadAction()` and `onProfileLoaded()` methods were not called. Because the profile was already loaded earlier, these methods would not get called until the next profile change (or wake-up from sleep). We now take care to call these action methods, but only when the profile is active. They won't be called during Core initialization, and if the login session is currently inactive. BUG: 497362
Loading