xkb_numlock / xkb_capslock for a specific keyboard has no effect with default ("smart") keyboard grouping

Description: Consider:

• You want NumLock enabled by default (e.g. for your laptop keyboard).
• You want NumLock disabled for a specific keyboard (e.g. a TKL keyboard where NumLock masks some keys).

The following configuration:

input type:keyboard xkb_numlock enabled
input 9610:1:MY_USB_KEYBOARD xkb_numlock disabled

Has no effect, i.e. NumLock still gets enabled by default for MY_USB_KEYBOARD.

Cause: The problem is that, under the default "smart" keyboard grouping, keyboards with different xkb_numlock still end up under the same keyboard group, consistent with the documentation:

smart will group the keyboards in the seat by their keymap and repeat info

So in the example above, the xkb_numlock enabled rule enables NumLock for the laptop keyboard, then it gets synced into MY_USB_KEYBOARD, so the xkb_numlock disabled rule has no practical effect.

However for users this is counterintuitive, and why this behavior happens is not easy to find.

Suggestions:

• Keyboards with different xkb_numlock and xkb_capslock should be put in different groups (Personal patch).
  • Similarly to how today, keyboards with a different repeat_rate are put in different groups.
• Alternatively, grouping by physical device (#5218) would also solve this issue.

Appendix - Workarounds:

1. Add input 9610:1:MY_USB_KEYBOARD xkb_options "numpad:pc": Set some keymap option, so the "smart" keyboard grouping puts this device in a different group.
2. Disable keyboard grouping with seat * keyboard_grouping none : May break keyboards that present themselves as multiple devices.