Hola, everybody. I've been -- as the kids say -- "AFK" for a while, dealing with personal/health issues when not working the day job. Such is life. I can tell you I'd much rather be here.
If I had been here, then perhaps I could have responded to this post sooner:
setiawan wrote: ↑17 Jul 2024, 16:15
I have numpad layout number 4 pictured below:
<snip>
Is there a way to get the numlock layer to work like depicted on my keys?
<snip>
I’ve only started using Vial tonight, but i don’t see any obvious way of catering to this use case. Do i have to create a toggle layer to act as num lock?
Yes.
This had already been done for you, though, in the
most recently published version of the Vial firmware (from back in February).
You just either needed to flash with one of the "f77-ansi_fn_opt4_*" keymaps, or load that keymap into your keyboard using Vial if you're already running r5 firmware.
Both variants of the keymap put the "Num Lock" layer on layer 1, and the "Fn" layer on layer 2.
Since the sheer quantity of F77 variants was careening out of control, I only ever shipped a keymap for Option 4 that assumes you have an HHKB-style split Right Shift. If you don't, then you can still use this keymap file, but you will need to go to the Layout tab in Vial, set Split Right Shift to "No Split", then go back to the keymap and change the Right Shift key from MO(2) to RShift (and relocate MO(2), which is effectively the Fn key, to your key of choice).
setiawan wrote: ↑17 Jul 2024, 16:15
Only difference is the OS obviously cannot recognise that num lock is enabled since it is not a real num lock, but not quite a big deal i suppose.
Support for having Num Lock status trigger with the layer switch is also included in this firmware.
There are two variants of the F77 "opt4" keymap provided:
- The "simulock" one uses a standard layer toggle TG(1) programmed into the spot for the Num Lock key, which is how I assume you did it.
- The "nlock" one programs the Num Lock key to actually be real Num Lock, and when Num Lock is on, layer 1 is selected, and when it's off, layer 0 is selected.
The Num Lock based layer triggering, though, isn't automatically enabled simply by loading the "nlock" .vil file into the keyboard with Vial. It
is automatically enabled if you re-flash the entire keyboard firmware again, however, and have it preload the "nlock" keymap variant in at flashing time.
This is because the Num Lock layer switching is not a standard QMK or Vial feature, so the Vial app has no clue it even exists. As a result, though there is a way to toggle the feature on and off without reflashing the whole firmware, it's slightly convoluted: What you need to do is pick a spare key (I'd recommend some unused key on layer 2) and assign it the custom keycode 0x5DFE. Pressing that key will then turn the Num Lock layer switch feature on and off. There is no visual indication of its current status, so the only way to know if it is working is to test it. It is persistent, though, so you don't need to re-enable it every single time you plug the keyboard in. (This was all described / explained in more detail in my posts from late September 2023, FWIW.) If you plan to leave it enabled indefinitely, you can simply assign 0x5DFE to some key temporarily, press that key to enable, then immediately delete that key assignment.
mikem wrote: ↑28 Jul 2024, 13:55
setiawan wrote: ↑17 Jul 2024, 16:15
How about the "00" key, would that simply have to be a macro? I don't think I've ever seen a keyboard with "00" before actually, I wonder if there is even a standardised key code for it
It does indeed have a code in the USB standard
This unfortunately doesn't mean much. From the QMK source code (tmk_core/common/keycode.h):
Code: Select all
// ***************************************************************
// These keycodes are present in the HID spec, but are *
// nonfunctional on modern OSes. QMK uses this range (0xA5-0xDF) *
// for the media and function keys instead - see below. *
// ***************************************************************
KC_KP_00 = 0xB0,
So, "KP_00" (or keypad 00) is not transmitted by QMK-based boards. Instead, that code value has been repurposed for a media key (KC_MEDIA_EJECT, by the looks of it). Even if there was a way to get QMK firmware to transmit that 00 code, there would have to be support for that keycode at the OS level, and at least if that comment text is to be believed, virtually no "modern OSes" support it.
So, yes: it has to be a macro.
