New Model F77 QMK Keypad remap

[jacks]

Does any qmk expert know the best way to remap the shifted keypad keys?

I would like to have the numpad behave in the way that the numpad option 2 (from Ellipses's site) is default, and something like option 1 is what happens when numlock is toggled. I will change further when the new keys are in, so basically I would like to know how it is planned to support the extra numpads using qmk.

I have currently set a layer 3 which is identical to layer 0 on the alpha side but which has the desired layout on the numpad, and have set the numlock key to toggle layers 3 and 0.

This seems to be workable, but might have issues with the operating system doing undesired things with numlock.

Is it possible to change the shifted codes of the numpad, so that this sort of setup works with a normal numlock and without an extra layer? Or is there a better way to do this?

Cheers,

JS

PS This site doesn't seem to like .json files as attachments. If anyone wants my layout file from the qmk configuartor, reply and I'll paste the text in here.

[PancakeMSTR]

Hey I just finished remapping my F77 using QMK, and I can try to help out. I didn't use the configurator, though, I did it through the command line on linux. If youre willing to go that route, I can definitely help, but I can try my hand at the configurator as well.

Mostly, though, I'm not 100% clear on what you want done. Starting with your layout probably a good idea, though, you can try sharing it with codeshare (or pastebin).

[jacks]

Thanks for the reply! Sorry the above is not really clear.

Here is an example of what I'm after with one key:

The QMK code for numpad 1 is KC_KP_1, which is keypad 1 or end, depending on whether or not numlock is on.
I would like it to be keypad 1 or DELETE. Similar would apply to the other keys on the numpad, so that toggling numlock would go between two layouts of my choice instead of the default ones.

At the moment I have a separate layer, with the numlock key actually being a layer-toggle key, and with the numpad 1 key sending KC_KP_1 on one layer and delete on the other layer. It's actually not working as intended at the moment, but that's because I haven't managed to turn my .json into a usable keymap.c. I will likely end up editing keymap.c by hand as I have no idea what the keyboard configurator actually does except that it puts all the keycodes in the right order and I can then copy them across.

I was wondering if there was a better way. There are several different numpad layout keysets, and so I would like to know how the keypad should be done in qmk to support them (and hence how to customize my own).

Thanks for your time!

JS

[jacks]

Putting the following into keymap.c seems to give the desired behaviour.

Basically a _NUMLOCK layer that is identical to the base except for the numpad keys, and then replacing the NUMLOCK key with a layer switch. Hopefully no side effects if/when the OS itself toggles numlock. The numpad keys give the original, default numpad behaviour when pushed with a shift key, for instance.

Loads of people must have done this already in qmk. Is this the best way to redefine the numpad, or should I be learning how to redefine the keys?

Thanks again.

Code: Select all

enum layer_names {
    _BASE,
    _NUMLOCK,
    _FN1,
    _FN2
};

// Defines the keycodes used by our macros in process_record_user
enum custom_keycodes {
    QMKBEST = SAFE_RANGE,
    QMKURL
};

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    /* Base */
    [_BASE] = LAYOUT_all(
        KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_MINS, KC_EQL, KC_BSLS, KC_GRAVE,    KC_P7,   KC_P8,   KC_P9,
        KC_TAB,    KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, KC_LBRC, KC_RBRC, KC_BSPC,         KC_P4,   KC_P5,   KC_P6,
        KC_CAPS,     KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, KC_SCLN, KC_QUOT, KC_NUHS, KC_ENT,    KC_P1,   KC_P2,   KC_P3,
        KC_LSFT, KC_NUBS,KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, MO(_FN1),    KC_P0,   KC_UP,   KC_PDOT,
        KC_LCTRL, KC_LGUI, KC_LALT,                      KC_SPC,           KC_NO, KC_RALT, DF(_NUMLOCK), KC_RCTRL,      KC_LEFT, KC_DOWN, KC_RIGHT
    ),
        [_NUMLOCK] = LAYOUT_all(
        KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_MINS, KC_EQL, KC_BSLS, KC_GRAVE,    KC_PSCR,   KC_SLCK,   KC_PAUSE,
        KC_TAB,    KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, KC_LBRC, KC_RBRC, KC_BSPC,         KC_INS,   KC_HOME,   KC_PGUP,
        KC_CAPS,     KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, KC_SCLN, KC_QUOT, KC_NUHS, KC_ENT,    KC_DEL,   KC_END,   KC_PGDN,
        KC_LSFT, KC_NUBS,KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, MO(_FN1),    KC_APP,   KC_UP,   KC_F12,
        KC_LCTRL, KC_LGUI, KC_LALT,                      KC_SPC,           KC_NO, KC_RALT, DF(_BASE), KC_RCTRL,      KC_LEFT, KC_DOWN, KC_RIGHT
    ),
    [_FN1] = LAYOUT_all(
        KC_GRV, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, KC_F6, KC_F7, KC_F8,   KC_F9, KC_F10,    KC_F11, KC_F12, KC_INS, KC_DEL,           KC_HOME,   KC_UP,   KC_PGUP,
        _______,      _______, _______, _______, _______, _______, _______, _______, KC_PSCR, KC_SLCK, KC_PAUS, KC_UP, _______, KC_DEL,                 KC_LEFT,   _______,   KC_RIGHT,
        _______,     KC_VOLD, KC_VOLU, KC_MUTE, KC_EJCT, _______, KC_PAST, KC_PSLS, KC_HOME, KC_PGUP, KC_LEFT, KC_RIGHT, _______, _______,  KC_END,    KC_DOWN, KC_PGDN,
        _______, _______, _______, _______, _______, _______, _______, KC_PPLS, KC_PMNS, KC_END, KC_PGDN, KC_DOWN, _______, _______,            KC_INS,    _______,   KC_DEL,
        _______, _______, _______,                             MO(_FN2),                 _______,  _______, _______, _______,             _______,     _______,   _______
    ),
    [_FN2] = LAYOUT_all(
        _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,   _______, _______, _______,
        _______,     _______, _______, EEPROM_RESET, RESET, _______, _______, _______, _______, _______, _______, _______, _______, _______,     _______, _______, _______,
        _______,         _______, _______, DEBUG, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,      _______, _______, _______,
        _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,            _______, _______, _______,
        _______, _______, _______,                             _______,                            _______,   _______, _______, _______,         _______, _______, _______
    )

};

[depletedvespene]

What I do is this:

• Layer 0 contains the basic mapping for alpha block and the pad as a navpad. Both 1U keys between Ctrl and Alt are Fn (the lack of a dedicated F row makes it specially important to have this mod on both sides), while the 1U key produced by splitting the right Shift key is LGUI (the Windows key — out of the way, where it won't be a nuisance, but still easily accesible).
• Layer 1 is a copy of layer 0, except the 1U keys between Ctrl and Alt are now LGUI and RGUI, and the split key is Fn (this is the traditional Fn position). This layer eases the use of the F77 keyboard on a Macintosh, where the GUI keys act as the Command (⌘) keys; Apple's mania of avoiding the F row like the plague diminishes a lot the usage of the Fn key, so having it in just one place (on an F77, not so on an F62) is acceptable.
• Layer 2 maps the pad as as the mix of arrow and numpad we all expect. This layer is toggled on and off with the key in the top-right corner of the alpha block. Note that this is a layer selection, not the "proper" num lock mode, so Num Lock has to be ON for numbers to be produced (if OFF, the key 4 will move the cursor to the left, etc.).
• Layer 3 defines the Fn layer "proper".

This was all done with the QMK configurator. There are some features I want to add (the key between space and RALT will later be a Macro key, to type out common sequences that I usually type, etc.), but this suffices for now.

[PancakeMSTR]

I'll take a look at what you did later when I get a chance but it looks to me like you're on the right track. You're not doing it much differently than how I would be, if that means anything.

[PancakeMSTR]

Still haven't looked at your problem, my bad. Do you still need help?

[jacks]

Not really, thanks!

I've learned a bit about how layers work - I now have a numpad second layer that is transparent otherwise, with a toggle between layers instead of numlock. This seems to be how everyone else is implementing their own numpad layers. I've also worked out how to use the configurator properly so I don't need to hand-edit my layout file

This does leave the shifted version of the numpad keys not being the same as the numpad layer whether you use numpad codes for the pad or just regular number codes. Easy to live with that.

It might also cause issues plugging into different computers that have numpad turned on or off separately if you use numpad codes. Plug into a different machine and suddenly your numpad 7 wants to be Home because the numlock is set differently on that machine, for instance. Might also be a bit trickier to implement lock lights, as it is no longer numlock that is toggling the layer (haven't looked into this at all).

One day I might work out if it is possible (and maybe better?) to have the numpad send a different second code, so that the numpad layer works using numlock instead of using a layer.

Thanks everyone!

JS

[darkcruix]

I started to use the VIA app locally on my system and the attached firmware with support for the app. It still is fully QMK based but allows to change the key assignment locally and on the fly (no re-compile).
This makes it much simpler to get to an optimal layout, imho.

Maybe you want to try it out - there is also a quick guide on how to use it in the zip file.

VIA.zip

(1.65 MiB) Downloaded 121 times

[Muirium]

Does this work with Xwhatsit controllers in IBM originals? I finally put Pandrew's QMK firmware on my Kishsaver and Beamspring this weekend and it works fantastic! But I'm still fiddling around with the finer details in my layouts and this live editing ability sounds very tempting.

If it can make Shift + Shift into Caps Lock then I'm in love.

Edit: ah, guess not.

Important Notes:
The provided firmware versions are only tested with the Brand New Model F models F62 and F77 from Model F Keyboards. They will not work with any other models at this point.
The Util.app that was part of the initial QMK version is not working at this point in time.

[darkcruix]

Does this work with Xwhatsit controllers in IBM originals? I finally put Pandrew's QMK firmware on my Kishsaver and Beamspring this weekend and it works fantastic! But I'm still fiddling around with the finer details in my layouts and this live editing ability sounds very tempting.

If it can make Shift + Shift into Caps Lock then I'm in love.

Edit: ah, guess not.

Important Notes:
The provided firmware versions are only tested with the Brand New Model F models F62 and F77 from Model F Keyboards. They will not work with any other models at this point.
The Util.app that was part of the initial QMK version is not working at this point in time.

Well - it definitely will work . The only downside is you need to make some changes to the source code of QMK and create your json file for your keyboard - just use the one in the zip as starting point. They will be different for sure, but you should be able to get the orders of rows and columns for the json with some testing.

config.h (adjust to your settings):

Code: Select all

#pragma once
#include "config_common.h"
#undef  PRODUCT
#undef  MANUFACTURER
#undef  DESCRIPTION
#undef  PRODUCT_ID
#define MANUFACTURER    Whatever
#define PRODUCT         Whatever 2
#define DESCRIPTION     A keyboard
#define VENDOR_ID 0x0481
#define PRODUCT_ID 0x0002
#define TAPPING_TERM 200
#define TAPPING_TOGGLE 2
#undef BOOTMAGIC_ENABLE
#undef BOOTMAGIC_LITE

rules.mk:

Code: Select all

VIA_ENABLE = yes
COMMAND_ENABLE = no
NKRO_ENABLE = no
LINK_TIME_OPTIMIZATION_ENABLE = yes
MOUSEKEY_ENABLE = yes
EXTRAKEY_ENABLE = yes       # Audio control and System control
CONSOLE_ENABLE = no         # Console for debug

On the util_comm.c make this change:

Code: Select all

void raw_hid_receive_kb(uint8_t *data, uint8_t length) {
    if (0 != memcmp(data, magic, sizeof(magic))) {
        return;
    }

[elcano]

Putting the following into keymap.c seems to give the desired behaviour.

Basically a _NUMLOCK layer that is identical to the base except for the numpad keys, and then replacing the NUMLOCK key with a layer switch. Hopefully no side effects if/when the OS itself toggles numlock. The numpad keys give the original, default numpad behaviour when pushed with a shift key, for instance.

It should be possible to create a QMK macro that switches layer and also switches the state of the NUMLOCK key. In this way the OS will always reflect the state of the keyboard. I'll try to look into it next week.

[elcano]

A macro was not needed. The code below should help you to toggle the layer as a function of a change in the Num Lock state. Notice that you might already have the function process_record_user in you keymap.c file. In that case, you only need to add from lines 5 to 14.

Important: For this to work, _NUMLOCK cannot be the base layer. This will only activate the _NUMLOCK layer. In this way it will overwrite the base layer as the default layer until deactivated. If your OS doesn't enable Num Lock, the keyboard will not have the Num Lock layer enable during initialization. If that is what you want, you need to configure the OS to enable Num Lock when loading.

Code: Select all

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
    // This section makes sure that the keyboard initializes with the proper layer, according to the Numlock setting of the host OS
    // It will also toggle the layer as you switch the Num Lock state
    // If you already have the process_record_user function in your code, you only need to add the code below
    bool num_lock = host_keyboard_led_state().num_lock; 
    if (num_lock) {
        if(IS_LAYER_OFF(_NUMLOCK)) {
            layer_on(_NUMLOCK);
        }
    } else {
        if(IS_LAYER_ON(_NUMLOCK)) {
            layer_off(_NUMLOCK); 
        }    
    }
    // If you already have this function, you only need to add the text above.
    return true;
}

[jacks]

Thanks! Seems to do the job.

I'm been flashing from configurator .json files at the moment as I'm changing layout twice a day and it's just easier. Once I make up my mind I will use the .c files and make this a permanent part of my board. I will want to add unicode support at some point so will no longer be able to use the configurator anyway (see below).

Anyone know the best way to add keys like pi, theta and the degree symbol? The board is getting used on linux (where I have full control of the input method) but also on random windows machines where I have no admin rights. I'm guessing unicode, with multiple input modes cycled by a key on a layer somewhere? It seems a bit sad that there is no standard way to send arbitrary characters from a keyboard.

JS

[elcano]

While you can configure almost any Unicode in Linux, in Windows you are restricted to the characters that are supported by Alt code entry. Luckily, the ones that you mentioned are supported.

When you can install additional software, QMK recommends installing WinCompose. This is a composer application that will allow you to build an Unicode character as a sequence of keystrokes.
However, I cannot install this app on my work computer, and prefer to standardize on not using it.

Whenever I switch OS I press a key combination that switches between Windows and Linux. I also have another key that prints out the current mode.

Finally, pandrew helped me with a function that can send Windows Alt Codes in lower and upper case pairs depending on whether the shift key is pressed. I use it for sending many character pairs in this format (á/Á) using their respective Alt codes "0225"/"0193", but you could use it for sending greek characters pairs like this (lowercase sigma σ, 229/uppercase sigma Σ, 228) or just the same character regardless of where the shift key is pressed or not (degree/degree, 0176/0176).

Let me know one you switch to keymap.c layout and I can share all this pieces of code here.