setxkbmap option `numpad:mac` breaks xdotool since v4.20251130.1

[dorsiflexion]

Hi, since v4.20251130.1, setting setxkbmap de -option 'numpad:mac' leads to xdotool throwing an error on every command (not just type). Prior to v4.20251130.1, everything worked fine.

❯ xdotool type a
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  17 (X_GetAtomName)
  Atom id in failed request:  0x0
  Serial number of failed request:  28
  Current serial number in output stream:  28

• Arch Linux (Linux or Linux-hardened doesn't matter)
• X11, no wayland
• DISPLAY = :0

Git bisect leads to this commit: 15fc2fc

[johannww]

i am having the same issue. downgraded to xdotool version 3.20211022.1 and everything works.

[jordansissel]

Confirmed this is a bug. I'm not exactly sure what the solution is, but I found the problem -- this is a unique edge case in xkb's default keymaps specific to numpad:mac.

I can reproduce quickly on Xwayland, and the -option 'numpad:mac' seems to be the trigger. I'm on a us layout and can reproduce:

# default keymap
xdotool sleep 0.1 ## works

# set us keymap (should change nothing)
% setxkbmap us
xdotool sleep 0.1 ## works

# set us keymap w/ numpad option:
% setxkbmap us -option 'numpad:mac'
xdotool sleep 0.1 ## fails
X Error of failed request:  BadAtom (invalid Atom parameter)

Setting back to us keymap in the same session still leaves xdotool failing:

% setxkbmap us
% xdotool sleep 0.1 ## fails
X Error of failed request:  BadAtom (invalid Atom parameter)

---

Some notes from trying to figure this out

Checking xdo.c internally

The failure seems to be in a debug/tracing call that invokes XGetAtomName but the atom queried is null, for some reason. I'm not sure if this is a bug in xdotool or somewhere else

xdotool/xdo.c

Line 1440 in d37c161

group, XGetAtomName(dpy, key_type->level_names[li]),

For code details, I can reproduce this and it fails while looking up keycode 129 level 0, XGetAtomName(dpy, key_type->level_name[li]) --- key_type->level_name[0] is 0x0 and I dont' think it should be null, some debugging:

[group 0, level Control[2]] Symbol(Break) = keycode 127 with mask:Control, real_mods:4, vmods:<none>
xGetAtom for 128 and level 0 level name 91
[group 0, level Any[1]] Symbol(XF86LaunchA) = keycode 128 with mask:<none>, real_mods:0, vmods:<none>
xGetAtom for 129 and level 0 level name 0
X Error of failed request:  BadAtom (invalid Atom parameter)

For keycode 129, key_type->num_levels is 2, but key_type->level_names[0] is null?

If I dig more, here's what keycode 129's level names looks like:

BUG? Level name 0 is null for keycode 129 group 0
  -> [level 0] level_name 0
  -> [level 1] level_name 98

I'm suspicious that this happens between code 128/129 and am not sure if libxdo is scanning the keymap correctly. the level_name should not be a null pointer (0) if the map is correct and if xdo is reading it correctly.

Checking the keymap itself

If I diff the keymap from us and us w/ numpad:mac, I find this to be interesting:

type "KEYPAD" {
-               modifiers= Shift+NumLock;
-               map[NumLock]= 2;
-               level_name[1]= "Base";
+               modifiers= none;
+               map[none]= 2;
                level_name[2]= "Number";
        };

When numpad:mac option is used, there is no entry for "level_name[1]" at all for KEYPAD key types, instead it appears to say declare that "no modifiers maps to level 2" and omits a level_name[1] definition. The lack of a level_name[1] entry shows that libxdo may need to be taught how to understand this map[None] = Level2 configuration:

% build/xkbcli-dump-keymap-x11 | sed -ne '/type "KEYPAD"/,/};/p'
        type "KEYPAD" {
                modifiers= none;
                map[none]= 2;
                level_name[2]= "Number";
        };

Looking for other examples, everything I found sets map[None] = Level1 except for this specific case:

% grep 'map\[None' /usr/share/X11/xkb/types/* | grep -v ' = Level1'
/usr/share/X11/xkb/types/numpad:        map[None] = Level2;

Interesting edge case!

[dorsiflexion]

Just a quick note: setxkbmap us doesn't reset the options, so numpad:mac stays activated. You need to do setxkbmap us -option '' to deactivate it.

[jordansissel]

@dorsiflexion ahh that’s helpful thanks! Keeps me from having to restart X each time I test 😅

[jordansissel]

Possible fix for this: #510