Keyboard Backlight/LEDs being overwritten by hyprland

[P3tracore]

Similar to issue #7344

hyprland.json

I have a cheap Chinese keyboard that has rgb functionality, meant to be turned on with the scroll lock key.

I have tested and it works in the tty, however, when starting hyprland and:

1. Running brightnessctl -d input7::scrolllock set 1
2. Running setleds +scroll or just setleds (Gives
3. Manually editing the file in /sys/class/input/input7::scrolllock/brightness
   The bug is that the keyboard LEDs flicker very briefly and then turn off, or turn on until any key is pressed. It appears to me that something hyprland related is overwriting the value in this file (confirmed by the issue I linked above)

According to the issue linked above:
"there is no mechanism to forcefully lock LED states in hyprland"
What is meant by "forcefully lock" the LED states? Why would hyprland touch the LED states in the first place? In my mind this means something you guys have written is intentionally iterating and editing the values in that file each time a key is pressed, as opposed to just leaving it alone. And in that case, where is the option to control when hyprland overwrites this file so that I can yk, turn my LEDs on and off at will?

"hyprland takes full control of your LEDs..."
Ok so, for whatever reason hyprland "takes full control" of my LEDs, is there no hyprland configuration option, or hyprland interface with which I can turn them off myself at will? I cannot find any documentation saying so, and if not then simply why? What's the point in taking control over something so that users can't configure it when you could have just left it alone in the first place?

"...if scroll lock is not enabled in hyprland, the LED will be disabled next time hyprland updates the LED states."
Again, why is hyprland updating the LED states at all? Additionally I can't seem to find any documentation on how to "enable the scroll lock key". If by that you mean to bind the scroll lock key in the configuration file to some command that enables the LEDs, that also does not keep the LEDs on, neither does enabling the usual functionality of scroll_button_lock = true in the input configuration either. Also kb_options = grp_led:scroll doesn't do anything though I'm not sure what it's purpose is actually, just though it was worth mentioning.

[vaxerski]

Why would hyprland touch the LED states in the first place?

because you have a caps lock.

I cannot find any documentation saying so, and if not then simply why? What's the point in taking control over something so that users can't configure it when you could have just left it alone in the first place?

because nobody implemented it

Again, why is hyprland updating the LED states at all?

because caps lock exists

[P3tracore]

Why would simply having a caps lock key cause hyprland to affect LED states?

[vaxerski]

because it's an LED. Look down on your keyboard.

[P3tracore]

That does not answer the question at all, why is there code in hyprland that changes the state of the LEDs on the keyboard in any way whatsoever? Isn't that some other fundamental system process's responsibility?

And if hyprland, for whatever reason must affect the state of the LEDs on the keyboard, why does it affect the state of the scrolllock LED on every keypress and not only when the scrollock key is pressed?

[vaxerski]

That does not answer the question at all, why is there code in hyprland that changes the state of the LEDs on the keyboard in any way whatsoever? Isn't that some other fundamental system process's responsibility?

No, it's the job of the display server.

And if hyprland, for whatever reason must affect the state of the LEDs on the keyboard, why does it affect the state of the scrolllock LED on every keypress and not only when the scrollock key is pressed?

Because every keypress could alter the caps lock state and we just update the LEDs. It's a bitfield of all LEDs in a uint32_t.