Enhance Keyboard Backlight Control: Toggle & 0% Brightness

Hey guys, let's dive into a couple of neat feature requests that would seriously level up how we control our keyboard backlights. I've been tinkering with my keyboard brightness in niri using dms, and I think these additions to the brightness IPC module would make things a whole lot smoother. Let's break down the current situation and the proposed improvements. We are going to explore why these features are important, how they would streamline our workflow, and the potential benefits for everyone using similar setups. The goal here is to get you up to speed with the discussion and why it matters to you. Plus, we'll look at the current workarounds and why they are not the best solutions.

The Missing toggle Action for Seamless Control

Okay, so the first thing I've been missing is a toggle action. Right now, if I want to turn my keyboard backlight on or off using a dedicated key (like XF86KbdLightOnOff), I'm stuck using a workaround. This involves a spawn-sh command that checks the current brightness level before deciding whether to turn the backlight on or off. It's functional, sure, but it's not exactly elegant. Let me show you what I mean. I'm currently using something like this:

spawn-sh "[ $(brightnessctl -d 'rgb:kbd_backlight' g) -gt 0 ] && brightnessctl -d 'rgb:kbd_backlight' s 0 || brightnessctl -d 'rgb:kbd_backlight' s 100"

This command does the following:

1. Gets the current brightness: brightnessctl -d 'rgb:kbd_backlight' g gets the current brightness level of the keyboard backlight.
2. Checks if brightness is greater than 0: [ $(...) -gt 0 ] checks if the retrieved value is greater than 0.
3. Toggles the brightness:
   • If the brightness is greater than 0, it sets the brightness to 0: brightnessctl -d 'rgb:kbd_backlight' s 0.
   • Otherwise (if the brightness is 0), it sets the brightness to 100: brightnessctl -d 'rgb:kbd_backlight' s 100.

See? It gets the job done, but it's a bit clunky. A native toggle action would be so much cleaner and more intuitive. Imagine this:

spawn "dms" "ipc" "call" "brightness" "toggle" "rgb:kbd_backlight"

This single line would do the same thing! It's concise, easy to read, and much less prone to errors. Using toggle would simplify the configuration and make it easier to manage keyboard backlight settings within dms. This is a win for anyone who values a clean and efficient workflow. I think a lot of people would appreciate having a simple toggle command, it would be a game-changer for anyone who customizes their keyboard backlight. It's about making things easier for the end-user.

Reaching Zero: Allowing decrement to Turn Off the Backlight

Now, let's talk about the decrement action. Currently, it stops at 1%. This is fine for monitors, as it's a safety feature to prevent the screen from going completely dark, but for a keyboard backlight, it's not ideal. I want to be able to turn off my keyboard backlight completely using the brightness-down key. The current behavior prevents this, and it's a bit annoying. The inability to reach 0% means that I can't completely disable the backlight using the brightness controls. This might sound like a small issue, but it impacts the user experience. I mean, think about it: if you want to turn off the backlight, you'd expect the brightness-down key to do the job. You'd need a separate command or keybind to turn it off completely. It's an inconsistency that breaks the natural flow. Plus, some people prefer to completely disable the backlight to save a bit of battery life or simply because they don't need it. The current setup doesn't allow for this, creating an incomplete user experience. This limitation forces users to resort to workarounds, adding unnecessary complexity. And, in the end, it's the little things that create a great user experience.

Alternative Suggestion: Introducing a kbdlight Module

If the 1% minimum is a safety feature and can't be changed, here's another idea. We could introduce a separate kbdlight module specifically for keyboard backlight control. This module could have its own toggle action, and the decrement action could reach 0%. This would maintain the safety features for monitors while providing complete control over the keyboard backlight. Here’s how that could look:

spawn "dms" "ipc" "call" "kbdlight" "toggle"

This design allows for greater flexibility. A dedicated kbdlight module could offer other keyboard-specific features in the future, such as controlling different lighting modes or effects. By separating the keyboard backlight controls from the general brightness controls, the design would also keep the feature set cleaner and more focused. This would also prevent potential conflicts with monitor brightness controls and provide users with a better-organized interface. All these considerations contribute to a smoother, more user-friendly experience.

Why These Features Matter

So, why am I making such a big deal out of these seemingly small changes? Because they collectively improve the user experience. They make the system more intuitive, easier to configure, and more versatile. It's about empowering users to customize their setups exactly the way they want. It is essential to give users complete control over their hardware. And, honestly, these changes are not that hard to implement. They would provide significant value to a lot of users and improve the overall usability of the system. We should strive to create a system that caters to both power users and casual users. This approach supports a wider range of hardware configurations and user preferences. The suggested features are very useful in different situations. It helps to be more productive and improves your overall experience. The goal is to make the system as user-friendly as possible, making the experience more comfortable.

Conclusion: A Call for Cleaner Control

In short, adding a toggle action and allowing decrement to reach 0% (or creating a separate kbdlight module) would significantly improve the keyboard backlight control experience. These changes streamline the configuration process, eliminate the need for clunky workarounds, and offer users greater flexibility. The proposed features are not just nice-to-haves; they're essential for a smooth, intuitive, and customizable user experience. It's all about making life easier for those of us who appreciate the details and like to tinker with our setups. I hope this sparks some discussion and leads to some positive changes. Thanks for listening, guys!