Implement the ability to change the backlight mode#648
Implement the ability to change the backlight mode#648Fede2782 wants to merge 1 commit intoBeardOverflow:mainfrom
Conversation
Fede2782
commented
Mar 17, 2026
Fede2782
commented
- The config had values but they were unused up to this point
* The config had values but they were unused up to this point
|
Does keyboard backlight being reliably triggered at all? I'm assuming it triggers only by keys, not by touchpad? I'm comparing this with how this made by Asus |
here on modern 15 h ai c1mg-096, using touchpad does trigger backlight as well. i set this as WIP cause i'd like someone without the backlight to test it as well. |
|
That's really nice, because my other laptops backlight from some chinese brand does not triggered by touchpad |
|
Does toggling this setting affects backlight? Like idea of making KB glow when mice is moved or screen is touched |
This setting only changes the mode. If backlight is on or off it's decided in the brightness attribute. This attribute might be managed by the DE so that keyboard could be triggered using external inputs such as mouse or keyboard. When brightness attribute is greater than zero then the brightness mode is followed. If it's "timeout" then every time a key or touchpad is used it will stay on for 10s. If it's "always" then it will always stay on until brightness is set to 0. |
|
You right but system does not know real state of backlight. You can read it, but DE will not update state without a trigger. Is BL level is 0 when state is timeout and blank? |
Once this module is installed everything knows and can control the backlight. KDE, for example, recognizes it and allows control of brightness intensity directly via its control panel. Therefore you could write an app to trigger the backlight anytime with any trigger you want since it is available in sysfs for apps. BL level doesn't change if mode is timeout but the timeout has reached 10s and powered off. It remains untouched cause the keyboard backlight is already on but it has been temporarily disabled because timeout mode is set |
|
I mean that KDE and other DEs can't know that you changed brightness with keyboard key |
They could tho. Once you press the keyboard key the EC value gets updated and therefore the sysfs attribute does as well when being read. So using a watcher they could detect those changes. |
|
Gnome have no watcher built in |
| struct msi_ec_kbd_bl_conf { | ||
| int bl_mode_address; | ||
| int bl_modes[2]; | ||
| struct msi_ec_mode bl_modes[5]; |
There was a problem hiding this comment.
Why 5 not 3?
Because states are "always", "timeout" and NULL
There was a problem hiding this comment.
Why 5 not 3?
Because states are "always", "timeout" and NULL
I have aligned with other modes definition. Also this allows better handling in case new modes are added in the future. This can be reduced to 3 if you think is necessary.
I never said it has. I am saying that once this module is installed there are a lot of new possibilities and DEs could take advantage of them in every way you could possibly think of. |
|
If you know how to tell DE that brightness is changed, can you say how to do this? At leas on KDE if you know. This not related to this PR and to this repo at all. But there a design possibility to receive events about brightness and other soft keys through WMI. But this is related to |
I haven't thought of a precise solution but, as I stated in previous replies, a possible solution could be implementing a watcher which periodically checks the brightness value exported by this driver and does actions depending on that. I didn't consider getting events WMI, could be possible that as well |
|
I think this events are standard because DE can rotate screen based on gyroscope for example, so we need to just tell DE that something happened to update its internal state |
2 participants
