Fresh install startup errors "Could not convert keysym to keycode"

[gabrielmontagne]

On fresh install on Debian -- using the bundled version, 4.0.2+dfsg-5, I get the following error on startup,

- >> Mod4+Shift+Caps_Lock: Could not convert keysym to keycode.
- >> Stack trace:
    - 0 [C]: in 'do_defbindings'
    - 1 ioncore_bindings.lua:199: in 'defbindings'
    - 2 /etc/X11/notion/cfg_bindings.lua:226
        - [Skipping unnamed C functions.]
    - 5 [C]: in 'dopath'
    - 6 /etc/X11/notion/cfg_notioncore.lua:1
        - [Skipping unnamed C functions.]
    - 9 [C]: in 'dopath'
    - 10 /etc/X11/notion/cfg_defaults.lua:19
        - [Skipping unnamed C functions.]
    - 13 [C]: in 'dopath'
    - 14 /etc/X11/notion/cfg_notion.lua:125
        - [Skipping unnamed C functions.]

I know it could be a packaging problem, but does this ring a bell? If it's not a bug, is there a work-around for it? On other machines with notion 3, I have zero problems.

[raboof]

Hmm, it doesn't look like a packaging problem, but I'm not sure what's going on /cc @dkogan

[dkogan]

The keysym/keycode table can be printed with xmodmap -pk. gabrielmontagne: I would guess you have something unexpected in your keyboard map. You're probably setting something it doesn't like in your X configuration somewhere? This isn't your fault, and notion should do better, but it's not entirely clear what's happening, yet.

raboof: two things could be improved with our diagnostics here:

1. We should print what keysym specifically we're looking for. This is an integer. If we had that, the user could xmodmap -pk to check if the error makes sense
2. Can we print out the C backtrace too? Or maybe dump a core also? We could get better diagnostics from those.

Are either of those easy to implement?

[raboof]

We should print what keysym specifically we're looking for. This is an integer. If we had that, the user could xmodmap -pk to check if the error makes sense

Agreed. That looks pretty simple (https://github.com/raboof/notion/blob/master/ioncore/conf-bindings.c#L100), do either of you want to give it a go?

Can we print out the C backtrace too? Or maybe dump a core also? We could get better diagnostics from those.

I agree that would be great, tracked in #104, not sure how hard it would be.

[dkogan]

I'm looking at ioncore_parse_keybut():

notion/ioncore/conf-bindings.c

Line 61 in e98a4df

bool ioncore_parse_keybut(const char *str, uint *mod_ret, uint *ksb_ret,

It looks at the binding (Mod4+Shift+Caps_Lock in this case), splits it on +, converts the string to a keysym with XStringToKeysym(), and then converts that keysym to a keycode by calling XKeysymToKeycode(). This last part fails for one of the 3 components of the binding (it'd be nice if the error message said which one). A random guess: the user has redefined Caps_Lock to function as a control, or something, and did this in a way that breaks the keysym/keycode conversion.

I haven't looked to see what notion3 does differently here.

gabrielmontagne: can you tells us about your custom keyboard config?

[raboof]

I haven't looked to see what notion3 does differently here.

Ah, I don't think they default keybindings in notion3 bound anything to capslock at all, while in notion4 they do

[gabrielmontagne]

Might be worth mentioning -- I don't know why I didn't specify it before -- both Debian and Notion are both freshly installed. I haven't changed any configuration of anything yet. So if you install the distro, install Notion and try to start it, you get the error.

[gabrielmontagne]

gabrielmontagne: can you tells us about your custom keyboard config?

Ah, no, but yes, you are totally right @dkogan, I do have exactly that, Caps_Lock working as a Ctrl
On, /etc/default/keyboard I have XKBOPTIONS="ctrl:nocaps,terminate:ctrl_alt_bksp"

Sorry, I should've mentioned that!

[dkogan]

Cool. So this is 100% clear then. notion4 has some binding with Caps_Lock in it that notion3 doesn't have. With your configuration, notion4 can't find the Caps_Lock key on your keyboard, so it barfs.

gabrielmontagne: configuring your notion to not have bindings that use this key whould fix it. Search for Caps_Lock in /etc/X11/notion/cfg_bindings.lua, and you should see the bindings that need changing. Or simply delete the two relevant bindings from that file.

raboof: remapping Caps_Lock is common-enough that we maybe shouldn't have any default bindings that use this key. Strong feelings about removing or changing those by default?

Also, unsettable bindings maybe should produce a warning instead of causing notion to not run at all. It'd be awesome if there was an error message that stated what binding failed, and what config file it came from.

Thanks!

[gabrielmontagne]

It worked perfectly! Thanks so much! I've been using this WM since before the not- times. I love it so much. Thanks for keeping it fresh and youthful 🤟

[knixeur]

I changed those caps lock bindings before using them and accidentally avoided this issue. They might suit you

kpress(ALTMETA.."S", "WFrame.switch_next(_)"),
...
kpress(ALTMETA.."A", "WFrame.switch_prev(_)"),

[raboof]

raboof: remapping Caps_Lock is common-enough that we maybe shouldn't have any default bindings that use this key. Strong feelings about removing or changing those by default?

I think having that one is really central to the consistency of the default keybindings, so I'd much prefer to keep it.

I agree remapping capslock is common enough that we should handle it gracefully, though, so...

unsettable bindings maybe should produce a warning instead of causing notion to not run at all. It'd be awesome if there was an error message that stated what binding failed, and what config file it came from.

Yeah, maybe it should just be a warning in the logs, not even a popup?

[dkogan]

Yeah, maybe it should just be a warning in the logs, not even a popup?

Maybe...

For a default, a warning in the logs would be ok. But for something in a user config, there should be a popup: the user explicitly asked notion to do something that it ended up not doing. So it should loudly communicate to the user that their intent was ignored.

I'm assuming it's not really easy to tell whether something came from a default config or not, right? So we should just pick one of the behaviors (log message or popup). Maybe a popup would be the better of the two? If it told the user what to do to silence the warning?

[knixeur]

I'd rather prefer a popup as it really grabs your attention that the binding will not work.

[wilhelmy]

JFR, since my keyboard doesn't have a Windows key (I know, rare these days) I use Caps as META (remapped to Mod4).

[nunotexbsd]

On FreeBSD with 4.0.3 version I get this on start:

Notion startup error log:
>> Mod4+grave: Could not convert keysym to keycode.
>> Mod4+Shift+asciitilde: Could not convert keysym to keycode.
>> Stack trace:
   0 [C]: in 'do_defbindings'
   1 ioncore_bindings.lua:199: in 'defbindings'
   2 /usr/local/etc/notion/cfg_bindings.lua:22
     [Skipping unnamed C functions.]
   5 [C]: in 'dopath'
   6 /usr/local/etc/notion/cfg_notioncore.lua:1
     [Skipping unnamed C functions.]
   9 [C]: in 'dopath'
   10 /usr/local/etc/notion/cfg_defaults.lua:19
     [Skipping unnamed C functions.]
   13 [C]: in 'dopath'
   14 /usr/local/etc/notion/cfg_notion.lua:121
     [Skipping unnamed C functions.]

I can't find any change to keymaps as I remember.