Bug 104050

> It is impossible to activate the scroll lock key on wayland. This key is the only one that can switch the light of any keyboard with backlight.

I haven't seen the same behaviour as you, but then again I also have keyboards which light up without using scroll lock.

Did this previously work for you under X11?

> PS: what idiot decided that this key shall never be used in linux?

I encourage you to read the link at the bottom of every page, being the Code of Conduct: https://www.freedesktop.org/wiki/CodeOfConduct/

Probably you'll find that whatever you're seeing is a bug rather than a deliberate design choice. Either way, the bug is likely to be in Mutter (the base of GNOME Shell), so you might want to take the issue up with them, ideally without calling them idiots.

On X, it was possible to reactivate the key with the following command: xmodmap -e 'add mod3 = Scroll_Lock'

About the PS, the last comment was second degree. All my apologies if it wasn't taken this way. Sorry about this. Really.

Anyway, I have no doubt that there is an explanation. But as a matter of a fact, from a pure end user point of view, a key that exists and works on every non apple machine (95%) and that just doesn't work on another system is clearly a bug. Even if the technical explanation or strategic choice makes sense. As a developer, we laugh a ourselves saying "it's not a bug, it's a feature". We are exactly in this situation. The fact a key of the keyboard is purely ignored by the system can't decently be justified to a basic end user by saying that it is a feature.
To conclude, as a matter of a fact, all users with a backlight keyboard are wondering the same kind of question: "why this key that works on every systems is ignored on linux by default? and why wayland that is now the default ubuntu windows manager simply decided that this key shouldn't even exist?".
Since I'm killing my eyes to work from home during my evenings, I'm wondering this question as well.

I'm not trying to justify this as a feature. My point is: no-one sat down one day and made a conscious decision to make scroll lock not work.

I would still like to try to find out what is happening here. Does binding Scroll Lock to Mod3 simply make the scroll lock key drive the scroll lock LED? Does that LED somehow control your entire keyboard backlight? What model is your keyboard?

The xmodmap thing is a workaround which shouldn't be necessary. By default, in both X11 and Wayland, pressing the scroll lock key should light the scroll lock LED.

(I am typing this on a Dell laptop where the backlight has nothing at all to do with Scroll Lock, and works well under Wayland. As you observe, the same was true of Apple keyboards.)

Daniel, I understand your concern, don't worry. I'm not judging. As a developer I know that sometimes, we have to make some choices or to give an appropriate priority on incidents/bugs. :-)

let's come back to our issue.
Right now, I'm talking about a separate keyboard, not about the keyboard of a laptop that has its own special key to light the backlight. Separate keyboards usually use the scroll lock key to switch their backlight. I believe that it is done this way so that the OS, when it hibernates, can send the signal to the keyboard that it must switch off. The only way to permit this is to give to the OS the control on the effect of the key scroll lock. If the OS ignores this key for some reason, the backlight and even the little led will never switch. 

Before, I was on ubuntu 16.04 (that was on X as I suppose you know). The scroll lock key was simply ignored because it wasn't mapped by the system. Therefore, the key was like it didn't exist. Meaning, a stroke on it had no effect what so ever. No led was switched, the backlight wasn't switched either... nothing. I knew it was a known issue because as I mentioned to you, lot of backlight keyboard owners wonder why this key is disabled. On X, as I said, the command xmodmap -e 'add mod3 = Scroll_Lock' permited to have the scroll lock key working like a charm... like on... windows. To be more clear, from the moment I executed this command, if I pressed on the key, the led was switched, and the backlight as well. It was a bit annoying to type the command every time I rebooted, or to setup the system not to have to type this command anymore, but I dealt with it.

Since I reinstalled my machine with ubuntu 17.10 (that is on wayland as you know as well), this command has no effect of course. Therefore, I didn't find anyway so far to have the backlight of my keyboard working.

I hope that it clarifies the issue. Thanks for the patience from every backlight keyboard owners! :-)

I just want to add a "me too" on this; I use Fedora and since Fedora 26 I have been unable to use my keyboard's backlight unless I don't use Wayland, then everything works as advised. I've seen the issue posted on a big number of forums but nobody seems to have a solution as of today. This works for me, outside of Wayland:

alias scroll='xset led named "Scroll Lock"'

Anyway, will continue lurking hoping that some day this issue is solved; this is a show stopper for anybody working with an external keyboard during the night, even if I don't need to see the keys I type, sometimes I need to find a particular key and this is just not working.

Actually, the key press is indeed detected (just checked). But I believe a signal must be sent back to the keyboard for the actual activation of the led. I suppose that backlight keyboards interpret the signal back as a signal to switch the back light with the led.

and indeed, I repeat, this issue is a real handicap for owner of backlight keyboard. I understand it can be a "no go" reason for many of them.

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.

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.

Peter, handballing to you in case you have any bright (groan) ideas.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/libinput/libinput/issues/11.