I bet I’m doing something wrong, and misunderstanding how the layer logic works. I’m up to something just a little bit more complicated than I should be. I’ll investigate further before filing any bugs. Most likely problem is the nut in front of the wheel.BuGless wrote: 18 Jul 2022, 13:48I'd say, the current behaviour is a bug, and should be fixed in the generic case to switch layers as soon as the Fn key is pressed. I can't imagine any benefit to delay the layerswitch until the toggle key is being released.Muirium wrote: 17 Jul 2022, 14:09 Anyone know the TMK/QMK layer logic well enough to know if I can get the lazy Fn behaviour I desire? Having to release Fn just to "make it stick" doesn't feel right.
TMK keyboard firmware collection
- Muirium
- µ
- Location: Edinburgh, Scotland
- Main keyboard: HHKB Type-S with Bluetooth by Hasu
- Main mouse: Apple Magic Mouse
- Favorite switch: Gotta Try 'Em All
- DT Pro Member: µ
- mmm
- Location: Denmark
- Main keyboard: 34-key split keyboard / F122
- Main mouse: Mx Ergo / Trackpad
- Favorite switch: Cap bs
I don't think that behaviour is a bug. I am using this as a feature (though not in TMK, but in other keyboard firmware). An example is that I would have two different modifiers on the same key, depending on layer, but when I press and hold it, I don't want it to change when I change layer - I want the modifier to stay exactly as I did when I pressed and held it.BuGless wrote: 18 Jul 2022, 13:48I'd say, the current behaviour is a bug, and should be fixed in the generic case to switch layers as soon as the Fn key is pressed. I can't imagine any benefit to delay the layerswitch until the toggle key is being released.Muirium wrote: 17 Jul 2022, 14:09 Anyone know the TMK/QMK layer logic well enough to know if I can get the lazy Fn behaviour I desire? Having to release Fn just to "make it stick" doesn't feel right.
A feature to retrigger a key on layer change is what is needed here (I think), not sure how straightforward it is to implement a custom function that would do this.
-
BuGless
- Location: The Netherlands
- Main keyboard: New Model F77
- Main mouse: Logitech Trackman Wheel
- Favorite switch: Beamspring
If the toggle would activate the layer only (and immediately) on the press-event, then that would work. The key-release event being registered in the new layer should be a no-op. That would make it compatible with your use as well.mmm wrote: 18 Jul 2022, 17:58 An example is that I would have two different modifiers on the same key, depending on layer, but when I press and hold it, I don't want it to change when I change layer - I want the modifier to stay exactly as I did when I pressed and held it.
- Muirium
- µ
- Location: Edinburgh, Scotland
- Main keyboard: HHKB Type-S with Bluetooth by Hasu
- Main mouse: Apple Magic Mouse
- Favorite switch: Gotta Try 'Em All
- DT Pro Member: µ
Thanks for the tip. I've tried using KC_NO on the function layer, as you suggested, but it makes no difference, unfortunately. Currently, this is my best attempt:
I'm using QMK's DF() function—default layer—to swap in Layer 2 when in Mouse mode. Ultimately I get the exact same result however: only releasing the Fn key then holding it again makes the transition "stick". I may be asking too much for the GUI editor.
Reading Hasu’s docs, I see this is the likely culprit for my inactive layer switches:
I'm using QMK's DF() function—default layer—to swap in Layer 2 when in Mouse mode. Ultimately I get the exact same result however: only releasing the Fn key then holding it again makes the transition "stick". I may be asking too much for the GUI editor.
Reading Hasu’s docs, I see this is the likely culprit for my inactive layer switches:
Maybe I need two actions on the same key with different trigger states like this?2.2.3 Toggle Switch
Turns on layer with first type(press and release) and turns off with next.
ACTION_LAYER_TOGGLE(layer)
Hmm. Thinks… Hmm!2.2 Layer Action
These actions operate layers of keymap.
Parameters
You can specify a target layer of action and when the action is executed. Some actions take a bit value for bitwise operation.
layer: 0-31
on: { ON_PRESS | ON_RELEASE | ON_BOTH }
bits: 4-bit value and 1-bit mask bit
- depletedvespene
- Location: Chile
- Main keyboard: IBM Model F122
- Main mouse: Logitech G700s
- Favorite switch: buckling spring
- DT Pro Member: 0224
- Contact:
Hasu, I'll happily assume you still check this thread.
I noticed a possible omission in the USB-USB and IBMPC-USB online keymap editors.
Looking at the IBMPC-USB Converter editors for 84-key AT and 122-key Terminal, all the numpad keys are fully split, including numpad 0. However, in the Full-key pages, numpad 0 is not split, despite Model M full-size keyboards supporting this as well; this occurs in the USB-USB Converter page as well.
I use a Soarer's converter on my Model M (PC) keyboard with a 20-key numpad; it handles the split numpad 0 without issue (the scan codes it recognizes are EXTRA_INSERT [0xB6] and PAD_0 [0x62]). I don't have a terminal Model M at hand, but I assume the scan codes won't be too different, if at all, from these.
I think that supporting a split numpad0 in the USB-USB and IBMPC-USB online keymap editors shouldn't be too much of a hassle.
I noticed a possible omission in the USB-USB and IBMPC-USB online keymap editors.
Looking at the IBMPC-USB Converter editors for 84-key AT and 122-key Terminal, all the numpad keys are fully split, including numpad 0. However, in the Full-key pages, numpad 0 is not split, despite Model M full-size keyboards supporting this as well; this occurs in the USB-USB Converter page as well.
I use a Soarer's converter on my Model M (PC) keyboard with a 20-key numpad; it handles the split numpad 0 without issue (the scan codes it recognizes are EXTRA_INSERT [0xB6] and PAD_0 [0x62]). I don't have a terminal Model M at hand, but I assume the scan codes won't be too different, if at all, from these.
I think that supporting a split numpad0 in the USB-USB and IBMPC-USB online keymap editors shouldn't be too much of a hassle.
-
Ananta
- Location: Singapore
- Main keyboard: IBM 5576
- Main mouse: Realforce mouse
- Favorite switch: Alps blue
Hi all, I am a beginner at creating my own keyboard layout, currently using an IBM 5576 keyboard in JIS layout, so I'm hoping to create a blend that I can get used to while still enjoying the Alps buckling springs.
One major thing that I have been trying is to match my inputs with what is shown on the keycap. I managed to do so by creating two layers:


The layer 0 shift will toggle layer 2, which are all the "shifted keys" mapped in the order that I wanted.
This worked surprisingly well, but the problem is that I seem to have lost the function of the shift key itself. Can a single key press be mapped to two simultaneous functions (toggling a layer and performing the key action)? Is there a workaround for this?
Thanks in advance for all replies!
One major thing that I have been trying is to match my inputs with what is shown on the keycap. I managed to do so by creating two layers:


The layer 0 shift will toggle layer 2, which are all the "shifted keys" mapped in the order that I wanted.
This worked surprisingly well, but the problem is that I seem to have lost the function of the shift key itself. Can a single key press be mapped to two simultaneous functions (toggling a layer and performing the key action)? Is there a workaround for this?
Thanks in advance for all replies!
- Muirium
- µ
- Location: Edinburgh, Scotland
- Main keyboard: HHKB Type-S with Bluetooth by Hasu
- Main mouse: Apple Magic Mouse
- Favorite switch: Gotta Try 'Em All
- DT Pro Member: µ
What’s your reason for a layer full of shifted keys? Maybe I’m missing something but all the shifted keys seem to be in the same layout as your base layer. What’s your goal with them?
-
Ananta
- Location: Singapore
- Main keyboard: IBM 5576
- Main mouse: Realforce mouse
- Favorite switch: Alps blue
If you see the numbers row, you will see some differences in the mappingMuirium wrote: 06 Aug 2022, 11:29 What’s your reason for a layer full of shifted keys? Maybe I’m missing something but all the shifted keys seem to be in the same layout as your base layer. What’s your goal with them?
In the original layout, the shifted 6, 7, 8, 9, 0 keys will show the US keyboard symbols:
6 = ^
7 = &
8 = *
9 = (
0 = )
but the JIS keycaps show
6 = &
7 = `
8 = (
9 = )
0 = ~
I just want to remap the shifted inputs to match the keycaps
- depletedvespene
- Location: Chile
- Main keyboard: IBM Model F122
- Main mouse: Logitech G700s
- Favorite switch: buckling spring
- DT Pro Member: 0224
- Contact:
You don't do that at the TMK level — that's a matter for the logical layout you have selected on the operating system.Ananta wrote: 06 Aug 2022, 11:42If you see the numbers row, you will see some differences in the mappingMuirium wrote: 06 Aug 2022, 11:29 What’s your reason for a layer full of shifted keys? Maybe I’m missing something but all the shifted keys seem to be in the same layout as your base layer. What’s your goal with them?
In the original layout, the shifted 6, 7, 8, 9, 0 keys will show the US keyboard symbols:
6 = ^
7 = &
8 = *
9 = (
0 = )
but the JIS keycaps show
6 = &
7 = `
8 = (
9 = )
0 = ~
I just want to remap the shifted inputs to match the keycaps
When you press a key (say, the ;: key in a common English (USA) keyboard), what the keyboard sends to the computer is a scan code (0xC0); the operating system looks up that scan code in a table, which is the national or logical layout you've selected, and produces the ; character you wanted. If you select a different national layout in the operating syste, the same 0xC0 scan code will end up producing, say, Ñ (Spanish layouts), Ö (German layout), C (Azeri layout), et cetera.
Simply program the alphas normally on TMK; if you're using Windows, use a program like MSKLC to make a custom "English (bit-paired)" logical layout that will match the printed legends on each keycap.
-
Ananta
- Location: Singapore
- Main keyboard: IBM 5576
- Main mouse: Realforce mouse
- Favorite switch: Alps blue
thank you very much! will try MSKLC outdepletedvespene wrote: 06 Aug 2022, 16:53You don't do that at the TMK level — that's a matter for the logical layout you have selected on the operating system.Ananta wrote: 06 Aug 2022, 11:42If you see the numbers row, you will see some differences in the mappingMuirium wrote: 06 Aug 2022, 11:29 What’s your reason for a layer full of shifted keys? Maybe I’m missing something but all the shifted keys seem to be in the same layout as your base layer. What’s your goal with them?
In the original layout, the shifted 6, 7, 8, 9, 0 keys will show the US keyboard symbols:
6 = ^
7 = &
8 = *
9 = (
0 = )
but the JIS keycaps show
6 = &
7 = `
8 = (
9 = )
0 = ~
I just want to remap the shifted inputs to match the keycaps
When you press a key (say, the ;: key in a common English (USA) keyboard), what the keyboard sends to the computer is a scan code (0xC0); the operating system looks up that scan code in a table, which is the national or logical layout you've selected, and produces the ; character you wanted. If you select a different national layout in the operating syste, the same 0xC0 scan code will end up producing, say, Ñ (Spanish layouts), Ö (German layout), C (Azeri layout), et cetera.
Simply program the alphas normally on TMK; if you're using Windows, use a program like MSKLC to make a custom "English (bit-paired)" logical layout that will match the printed legends on each keycap.