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

#8246 aperta il 25 feb 2020

Vedi su GitHub
 (7 commenti) (0 reazioni) (0 assegnatari)C (43.867 fork)batch import
discussiondocumentationhelp wantedquestion

Metriche repository

Star
 (20.368 star)
Metriche merge PR
 (Merge medio 20g 9h) (27 PR mergiate in 30 g)

Descrizione

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.

Guida contributor