Open Khraut opened 3 months ago
Hello!
Sorry for the long delay in my response!
First of all, I want to say that the use-case is definitely valid, and you are right that a separate script changing the backlight would indeed make wluma learn the new behavior.
Could you tell me more about your experience, in what cases do you want the keyboard backlight turned off? What if you are just using a mouse / touchpad for several minutes, is that the reason to turn the keyboard backlight off? If you are watching a movie, would you rather want to turn off entire wluma off for this period, as opposed to just keyboard?
What I'm trying to understand is whether it makes sense to turn off entire wluma on inactivity (and possibly save some energy on not trying to scan screen contents and various sensors), or there are some cases when only keyboard backlight needs to be turned off. For the former, a cheap solution could be to make swayidle start and stop wluma process.
Thanks for the reply!
I don't know if my use case is common. I am using my Laptop as a desktop replacement. It's hooked up to a second monitor and the internal screen is used as a secondary display.
Apart from the keyboard backlight everything works as expected and it's really nice to have both the internal and the external screen controlled by the ambient light sensor.
What annoys me is the keyboard backlight not turning off since I am not using the internal keyboard it is more of a distraction.
I think this case can be handled in 2 ways:
Completely turn off keyboard backlight when connected to an external display
a simple timeout that is only affected by the interaction with the touchpad/internal keyboard
This way it should just stay off during "Desktop mode".
What do you think of this approach?
I think a timeout would be also superior during a movie session or similar cases because the brightness of the screen should stay in auto mode. If you would just stop wluma it would also stop the brightness control or not? 🤔
Thanks for the details, it really helps to understand the actual use-case!
My immediate thoughts is that detecting whether interaction occurs via an internal vs external keyboard would probably be quite difficult to do, and perhaps more importantly I don't think it's up to wluma to impose such kind of rules on its users.
It sounds like, if you had the ability to tell wluma to stop managing a specific device (keyboard in this case), it would solve your use-case. We don't have such feature built-in, but we do have a way to simulate this, to see if it actually leaves you happy with the workflow. Would you like to try this?
If yes, here's how I would do it:
config.toml
into config-laptop.toml
and config-desktop.toml
, and remove the keyboard part from the config-desktop.toml
one (so they differ only in that one of them has keyboard, and another does not).config.toml
and instead create a symlink config.toml
, pointing to one of the actual files.Let me know if this works at all, and if yes, whether it actually gives you the experience you desire?
If this works well, then we can think of how to build this in, whether by having "profiles" that you can choose between, or an ability to toggle specific devices on and off.
Please describe your feature request
First of all a big thanks for wluma! It is really a program to handle my backlight automation needs!
Nonetheless it would be nice to have a timeout for the keyboard backlight. Although there are some tools that provide a keyboard backlight timeout after a certain period of time, where the keyboard is not interacted with, to turn of the backlight, I assume that these tools would interfere with wluma's learning thing.
My assumption is, that if i had a script running that would turn of the backlight, wluma would think, that my backlight under this lighting conditions should be turned off.
I think it would make more sense for wluma to handle it by itself.