Interaction with manual adjustment:
First option – if the user manually changes the brightness then the auto-adjustment is temporarily paused for N seconds (e.g., 30–60s) so as not to "override" the user's intention. A notification could be shown about this.
Second option, as already mentioned by the author, is to use so-called Learned Auto-Brightness. That is, a brightness curve is built based on how the user adjusts brightness under certain lighting conditions.
Third option – allow the user to explicitly configure the brightness curve.
Multiple screens:
Use auto-brightness only for monitors with a built-in ambient light sensor and DDC/CI support. To begin with, support could be limited only to the laptop’s built-in screen if it has a light sensor.
Adding detailed configuration for external monitors that support DDC/CI but lack ambient light sensors is complex and offers limited value. In these cases, a more useful approach would be "change brightness and contrast based on content" (e.g., like in the mentioned
wluma, orbrightml, or similar to Windows).
General considerations:
Introduce hysteresis and/or time-based smoothing to avoid flickering or abrupt changes when ambient light fluctuates rapidly.
Store independent lux → brightness mappings for each detected sensor.
Notify users when the brightness adjustment method changes, or alternatively, explain the behavior clearly within the KCM interface.
By default, auto-brightness should be disabled.