[Feature request]: Increase keyboard brightness when display brightness is reduced on [als.none] #130
Comments
|
One challenge here is that in a general case you have many screens and many keyboards, so you need somehow to express a dependency on a particular screen for a given keyboard...
Do you mean you can't use it because of #127? I think we will make #127 compatible in terms of config, but if you leave #127 for a second, would you then be satisfied with keyboard being managed by e.g. |
Ah, yes, you are right about that. I was only thinking about the single-screen case. But as you are saying, tying a keyboard to a particular (main?) display feels an alright solution. If that won't feel good, then maybe use the average of each screen? Can be explored. But the concept makes sense to you too right? i.e. add an optional feature to wluma that automatically makes the keyboard visible when user decreases screen brightness.
No no, making the config UI incorporate all this in a nice way should not be a problem eventually. Thing is als.time implies a regularity in ambient change, which my environment doesn't have often; I like to turn off the light sometimes which is very random so I feel wluma can't do much in this case without (real sensors or) manual help which can come in the form of the user pressing brightness up/down. |
|
The use-case makes sense, and it's not something that can be achieved with existing features, so it's definitely a valid request that is valuable to fix. Still considering whether the particular idea of tying keyboard to another screen's prediction is the best way forward. In reality wluma doesn't distinguish keyboard from screen much, it's all the same to it, the same predictor that runs and uses available inputs (als is available for both, keyboards obviously dont have luma). So another approach can for example be to let keyboard's predictor receive luma of a specific output, to make better judgements. Combine this with #127, where you are building an alternative predictor, and that predictor could also be applied for a keyboard - we tell it to use luma of screen X, you tell it a different curve to use, and we reuse all the other logic. Not saying that this is the best idea, just an alternative consideration. |
You mean tying the final display brightness prediction to keyboard illumination? It will be opt-in so shouldn't be an issue. It is a second step for wluma manual mode you can say, if the current PR is the first.
I am away from my laptop so can't read the read code right now, but you mean to say that the learning slash prediction logic is the same regardless of final value being for a keyboard or a display? That is, save a bunch of data points and predict the next point. Makes sense.
I think it should have more to do with user-adjusted brightness as input, and only when user manually adjusts, not when wluma is auto adjusting. Display content's luma can be accounted in the calculation alongside brightness as well, I can be wrong but I don't think most keyboards have that many levels for keyboard brightness to need such fine control. Most keyboards (dell xps and thinkpad in my usage) I have seen only have three levels: off, low, and high. Mac keyboards definitely have more.
The config UI can be very similar if not exactly the same, yup. Logic is definitely reusable too. Just one thing as mentioned above, use brightness instead of luma. |
|
Keyboards definitely don't need as high fidelity as screens do, the point is rather that it's nice to have generic solutions and let people compose them - easier to maintain too. The existing predictor (predict desired brightness based on als and luma) is a single implementation, that is used both for screens and for keyboards (for keyboards luma is simply always zero). #127 will have a new predictor (predict desired reduction based on luma), which we again can apply to keyboards - except in that case we need to give it some luma, from some screen. And so if this works, we just have two predictors, and we don't need a special case for keyboard for a special predictor. Let's maybe take this after #127, it will maybe make more sense or just be easier to discuss when we have something concrete :) |
Yeah.
Yes, I completely agree with all your points. I am just saying that the input for the predictor when being used for keyboards, it should be some display's brightness and trigger is when the user changes it, not display content luma which keeps changing randomly. A lot of logic is definitely shared, yes, and we will definitely reflect it in code.
I guess you are right, just a thing to keep in mind that this is what's next. |
|
Could you actually give some examples / scenarios of why it has to be done on manual action? Whether you want keyboard to be lit when you manually set brightness to |
|
It has to be manual because keyboard potentially constantly turning on and off when switching back and forth between windows will be annoying. It can happen when the conditions are just right. |
|
Sure, but what if the conditions are just right, I don't want to change screen brightness, it is already perfect thanks to perfect wluma algorithm, but I dont see keyboard so I'm forced to take an unwanted brightness change? Why is it wrong to toggle keyboard backlight when I'm toggling between two states, one where I do and one where I don't see my keyboard? |
In that case you just turn on the keyboard backlight like you normally do, this feature is just auxiliary action from wluma, which the user has opted into knowingly that it too isn't perfect.
Let's say your configuration was such that the keyboard backlight turns on for brightness below 10% and turns off above 10%. Imagine you are sitting in the dark. It will be perfectly fine if wluma keeps switching display brightness to above 10% (e.g. 12%) and below 10% (e.g. 8%) when switching between bright and dark apps, but it will get pretty annoying if my keyboard backlight keeps switching on and off. This feature is meant mostly for situations like when you turn off the lights in the room and you can't see the keyboard, so you reduce the brightness manually and wluma notices it and automatically turns on the keyboard backlight and (coming in #127) also adjusts the "anchor" for luma-based screen-brightness auto-adjustments. By anchor I mean the Maybe this feature doesn't make that much sense when you do have an actual als or equivalent, but certainly goes hand in hand with #127 and makes wluma complete for me. Let's collectively call both of these features "manual-mode". Manual-mode is great for people who want something midway between full automation (what wluma currently is) and not having wluma at all, because they either can't use an als or equivalent, or maybe because they simple prefer it this way. |
|
I'm still not fully convinced on the idea that the desired level of keyboard backlight can't be "predictably" defined based on the current state of things alone, but has to depend on recent external factors 🤔 Taking it to extreme, if you are teleported into a dim room in front of a laptop and are tasked to type a sentence on the keyboard, you either can or cannot comfortably see the keyboard in front of you - regardless if I was there in the room a minute before and manually adjusted the brightness or not. If you are then teleported into a different room with potentially other lighting conditions, and are again tasked to type a sentence, it's the new conditions that dictate whether you can or cannot comfortably see the keyboard, not the conditions of the previous room or whether I was recently in the new room manually adjusting the brightness a minute ago. Right? 😅 So if you are being annoyed by the keyboard being turned on and off, as you are teleported between two rooms back and forth, is it maybe because keyboard is being not lit up when you can't see it, or lit up when it's obviously bright enough anyway (i.e. bad configuration / wrong curve), or maybe because you are not even tasked to type any text at this point, so you don't need the keyboard backlight in any case even if it's pitch black room (i.e. missing additional input signals, such as task at hand or time of last keypress)? Going away from abstract discussions for a moment, assuming that we want to implement exactly the behavior you described, I'm wondering if the UNIX principle should be applied and a simple script would do a better job here. Consider that the proposed algorithm doesn't depend on ALS, does not depend on screen contents, does not depend on the current backlight status of the keyboard, and does not even depend on the current brightness level of the screen - it depends on the screen brightness that you are setting. Imagine your current keybinding to increase screen brightness does something like this today: brightnessctl set -- +1%You could instead make it do this instead, solving all your needs? current=$(brightnessctl -m | awk -F, '{print substr($4, 0, length($4)-1)}')
desired=$(( current + 1))
brightnessctl set -- "${desired}%"
desired_kbd=$(( desired <= 5 ? 1 : (desired <= 10 ? 2 : 0) ))
brightnessctl set -d kbd_backlight "$desired_kbd" |
I think we might be meaning different things when saying what a not-visible keyboard in a dark room is. I mean that it is just not visible at all in a dark enough room regardless of screen brightness and/or screen content luma being zero or cranked to the max. (my laptop screen is small so it can't illuminate the keyboard enough to anything usable on its own without keyboard's own backlight coming into the mix) Do you mean to say that a keyboard's visibility can be affected by a screen's brightness and/or luma? The following response might or might apply based on the questions I just asked above.
Umm, can you please explain what you mean by these?
Correct.
No, if you lowered the screen brightness and the keyboard backlight automatically turned on as a result of that thanks to this feature then it does matter because then I will be able to see the keyboard without problem. [1]
Correct.
Same things as [1].
No.
No.
No. I almost always need the keyboard because my workflow for most everything is keyboard based. :) But answering your question, what will annoy is disco-lights-like (sorry, can't think of a better term XD) keyboard just because I was switching between bright and dark apps. Of course this only applies if we are also taking brightness adjustments done by wluma, i.e. not just the ones done by the user, as a trigger for this because wluma can adjust brightness in reaction to luma changes in "manual-mode". I am not considering this feature to be used with a real (or equivalent) als outside of manual-mode. But I know you surely are, so can you please repeat it to help me better understand your side of the argument? Thanks. (yes, your task is tougher, sorry 😅)
Yessss!
Yup, this is exactly what I need and can do, and I thought of it myself too, but I also thought this will be super simple to make part of wluma as well as I am already a user of wluma, while making wluma more feature rich. Sorry that I failed to mention this before, would have avoided all the confusion. So I guess the only question now is, will it be okay if this is a part of wluma or is it better as an external script? It is simple to do either way but having it in wluma increases this feature's visibility to other people compared to a random script that nobody is going to ever find. I guess it depends on whether there is a sizeable number of people who will want this if someone told to them that it can be easily done (e.g. with this script) or that it is available already in something like wluma. Basically something people don't know about yet but probably need kinda thing. |
|
In the thought experiment above, I meant of course that such feature does not exist yet in wluma, so you are teleported into a room, you are tasked to type some text, and in order to do that you must decide whether to enable keyboard backlight or not. That's why I still don't really get how a decision whether to enable or not keyboard backlight can be based on screen brightness, but only if that screen brightness was set by a human and not by a robot. It's like quantum mechanics, where the presence of the observer changes the outcome 😂 Maybe take the thought experiment another way: there are two rooms, same lighting, same screen contents, exactly the same screen brightness level, keyboard backlight is turned on in both rooms - in one room, keyboard backlight was activated "automatically" because screen brightness went automatically below a certain threshold, in another room it was activated because I manually reduced brightness to a certain threshold. As you step in and out of both rooms, since they look in every way identical (the only difference is how we got to this situation), how do you decide that it is wrong that keyboard is lighted in one of these two rooms, but not in another? Yes it's going to be a disco-lights-like behavior, but when configured correctly it's disco-light only because you objectively can clearly see keyboard in one case, and objectively cannot distinguish keys on keyboard because it's too dark in another case, so activating the keyboard light is useful, isn't it? |
Maybe this is the key to our confusion, it sounds like the screen backlight is actually not the decisive factor whether to enable keyboard backlight or not? It sounds more like a lucky coincidence that keyboard backlight has to be enabled or disabled when you change screen brightness, since as you say screen brightness does not really affect visibility of keyboard? |
|
The key difference between the two-room analogy and real usage is that you are not carrying the same laptop with same keyboard-backlight/screen-brightness from the previous room to the next in the analogy; the previous state of things does matter and flow of time is a factor i.e. this can't be "parallelized" in the way that is done in the analogy is what I kinda mean to say. I hope you somehow get I might be failing to express properly. The analogy is only complicating things in my opinion instead of being a useful reasoning device. Just think about it as you would experience it in real life without thinking about the hypothetical.
I disagree that it can be configured correctly, no matter what you do. Let's do it this way, you describe a config and implementation you think is perfect, and I will try to tell when it will have issues (maybe I will fail and at that point you win XD).
🤣 I think I just created yet another confusion. Allow me to try again. Quoting myself:
What I meant was, imagine without this feature and without wluma for that matter i.e. a normal laptop/desktop setup, in this setup, the keyboard keys will never be illuminated properly just from the photons emitted by a screen which fall on the keyboard and get reflected towards our eyes. current=$(brightnessctl -m | awk -F, '{print substr($4, 0, length($4)-1)}')
desired=$(( current + 1))
brightnessctl set -- "${desired}%"
desired_kbd=$(( desired <= 5 ? 1 : (desired <= 10 ? 2 : 0) ))
brightnessctl set -d kbd_backlight "$desired_kbd"Okay, before we discuss any further, if I am able to convince you that this script you just wrote is all that this feature is going to be and nothing more, will you be willing that it be part of wluma and not just an external script? |
|
To be honest, when combining all the considerations below, I don't think the invested effort, time and the added code complexity is worth integrating this directly in wluma:
You have a good point about discoverability, I think we can do something about that in any case - for example I recently opened wiki for anyone to edit, so one way could be to put useful stuff in there? |
|
I see. I will add it to the wiki then. Closing this as resolved. Thanks. |
|
Added to wiki. |
Please describe your feature request
Will it be appropriate to add a feature that whenever the display brightness is lowered, increase the keyboard brightness automatically? I always do this manually.
Having a real als, wluma will already do this automatically, but I don't have a real als and I can't use als.webcam or als.time either.
I don't want luma changes to be the trigger (in the case of als.none which is very limited and forced to only rely on luma) to change the keyboard brightness, I want it as a reaction to me changing the brightness manually. Will go along very nicely with #127.
Can be set like this for example:
Interpreted as:
The text was updated successfully, but these errors were encountered: