qmk/qmk_firmware

Proper customization at the keymap level is impossible due to _user() functions either being handled incorrectly or not returning a bool.

Open

#8,246 建立於 2020年2月25日

在 GitHub 查看
 (7 留言) (0 反應) (0 負責人)C (43,867 fork)batch import
discussiondocumentationhelp wantedquestion

倉庫指標

Star
 (20,368 star)
PR 合併指標
 (平均合併 20天 9小時) (30 天內合併 27 個 PR)

描述

Incorrect handling of bool _user() functions

This is the advice given when writing a custom _kb() function, straight from the docs:

wiki

For process_record_kb() for example, that description would be roughly equal to this code structure:

bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
    if (!process_record_user(keycode, record)) {
        return false;
    }
    // Do _kb stuff only if process_record_user() didn't already handle the key event.
}

Yet all implementations I could find of process_record_kb() look like this:

bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
    // Alway do _kb stuff, and potentially even skip process_record_user() with early return.
    return process_record_user(keycode, record);
}

As a results you have to change code at the keyboard level if you want proper control at the keymap level.

No option of overwriting non-bool _kb() functions

The second part of this (which might even deserve its own issue), is that a lot of _user() and _kb() functions simply don't return a bool, which makes it impossible for the keyboard level to know if the user level already handled that functionality.

This includes things like void encoder_update_kb(), void matrix_init_kb(), void raw_hid_receive_kb(), void matrix_scan_kb() and a bunch more.

貢獻者指南