<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - scrolllock, the only key that can switch keyboard back light can't be activated" href="https://bugs.freedesktop.org/show_bug.cgi?id=104050#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - scrolllock, the only key that can switch keyboard back light can't be activated" href="https://bugs.freedesktop.org/show_bug.cgi?id=104050">bug 104050</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>We had a fairly long discussion about the keyboards whose backlight is actually the ScrollLock led on #wayland IRC. People were surprised such things even exist. I would guess that such keyboards might be the reason why the ScrollLock key no longer toggles the ScrollLock led, I understood that it is simply missing from keymaps. For me ScrollLock does not toggle its led even on Xorg, but it does in VT where it also stops the terminal output. Since ScrollLock key has a defined behaviour and it only as a side-effect toggled the led, I presume the disconnect is intentional. It was said that most keyboards have explicit sysfs or other controls for the backlight. A possible solution would be to define a new hwdb tag, e.g. SCROLL_LOCK_IS_BACKLIGHT, which would tell display servers that the ScrollLock led is not a status led but a backlight. Then they would be able to control it on purpose as part of their normal keyboard backlight controls.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>