This fixes applying display brightness from the current profileconfiguration at startup. This had failed on Wayland since 6.2when KWin brightness integration was added. Here's why.
In a Wayland session, the ScreenBrightnessControl action will notinitially announce itself as supported because KWin outputs are onlyknown after a brief asynchronous delay. Instead, it gets enabledas a reaction to the first displayAdded/displayIdsChanged signal.
The refreshActions() slot that handles this would create andregister the action object, but the action's loadAction() andonProfileLoaded() methods were not called. Because the profilewas already loaded earlier, these methods would not get calleduntil the next profile change (or wake-up from sleep).
We now take care to call these action methods, but only when theprofile is active. They won't be called during Core initialization,and if the login session is currently inactive.
Also part of this MR:
daemon: Ensure legacy display ids exist before comparing the first one
Prevents a crash if a handler for a ScreenBrightnessController signalcalls setBrightness() before legacy display ids were updated.I'm not aware of any such crash happening for end users so far,but my next patch (i.e. the above main commit) will exercise this code path, requiring this fix.
CC @zamundaaa, @nicolasfella, @iasensio - thanks in advance for your review(s)