The Scroll Lock LED lighting up when you switch to a secondary keyboard layout (and going dark again when you switch back) is not a hardware fault or a broken key. It is caused by the XKB option grp_led:scroll, which deliberately repurposes the Scroll Lock indicator as a "second layout active" signal. Removing this option from GNOME's per-user settings and from the system-wide keyboard configuration fixes the behavior on Wayland, where classic X11 tools like xmodmap and setxkbmap have no effect.
Why the LED changes when you switch layouts
Historically, X11 had no dedicated visual indicator for keyboard layout, so XKB offered a family of options named grp_led:* that bind the layout group to an existing keyboard LED. The variant grp_led:scroll makes the Scroll Lock LED light up whenever any layout other than the first one is active. If your layouts are, for example, US English and German, the LED turns on the moment you switch to German and turns off when you return to English — which looks exactly like Scroll Lock engaging and disengaging on its own.
Two things often confuse people experiencing this:
- Pressing the physical Scroll Lock key does nothing, because the LED is no longer controlled by the Scroll Lock modifier state at all — it is bound to the layout group.
- The option usually is not something you chose yourself. It is typically set during installation or by a distribution default, and GNOME imports the system-wide XKB options into your per-user settings the first time you log in.
Diagnosis: check where the option is set
On a GNOME Wayland session, check two places. First, the user-level GNOME settings:
gsettings get org.gnome.desktop.input-sources xkb-options
localectl status
If the gsettings output contains grp_led:scroll, that is what your session is using right now. The localectl output may also show X11 Options: grp_led:scroll, which reflects the system-wide configuration stored in /etc/default/keyboard and is what the GDM login screen uses.
It is worth confirming this is the real cause before changing anything: while the LED is lit, type into a terminal or a text editor. If keypad and arrow-key behavior is also misbehaving in applications like spreadsheets (because those apps react to the Scroll Lock state), the bound LED is genuinely telling applications Scroll Lock is on.
Fix: remove the option from GNOME's settings
GNOME offers no graphical interface for XKB options beyond choosing the Compose and AltGr keys, so you need to set the value directly. An empty list disables all extra XKB options:
gsettings set org.gnome.desktop.input-sources xkb-options "[]"
Verify with gsettings get org.gnome.desktop.input-sources xkb-options — it should now report an empty array. The change takes effect immediately; switching layouts should no longer touch the LED. No logout is required, though restarting the session is a clean way to confirm nothing is re-applying the option.
Note that removing grp_led:scroll does not restore the LED's normal Scroll Lock function in GNOME Wayland. GNOME does not wire the Scroll Lock modifier into the LED by default, so the key simply stays inert unless you reassign it to something else (for instance, as a Compose key via compose:sclk in the same options list).
Fix: also clean up the system-wide configuration
The per-user fix covers your session, but GDM (the login screen) reads /etc/default/keyboard, so the LED behavior will persist on the greeter until you edit that file as well. Set XKBOPTIONS to an empty value:
XKBMODEL="pc105"
XKBLAYOUT="us,de"
XKBVARIANT=","
XKBOPTIONS=""
You generally cannot fix this with localectl on Debian/Ubuntu: the D-Bus policy explicitly forbids localectl from modifying keyboard configuration there, so editing the file directly with an editor and sudo is the reliable route.
Why xmodmap and X11-era fixes do not help
Under Xorg, remapping the Scroll Lock key or LED with xmodmap or editing files under /usr/share/X11/xkb/symbols/ could change this behavior. On a Wayland session the compositor (GNOME's Mutter) manages keyboard state itself; those tools either fail or affect only legacy XWayland clients. The grp_led binding in particular is applied by the compositor from the XKB options in org.gnome.desktop.input-sources, which is why the only effective fix is removing the option at the source.
Prevention
- After a fresh install, review
localectl statusandgsettings get org.gnome.desktop.input-sources xkb-optionsif any LED behaves oddly after layout switches. - If you later want a layout indicator, prefer GNOME's built-in top-bar layout indicator rather than LED-based options.
- When adding your own XKB options (such as a Compose key position), include only the options you actually want in the list — anything inherited from the installer, like
grp_led:scroll, will ride along otherwise.
Frequently Asked Questions
Why does my Scroll Lock key not toggle anything at all?
Because the LED is currently bound to the layout group instead of the Scroll Lock modifier. Even after removing grp_led:scroll, GNOME on Wayland does not automatically restore the classic "press Scroll Lock to toggle scrolling state" behavior; the key will simply do nothing unless you assign it a function, such as making it a Compose key.
I edited the xkb symbols files and added a modifier map — why no change?
On Wayland, Mutter loads its own keyboard configuration from GNOME's settings; hand-editing /usr/share/X11/xkb/symbols/ files or adding modifier_map Mod3 lines does not reliably affect the session. Adjusting the xkb-options key in org.gnome.desktop.input-sources is the supported way.
Can I use localectl to clear the option system-wide?
Not on Debian/Ubuntu. The D-Bus policy there explicitly prohibits localectl from writing keyboard configuration, so edit /etc/default/keyboard directly with root privileges.
Does clearing xkb-options break my layout switching?
No. Layout selection and switching shortcuts are managed separately from XKB options. Clearing the list only removes extras like LED binding, Compose key placement, or custom key behavior that were explicitly listed.
The LED is fixed in my session but still wrong on the login screen. What now?
GDM reads /etc/default/keyboard, not your per-user GNOME settings. Make sure XKBOPTIONS is empty in that file, then log out or restart to see the change on the greeter.