Unexpected behavior from Shift and Numlock keys

[ilikefrogs]

The shift and numlock keys both function on their own, so I presume there’s no hardware issue. The expected behavior is that when I have numlock on but want to hit the home key I can hit shift+7 to go home, or if the numlock key is off then shift+7 types 7 instead of going home. Instead, I always get a number if numlock is on and the arrows if numlock is off, regardless of whether I’m pressing shift.

It would seem that the key binding available in system settings “Num Lock on: digits; Shift for arrows. Num Lock off: arrows (as in Windows)” will get me what I want, or close enough to suffice. Even after a reboot, however, this does not change any behavior. Weirdly, the option right below it, “Numeric keypad always enters digits (as in macOS)” works perfectly.

I’m on a Lenovo ThinkPad P15 Gen 2i, if that makes a difference here. I’m also realizing that some of the other rebinds fail, but only some. Ctrl position at bottom left, for instance, doesn’t override my Fn key with Ctrl, and “Swap Ctrl and Caps Lock” only turns the caps lock into ctrl, not the other way around. Not sure if this is relevant. Has anyone experienced this before?

[hcvv]

@ilikefrogs

system settings

That seems to point to some desktop, but none of them is mentioned.

When it is nevertheless all about the CLI, then I apologize for not understanding.

[susejunky]

@ilikefrogs

the key binding available in system settings

What desktop, what version?

[marel]

Welcome to the forum.

I had a look for KDE and this is I think what you want:

So this seems to be no the default at least in KDE, but you can change it.

My current keyboard does not have a Num Lock or a num key cluster, when I still had a full keyboard I did remap the Num Lock key to be the Compose Key.

[ilikefrogs]

I forgot to mention this was on KDE. That setting is the one I found, and the one that for whatever reason does not work.

[marel]

Would be good if somebody else running KDE and having a keyboard with a num key cluster could try this KDE setting and report if it is working.

For the problem itself, I think you are better off opening a topic on the KDE Discuss.

[iainh]

@marel

Would be good if somebody else running KDE and having a keyboard with a num key cluster could try this KDE setting and report if it is working.

I tried it out and I have the same experience as OP. I tried using either Shift keys but it still typed the number rather than doing the action. I tried toggling other settings as well, such as “Default numeric keypad keys”, and specifying a “Layout of numeric keypad” but none of them allowed the shift+num to function.

An incidental thing I noticed is that when a change is made in any of the key bindings sections, a “Reset” button shows for that section. For any other section, the reset button will untick the options and go back to default; this does NOT happen for the Compatibility options section.

[ilikefrogs]

I’ll reach out to them, then. I’m glad this isn’t just me.

[Wismill]

This an xkeyboard-config bug introduced in version 2.48.

It seems that there are 2 incompatible expectations from the users:

1. Users that expect Shift to temporally cancel NumLock, much like Shift cancels CapsLock.
2. Users that expect Shift to not interfere at all with keypad, so that they can use Shift+keypad arrows (etc.) as they use Shift + non-keypad arrows.

As one of the maintainers of xkeyboard-config, I hate breaking workflows but we lack data to decide what keypad behavior should be the default.

For the record, the canonical behavior defined in the XKB protocol is:

• If Shift and the “NumLock” modifier are both set, the default KEYPAD type yields level one.
• If either Shift or the “NumLock” modifier alone are set, it yields level two.
• If neither Shift nor the “NumLock” modifier are set, it yields level one.

However, this is a 20-year old document, and we did receive bug reports that requested to change the default behavior.

So I kindly invite you to join the discussion. Alternatively, I will try to follow the discussion here, but do note that I found it purely by chance and I am not much active here.

[ilikefrogs]

I think I understand what you’re saying. I’m glad you happened across this, since while I had posted about this on the KDE forum, I didn’t know this other conversation existed.

I suppose my two cents are that I don’t really care what the default behavior is as long as the customization options work. For whatever it’s worth, my assumption was that shift should invert whatever behavior the number pad is “locked” onto, but that’s only because I’m mapping the caps lock behavior onto numlock, no other reason.

But my issue has always been that the configuration option exists but isn’t working, not that the default isn’t what I’d like it to be.

[Wismill]

Fix is on the way and should be included in the imminent 2.49 release.

Note that this is rather a mitigation than restoring the previous behavior: it requires that the users select manually the numpad:pc option.

[Wismill]

Until xkeyboard-config 2.49 is published and deployed, one can fix this locally by creating ~/.config/xkb/types/numpad with the following content:

// NumLock enables digits; Shift cancels NumLock but never enables digits
//
//     | NumLock | Shift | Level | Description            |
//     | ------- | ----- | ----- | ---------------------- |
//     | Off     | Off   | 1     | Navigation and editing |
//     | Off     | On    | 1     | Navigation and editing |
//     | On      | Off   | 2     | Digits                 |
//     | On      | On    | 1     | Navigation and editing |

// On Windows keypads, Shift cancels NumLock but Shift alone does not enable digits.
partial xkb_types "microsoft" {
    virtual_modifiers  NumLock, LevelThree;

    type "KEYPAD" {
	modifiers = Shift + NumLock;
	map[None] = Level1;
	map[Shift] = Level1;
	preserve[Shift] = Shift;
	map[NumLock] = Level2;
	map[Shift+NumLock] = Level1;
	level_name[Level1] = "Base";
	level_name[Level2] = "Number";
    };

    // A four-level keypad variant. Shift alone does not enable digits,
    // but Shift cancels NumLock.
    type "FOUR_LEVEL_KEYPAD" {
	modifiers = Shift + NumLock + LevelThree;
	map[None] = Level1;
	map[Shift] = Level1;
	preserve[Shift] = Shift;
	map[NumLock] = Level2;
	map[LevelThree] = Level3;
	map[Shift+NumLock] = Level1;
	map[Shift+LevelThree] = Level4;
	map[NumLock+LevelThree] = Level4;
	map[Shift+NumLock+LevelThree] = Level3;
	level_name[Level1] = "Base";
	level_name[Level2] = "NumLock";
	level_name[Level3] = "AltGr";
	level_name[Level4] = "Shift/NumLock AltGr";
    };

    // A four-level keypad variant. The first two levels are controlled by NumLock.
    // LevelThree overrides this mode, with two additional shifted levels.
    type "FOUR_LEVEL_MIXED_KEYPAD" {
	modifiers = Shift + NumLock + LevelThree;
	map[None] = Level1;
	map[Shift] = Level1;
	preserve[Shift] = Shift;
	map[NumLock] = Level2;
	map[LevelThree] = Level3;
	map[Shift+NumLock] = Level1;
	map[Shift+LevelThree] = Level4;
	map[NumLock+LevelThree] = Level3;
	map[Shift+NumLock+LevelThree] = Level4;
	level_name[Level1] = "Base";
	level_name[Level2] = "NumLock";
	level_name[Level3] = "AltGr";
	level_name[Level4] = "Shift AltGr";
    };
};

[ilikefrogs]

I created that file, and the behavior has changed, but not entirely for the better. Previously, Numlock locked the numbers no matter what. Now shift+number = shift+arrow.

So numlock-on gives “1” = 1, “Shift+1” = Shift+End, when if I’m reading the file correctly, it should be “Shift+1” = End.