<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><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#c9">Comment # 9</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 <span class="vcard"><a class="email" href="mailto:daniel@fooishbar.org" title="Daniel Stone <daniel@fooishbar.org>"> <span class="fn">Daniel Stone</span></a>
</span></b>
        <pre>Sorry it's been a while; I've been working on other things, and this has been
slightly odd to me.

I think the core of the problem though is around modifier vs. virtual modifier
tracking. XKB has a concept of 'virtual modifiers' (of which scroll lock is
one), and 'real modifiers' (of which it isn't). There are a very limited number
of real modifiers, and most of them are in use; we can't add more without
breaking compatibility with X11.

The way XKB defines LEDs, you can only bind them to the state of real
modifiers. I _think_ we could extend xkbcommon to do that safely, without
breaking backwards compatibility with X11/xkbcomp, but it would need a change
in xkeyboard-config; specifically, changing the Scroll Lock LED to bind to the
ScrollLock vmod, not to modMapMods.

Adding scroll lock as a real modifier is a non-starter, as it does very
interesting things to client-side shortcut handling (read: totally breaks it).

I think this is wrong way to approach it though. Activating scroll lock can
cause visible effects, like, well, locking your scroll if you're in a terminal.
I think the best thing would be have a new udev/hwdb entry for keyboards which
use the scroll lock LED to drive the backlight, and then support this
separately through libinput or similar. Then we could explicitly drive it - and
have compositors do things like light it up on keypress - without having to
rely on weird xset hacks.

Also, I assume all these keyboards are external? The backlit laptop keyboards
I've had (Dell XPS, MacBook) just put backlight entries in sysfs.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>