[z1pp090]

Summary

On desktops whose monitors don't expose brightness through WMI (external displays, no WmiMonitorBrightness instances), BrightnessManager::init() fails with WBEM_E_NOT_SUPPORTED and every start logs a context-free error:

[ERROR][seelen_ui::error] WMI(HResultError { hres: -2147217396 })

That is the expected answer of the provider on such hardware (Get-CimInstance -Namespace root/wmi -ClassName WmiMonitorBrightness fails the same way), not a fault, so this PR treats it as "nothing to track": the manager keeps an empty list and logs at debug level instead. The notification thread is now only spawned when the initial query succeeded, since it fails with the same error and just died silently before.

Changes

• src/background/modules/monitors/brightness/application.rs: match WMIError::HResultError { hres } against WBEM_E_NOT_SUPPORTED (0x8004100C) in init(); move the initial query before the thread spawn.

Testing

• CI green on my fork.
• Built this branch (unsigned, throwaway signing key) and ran it in a fresh Windows Sandbox: the error line is gone, replaced by [DEBUG][seelen_ui::modules::monitors::brightness::application] Monitor brightness is not supported through WMI on this system; app and service ran normally for the 120 s window. Not tested on a laptop with a WMI-capable panel (the success path is unchanged apart from the reordering).

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with no actionable regression identified in the changed initialization flow.

Summary

This PR treats WMI brightness capability absence as an expected condition rather than an initialization error.

• Queries initial brightness state before starting the notification listener.
• Logs WBEM_E_NOT_SUPPORTED at debug level and leaves the manager empty.
• Starts brightness notifications only after the initial WMI query succeeds.

_{Reviews (1) · Last reviewed commit: "fix(brightness): don't log an error when..."}