TMK keyboard firmware

[knowsnokb]

Does the TMK firmware have have double function functionality/hold-key tap-key functionality?

For example,can I do the following with TMK firmware on my keyboard?

Press and hold left ALT= ALT
Press and hold right ALT = ALT
Press and release left ALT = [
Press and release right ALT = ]
Press and hold left SHIFT = SHIFT
Press and release left SHIFT = {
Press and hold Q = fn1
Press and release Q = Q

Can I also assign shift keys to like !@#$":? etc... to any key I want without me requiring to press shift?
Ex..
Assigning ? to backspace
Assigning : to spacebar

Thanks.

[e_l_tang]

All of these functionalities are possible. They're documented at https://github.com/tmk/tmk_core/blob/master/doc/keymap.md.

[e_l_tang]

Does there exist a detailed explanation of how TMK works? I've been reading through the source code trying to understand it, but there are some parts that I just can't figure out.

[typewriter]

Does there exist a detailed explanation of how TMK works? I've been reading through the source code trying to understand it, but there are some parts that I just can't figure out.

I would also like to understand the code.
Are all the source code for the all libraries used by TMK available in your repository? (aside of course from standard C/C++/language libraries)?
Do all .h files (if TMK uses c/c++) have .c/.cpp files available at the TMK repository? (aside of course form standard C/C++ language libraries)?
I mean, does it use external libraries whose source codes are not available from the TMK repository?

[njbair]

Does there exist a detailed explanation of how TMK works? I've been reading through the source code trying to understand it, but there are some parts that I just can't figure out.

I would also like to understand the code.
Are all the source code for the all libraries used by TMK available in your repository? (aside of course from standard C/C++/language libraries)?
Do all .h files (if TMK uses c/c++) have .c/.cpp files available at the TMK repository? (aside of course form standard C/C++ language libraries)?
I mean, does it use external libraries whose source codes are not available from the TMK repository?

Everything you need to compile TMK is included in hasu's repo, with the exception of ChibiOS which must be pulled in manually if you need to use it (you would know if you did).

A lot of third-party libs are included in the repo.

[Koren]

I would also like to understand the code.

It's not really hard to understand, just take a pen and paper to remember what is in which file. ^_^

I don't think there's documentation on it (in fact, there's several fonctionalities that doesn't seem to have user documentation, if I'm not mistaken). Maybe we should create a Wiki to share our informations on it...

Are all the source code for the all libraries used by TMK available in your repository? (aside of course from standard C/C++/language libraries)?

As njbair said, it's self-contained for most boards, but the C/C++ chain is non-standard if you're doing your first embedded project. You may need avr-gcc or an equivalent for your board.

[e_l_tang]

I know what code in each file (the filenames make that pretty clear), but what I don't know what it does. I would greatly appreciate it if you wrote an explanation.

[a-c]

you will need to check schematic of PCB to know how to control and write code.

my GH 60 firmware doesn't support any LEDs except for caps lock, if you didn't know.

I traced the circuit on the GH60 Rev.C from Techkeys.

The WASD LEDs are connected to F7
The Poker Arrow LEDs are connected to F4
ESC is connected to F6

They are connected directly to the pin so appropriate resistors should be chosen to keep power draw for the 4 LEDs under 20mA total.

[gcardinal]

I have Tandberg TDV-5000 and it has a few uniq keys which I wasn't able to find in https://github.com/tmk/tmk_core/blob/master/doc/keycode.txt


I used HID Listen from https://www.pjrc.com/teensy/hid_listen.html and a few keys (top right row, orange keys in the picture)

// felt
r80 r4B +0F d0F
r80 rF0 r4B -0F u0F

// avsn
r80 r2A +19 d19
r80 rF0 r2A -19 u19

// setn
r80 r32 +05 d05
r80 rF0 r32 -05 u05

// ord
r80 r3A +10 d10
r80 rF0 r3A -10 u10

but I wasn't able to see how I can go from those codes to generate new array in keymap_common.h

Any help is greatly appreciated !

Edit: For use with tmk_keyboard > converter > ps2_usb

Edit 2: I now see that codes I got was wrong - since they came from arduino running "Soarer's Converter" - but I would still very much appreciate info on how to go from hid monitor output to keymapping

[hasu]

It seems like those keys spit scan code "80 xx" for press and "80 F0 xx" for release. Prefix code "80" is not known in general, probably specific to your keyboard. TMK PS/2 converter doesn't support it and I think Soarer's also not, they will just ignore "80".

To support those scan codes you have to fix ps2_usb/matrix.c to handle "80" prefix.

[axtran]

you will need to check schematic of PCB to know how to control and write code.

my GH 60 firmware doesn't support any LEDs except for caps lock, if you didn't know.

I traced the circuit on the GH60 Rev.C from Techkeys.

The WASD LEDs are connected to F7
The Poker Arrow LEDs are connected to F4
ESC is connected to F6

They are connected directly to the pin so appropriate resistors should be chosen to keep power draw for the 4 LEDs under 20mA total.

Any chance that you also have Fn or Caps LEDs too?

[a-c]

Caps is B2


Didn't notice a separate circuit for the FN, but it has to be either F5 or B0, those are the only pins left.

[axtran]

Caps is B2


Didn't notice a separate circuit for the FN, but it has to be either F5 or B0, those are the only pins left.

Thanks. I got my hands on a Green Rev. C from TechKeys and it is awesome.

[BlueNalgene]

I'm playing with dfu-programmer on debian, and I cannot successfully erase the old firmware on my board (which I programmed in Windows with FLIP)

Code: [Select]

# dfu-programmer atmega32u2 erase --suppress-validation --debug 300
Produces:

Code: [Select]

     target: atmega32u2
    chip_id: 0x2ff0
  vendor_id: 0x03eb
    command: erase
      quiet: false
      debug: 300
device_type: AVR
------ command specific below ------
   validate: false

then it proceeds to bring up the --help file.  This does not appear to erase the firmware on the device.  Running

Code: [Select]

# dfu-programmer atmega32u2 erase --suppress-validation --debug 300 && dfu-programmer atmega32u2 flash /home/wes/Downloads/alps64_firmware.hex --debug 300 && dfu-programmer atmega32u2 reset --debug 300
confirms this by giving a similar response as the erase only command, then spits out:

Code: [Select]

dfu.c:387: dfu_device_init( 1003, 12272, 0x7fff154fede0, true, false )
dfu.c:389: dfu_device_init(000003eb, 00002ff0)
libusb: debug [libusb_get_device_list]
libusb: debug [discovered_devs_append] need to increase capacity
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  0: 0x058f, 0x6364
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  1: 0x1d6b, 0x0002
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  2: 0x1267, 0x0103
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  3: 0x1d6b, 0x0001
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  4: 0x1d6b, 0x0001
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  5: 0x1d6b, 0x0002
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  6: 0x1d6b, 0x0001
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  7: 0x1d6b, 0x0002
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  8: 0x1d6b, 0x0001
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  9: 0x1d6b, 0x0003
libusb: debug [libusb_get_device_descriptor]
dfu.c:404: 10: 0x093a, 0x2521
libusb: debug [libusb_get_device_descriptor]
dfu.c:404: 11: 0x2109, 0x3431
libusb: debug [libusb_get_device_descriptor]
dfu.c:404: 12: 0x1d6b, 0x0002
dfu-programmer: no device present.
libusb: debug [libusb_exit]
libusb: debug [libusb_exit] destroying default context
The 4th line of that last output suggests that the old firmware did not erase.  Am I missing some sort of protection I need to disable when programming on Linux?

[e_l_tang]

Did you try using sudo?

[BlueNalgene]

Did you try using sudo?

I'm in Debian, so I use "su".  I was root when I ran the commands.

[axtran]

I'm playing with dfu-programmer on debian, and I cannot successfully erase the old firmware on my board (which I programmed in Windows with FLIP)

Code: [Select]

# dfu-programmer atmega32u2 erase --suppress-validation --debug 300
Produces:

Code: [Select]

     target: atmega32u2
    chip_id: 0x2ff0
  vendor_id: 0x03eb
    command: erase
      quiet: false
      debug: 300
device_type: AVR
------ command specific below ------
   validate: false

then it proceeds to bring up the --help file.  This does not appear to erase the firmware on the device.  Running

Code: [Select]

# dfu-programmer atmega32u2 erase --suppress-validation --debug 300 && dfu-programmer atmega32u2 flash /home/wes/Downloads/alps64_firmware.hex --debug 300 && dfu-programmer atmega32u2 reset --debug 300
confirms this by giving a similar response as the erase only command, then spits out:

Code: [Select]

dfu.c:387: dfu_device_init( 1003, 12272, 0x7fff154fede0, true, false )
dfu.c:389: dfu_device_init(000003eb, 00002ff0)
libusb: debug [libusb_get_device_list]
libusb: debug [discovered_devs_append] need to increase capacity
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  0: 0x058f, 0x6364
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  1: 0x1d6b, 0x0002
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  2: 0x1267, 0x0103
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  3: 0x1d6b, 0x0001
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  4: 0x1d6b, 0x0001
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  5: 0x1d6b, 0x0002
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  6: 0x1d6b, 0x0001
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  7: 0x1d6b, 0x0002
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  8: 0x1d6b, 0x0001
libusb: debug [libusb_get_device_descriptor]
dfu.c:404:  9: 0x1d6b, 0x0003
libusb: debug [libusb_get_device_descriptor]
dfu.c:404: 10: 0x093a, 0x2521
libusb: debug [libusb_get_device_descriptor]
dfu.c:404: 11: 0x2109, 0x3431
libusb: debug [libusb_get_device_descriptor]
dfu.c:404: 12: 0x1d6b, 0x0002
dfu-programmer: no device present.
libusb: debug [libusb_exit]
libusb: debug [libusb_exit] destroying default context
The 4th line of that last output suggests that the old firmware did not erase.  Am I missing some sort of protection I need to disable when programming on Linux?

I thought the chip was the atmega32u4?

[BlueNalgene]

I thought the chip was the atmega32u4?

The Alps64 uses ATMega32u2.  Source

[flabbergast]

There should be nothing special about doing this in linux. It looks like the dfu-programmer can't talk to the atmega at all. Maybe it's a permissions problem (try as root/sudo?).

[e_l_tang]

Are you sure you activated your chip's boot loader?

[hasu]

BlueNalgene,
Seems like dfu-programmer doesn't find bootloader device(03eb:2ff0) somehow. To activate bootlaoder
push the button on bottom and run `lsusb` command to check if the device is recognized. You should get a line for the device in output of the command like this.

Code: [Select]

Bus 001 Device 038: ID 03eb:2ff0 Atmel Corp.

If not something wrong may be in OS configuration or hardware.

[BlueNalgene]

BlueNalgene,
Seems like dfu-programmer doesn't find bootloader device(03eb:2ff0) somehow. To activate bootlaoder
push the button on bottom and run `lsusb` command to check if the device is recognized. You should get a line for the device in output of the command like this.

Code: [Select]

Bus 001 Device 038: ID 03eb:2ff0 Atmel Corp.

If not something wrong may be in OS configuration or hardware.

lsusb yields

Code: [Select]

Bus 006 Device 005: ID 03eb:2ff0 Atmel Corp.
Looking at the code, it seems that the

Code: [Select]

--force parameter is only necessary for programming a 'blank' chip.  I removed that flag and the erase command works again. 

SOLVED

Can anyone else confirm this observation?  It might be worth updating the FAQ/Instructions

[axtran]

BlueNalgene,
Seems like dfu-programmer doesn't find bootloader device(03eb:2ff0) somehow. To activate bootlaoder
push the button on bottom and run `lsusb` command to check if the device is recognized. You should get a line for the device in output of the command like this.

Code: [Select]

Bus 001 Device 038: ID 03eb:2ff0 Atmel Corp.

If not something wrong may be in OS configuration or hardware.

lsusb yields

Code: [Select]

Bus 006 Device 005: ID 03eb:2ff0 Atmel Corp.
Looking at the code, it seems that the

Code: [Select]

--force parameter is only necessary for programming a 'blank' chip.  I removed that flag and the erase command works again. 

SOLVED

Can anyone else confirm this observation?  It might be worth updating the FAQ/Instructions

I had to use --force on a blank GH60 Rev. C for an into all programming (erased first) and then subsequent programming attempts (dfu-programmer on OS X) worked without any issues.

[hasu]

Looking at the code, it seems that the

Code: [Select]

--force parameter is only necessary for programming a 'blank' chip.  I removed that flag and the erase command works again. 

SOLVED

Can anyone else confirm this observation?  It might be worth updating the FAQ/Instructions

First note that '--force' option of erase command is only implemented in 0.7.x, I think older dfu-programmer has no this option. So this depends on version of the tool.


Quote from man page. In case of 0.7.x it is safe that you always have '--force' option for erase, you will get an error when chip are already blank unless you have this option.

       erase [--force]
              Erases  all the flash memory.  For AT90 and ATmega type devices a chip erase must
              be performed before other commands become available.  Erase first checks  if  the
              memory is blank unless --force flag is set.

[njbair]

So I had an idea today. I use TMK's layer switching all the time. But I think it would be really cool if layouts could be broken out into "zones." I'll give an example below.

So I ordered a Monarch from the group buy last fall. If you're not familiar with the Monarch, it's basically a 60% with a number pad on the left. Like this:



It would be cool to be able to switch the layout of the 60% section, without changing the layout of the numpad section. Then I could configure that bank of numpad keys for different tasks, such as gaming, CAD, or number entry, meanwhile switching alpha layouts between QWERTY and Dvorak without the two affecting one another.

I know this is something that TMK can't do, but I'm wondering if it would be possible to do add support for this. I'm not asking if it's likely, because I know it's an obscure use case, but is it technically possible to do this?

I envision the keymap file could define the zones as arrays of keys that belong to each group, like so:

Code: [Select]

zones = {
    /* numpad zone */
    [0] = [0, 1, 2, 3,
           18,19,20,21,
           36,37,38,39,
           54,55,56,57,
           70,71],
    /* everything else */
    [1] = [4, 5, 6, 7, 8, 9, 10,11,12,13,14,15,16,17,
           22,23,24,25,26,27,28,29,30,31,32,33,34,35,
           40,41,42,43,44,45,46,47,48,49,50,51,52,53,
           58,59,60,61,62,63,64,65,66,67,68,69,
           72,73,74,75,76,77,78]
}

Then you would need to define the keymaps for those zones, which you could do pretty much the same way as it's done now.

But then the important final step would be to take the two zone arrays and concatenate them into the currently-active keymap. This seems like it should work; you just have to keep track of which layer is active in each zone.

The only thing I'm not sure about, is whether there is enough memory to do all of this extra work.

Any thoughts?

[hasu]

If Monarch has an AVR as controller you will be able to read keymap directly from flash and don't need much memory. Or if it has Cortex-M you don't have to worry about memory space any more.
http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html

You can implement your own keymap framework by replacing existent `action_for_key()` in tmk_core/common/keymap.c.

[gcardinal]

It seems like those keys spit scan code "80 xx" for press and "80 F0 xx" for release. Prefix code "80" is not known in general, probably specific to your keyboard. TMK PS/2 converter doesn't support it and I think Soarer's also not, they will just ignore "80".

To support those scan codes you have to fix ps2_usb/matrix.c to handle "80" prefix.

Thank you for the answer - I don't know C but I did gave it a try:
https://github.com/bergstar/tmk_keyboard/commit/f170fd174a4a2d523d8c8cc62337cf05a869a7dc

Will this be sufficient?

[BlueNalgene]

So I had an idea today. I use TMK's layer switching all the time. But I think it would be really cool if layouts could be broken out into "zones." I'll give an example below.

So I ordered a Monarch from the group buy last fall. If you're not familiar with the Monarch, it's basically a 60% with a number pad on the left. Like this:

Show Image

It would be cool to be able to switch the layout of the 60% section, without changing the layout of the numpad section. Then I could configure that bank of numpad keys for different tasks, such as gaming, CAD, or number entry, meanwhile switching alpha layouts between QWERTY and Dvorak without the two affecting one another.

I know this is something that TMK can't do, but I'm wondering if it would be possible to do add support for this. I'm not asking if it's likely, because I know it's an obscure use case, but is it technically possible to do this?

I envision the keymap file could define the zones as arrays of keys that belong to each group, like so:

Code: [Select]

zones = {
    /* numpad zone */
    [0] = [0, 1, 2, 3,
           18,19,20,21,
           36,37,38,39,
           54,55,56,57,
           70,71],
    /* everything else */
    [1] = [4, 5, 6, 7, 8, 9, 10,11,12,13,14,15,16,17,
           22,23,24,25,26,27,28,29,30,31,32,33,34,35,
           40,41,42,43,44,45,46,47,48,49,50,51,52,53,
           58,59,60,61,62,63,64,65,66,67,68,69,
           72,73,74,75,76,77,78]
}

Then you would need to define the keymaps for those zones, which you could do pretty much the same way as it's done now.

But then the important final step would be to take the two zone arrays and concatenate them into the currently-active keymap. This seems like it should work; you just have to keep track of which layer is active in each zone.

The only thing I'm not sure about, is whether there is enough memory to do all of this extra work.

Any thoughts?

Isn't that possible now?  You can use the toggle layer buttons to change the alpha section of the board, but leave the TK as transparent"  If you are talking about mixing and matching, you could just use a lot of layers. e.g. Layer 0 (default), Layer 1 (Dvorak Alpha), Layer 2 (upsidedown TK) , Layer 3 (Dvorak + upsidedown TK)

[axtran]

So I had an idea today. I use TMK's layer switching all the time. But I think it would be really cool if layouts could be broken out into "zones." I'll give an example below.

So I ordered a Monarch from the group buy last fall. If you're not familiar with the Monarch, it's basically a 60% with a number pad on the left. Like this:

Show Image

It would be cool to be able to switch the layout of the 60% section, without changing the layout of the numpad section. Then I could configure that bank of numpad keys for different tasks, such as gaming, CAD, or number entry, meanwhile switching alpha layouts between QWERTY and Dvorak without the two affecting one another.

I know this is something that TMK can't do, but I'm wondering if it would be possible to do add support for this. I'm not asking if it's likely, because I know it's an obscure use case, but is it technically possible to do this?

I envision the keymap file could define the zones as arrays of keys that belong to each group, like so:

Code: [Select]

zones = {
    /* numpad zone */
    [0] = [0, 1, 2, 3,
           18,19,20,21,
           36,37,38,39,
           54,55,56,57,
           70,71],
    /* everything else */
    [1] = [4, 5, 6, 7, 8, 9, 10,11,12,13,14,15,16,17,
           22,23,24,25,26,27,28,29,30,31,32,33,34,35,
           40,41,42,43,44,45,46,47,48,49,50,51,52,53,
           58,59,60,61,62,63,64,65,66,67,68,69,
           72,73,74,75,76,77,78]
}

Then you would need to define the keymaps for those zones, which you could do pretty much the same way as it's done now.

But then the important final step would be to take the two zone arrays and concatenate them into the currently-active keymap. This seems like it should work; you just have to keep track of which layer is active in each zone.

The only thing I'm not sure about, is whether there is enough memory to do all of this extra work.

Any thoughts?

Isn't that possible now?  You can use the toggle layer buttons to change the alpha section of the board, but leave the TK as transparent"  If you are talking about mixing and matching, you could just use a lot of layers. e.g. Layer 0 (default), Layer 1 (Dvorak Alpha), Layer 2 (upsidedown TK) , Layer 3 (Dvorak + upsidedown TK)

Yeah--you could just copy the keymap_poker.c approach (in the GH60 config). Overlay the keys you want and not others-- the array can also be viewed (reorganized) in different ways if you'd like to make it look like an unlock block.

[axtran]

Ugh "numlock block"

[njbair]

So I had an idea today. I use TMK's layer switching all the time. But I think it would be really cool if layouts could be broken out into "zones." I'll give an example below.

So I ordered a Monarch from the group buy last fall. If you're not familiar with the Monarch, it's basically a 60% with a number pad on the left. Like this:

Show Image

It would be cool to be able to switch the layout of the 60% section, without changing the layout of the numpad section. Then I could configure that bank of numpad keys for different tasks, such as gaming, CAD, or number entry, meanwhile switching alpha layouts between QWERTY and Dvorak without the two affecting one another.

I know this is something that TMK can't do, but I'm wondering if it would be possible to do add support for this. I'm not asking if it's likely, because I know it's an obscure use case, but is it technically possible to do this?

I envision the keymap file could define the zones as arrays of keys that belong to each group, like so:

Code: [Select]

zones = {
    /* numpad zone */
    [0] = [0, 1, 2, 3,
           18,19,20,21,
           36,37,38,39,
           54,55,56,57,
           70,71],
    /* everything else */
    [1] = [4, 5, 6, 7, 8, 9, 10,11,12,13,14,15,16,17,
           22,23,24,25,26,27,28,29,30,31,32,33,34,35,
           40,41,42,43,44,45,46,47,48,49,50,51,52,53,
           58,59,60,61,62,63,64,65,66,67,68,69,
           72,73,74,75,76,77,78]
}

Then you would need to define the keymaps for those zones, which you could do pretty much the same way as it's done now.

But then the important final step would be to take the two zone arrays and concatenate them into the currently-active keymap. This seems like it should work; you just have to keep track of which layer is active in each zone.

The only thing I'm not sure about, is whether there is enough memory to do all of this extra work.

Any thoughts?

Isn't that possible now?  You can use the toggle layer buttons to change the alpha section of the board, but leave the TK as transparent"  If you are talking about mixing and matching, you could just use a lot of layers. e.g. Layer 0 (default), Layer 1 (Dvorak Alpha), Layer 2 (upsidedown TK) , Layer 3 (Dvorak + upsidedown TK)

This won't work as you start adding more layers, because of the way layer stacking works.

Say you set up your layers like this (pseudo-code):

Code: [Select]

[0] = qwerty w/ numpad,
[1] = dvorak w/ numpad,
[3] = numpad gaming overlay (transparent alpha cluster),
[4] = numpad CAD overlay (transparent alpha cluster)

According to the docs, the firmware starts on your current layer, then keeps searching down the layer stack until it finds the first layer with something other than KC_TRANS, which in this case would be the Dvorak layer. Which means it's impossible to use the numpad overlay layers with QWERTY.

Unless, of course, you just make a layer for every conceivable combination, but that becomes unmanageable very quickly. There is also a 32-layer limit, which seems like a lot until you realize that 3 numpad layers and 3 alpha layers yields a total of 3³ = 27 layers.

That's why it would be necessary to be able to combine them programmatically at runtime.

[BlueNalgene]

More

So I had an idea today. I use TMK's layer switching all the time. But I think it would be really cool if layouts could be broken out into "zones." I'll give an example below.

So I ordered a Monarch from the group buy last fall. If you're not familiar with the Monarch, it's basically a 60% with a number pad on the left. Like this:

Show Image

It would be cool to be able to switch the layout of the 60% section, without changing the layout of the numpad section. Then I could configure that bank of numpad keys for different tasks, such as gaming, CAD, or number entry, meanwhile switching alpha layouts between QWERTY and Dvorak without the two affecting one another.

I know this is something that TMK can't do, but I'm wondering if it would be possible to do add support for this. I'm not asking if it's likely, because I know it's an obscure use case, but is it technically possible to do this?

I envision the keymap file could define the zones as arrays of keys that belong to each group, like so:

Code: [Select]

zones = {
    /* numpad zone */
    [0] = [0, 1, 2, 3,
           18,19,20,21,
           36,37,38,39,
           54,55,56,57,
           70,71],
    /* everything else */
    [1] = [4, 5, 6, 7, 8, 9, 10,11,12,13,14,15,16,17,
           22,23,24,25,26,27,28,29,30,31,32,33,34,35,
           40,41,42,43,44,45,46,47,48,49,50,51,52,53,
           58,59,60,61,62,63,64,65,66,67,68,69,
           72,73,74,75,76,77,78]
}

Then you would need to define the keymaps for those zones, which you could do pretty much the same way as it's done now.

But then the important final step would be to take the two zone arrays and concatenate them into the currently-active keymap. This seems like it should work; you just have to keep track of which layer is active in each zone.

The only thing I'm not sure about, is whether there is enough memory to do all of this extra work.

Any thoughts?

Isn't that possible now?  You can use the toggle layer buttons to change the alpha section of the board, but leave the TK as transparent"  If you are talking about mixing and matching, you could just use a lot of layers. e.g. Layer 0 (default), Layer 1 (Dvorak Alpha), Layer 2 (upsidedown TK) , Layer 3 (Dvorak + upsidedown TK)

This won't work as you start adding more layers, because of the way layer stacking works.

Say you set up your layers like this (pseudo-code):

Code: [Select]

[0] = qwerty w/ numpad,
[1] = dvorak w/ numpad,
[3] = numpad gaming overlay (transparent alpha cluster),
[4] = numpad CAD overlay (transparent alpha cluster)

According to the docs, the firmware starts on your current layer, then keeps searching down the layer stack until it finds the first layer with something other than KC_TRANS, which in this case would be the Dvorak layer. Which means it's impossible to use the numpad overlay layers with QWERTY.

Unless, of course, you just make a layer for every conceivable combination, but that becomes unmanageable very quickly. There is also a 32-layer limit, which seems like a lot until you realize that 3 numpad layers and 3 alpha layers yields a total of 3³ = 27 layers.

That's why it would be necessary to be able to combine them programmatically at runtime.

I see what you are saying.  I was recommending doing a layer for each combination (which might be less than you expect), but that may not be appropriate for what you want.  If you were to program a new layer class, you could have a separate switch toggle between QWERTY and DVORAK and just have a bunch of normal layer toggles for the numpad and anything else.  My pseudocode thinking is:

Code: [Select]

//layouttoggle
if switch.state = 1
    assign [q]->[']
    [w]->[,]
    etc.
else return default layout

//normal layers
[3] = numpad gaming overlay (transparent alpha cluster),
[4] = numpad CAD overlay (transparent alpha cluster)

By taking whatever matrix location is [q] and telling the firmware to now treat that as ['] you could possibly do this without creating a class that separates the board into fragments.  This is a more rudimentary approach to solving the problem, but it might be easier to implement. 

[njbair]

More

So I had an idea today. I use TMK's layer switching all the time. But I think it would be really cool if layouts could be broken out into "zones." I'll give an example below.

So I ordered a Monarch from the group buy last fall. If you're not familiar with the Monarch, it's basically a 60% with a number pad on the left. Like this:

Show Image

It would be cool to be able to switch the layout of the 60% section, without changing the layout of the numpad section. Then I could configure that bank of numpad keys for different tasks, such as gaming, CAD, or number entry, meanwhile switching alpha layouts between QWERTY and Dvorak without the two affecting one another.

I know this is something that TMK can't do, but I'm wondering if it would be possible to do add support for this. I'm not asking if it's likely, because I know it's an obscure use case, but is it technically possible to do this?

I envision the keymap file could define the zones as arrays of keys that belong to each group, like so:

Code: [Select]

zones = {
    /* numpad zone */
    [0] = [0, 1, 2, 3,
           18,19,20,21,
           36,37,38,39,
           54,55,56,57,
           70,71],
    /* everything else */
    [1] = [4, 5, 6, 7, 8, 9, 10,11,12,13,14,15,16,17,
           22,23,24,25,26,27,28,29,30,31,32,33,34,35,
           40,41,42,43,44,45,46,47,48,49,50,51,52,53,
           58,59,60,61,62,63,64,65,66,67,68,69,
           72,73,74,75,76,77,78]
}

Then you would need to define the keymaps for those zones, which you could do pretty much the same way as it's done now.

But then the important final step would be to take the two zone arrays and concatenate them into the currently-active keymap. This seems like it should work; you just have to keep track of which layer is active in each zone.

The only thing I'm not sure about, is whether there is enough memory to do all of this extra work.

Any thoughts?

Isn't that possible now?  You can use the toggle layer buttons to change the alpha section of the board, but leave the TK as transparent"  If you are talking about mixing and matching, you could just use a lot of layers. e.g. Layer 0 (default), Layer 1 (Dvorak Alpha), Layer 2 (upsidedown TK) , Layer 3 (Dvorak + upsidedown TK)

This won't work as you start adding more layers, because of the way layer stacking works.

Say you set up your layers like this (pseudo-code):

Code: [Select]

[0] = qwerty w/ numpad,
[1] = dvorak w/ numpad,
[3] = numpad gaming overlay (transparent alpha cluster),
[4] = numpad CAD overlay (transparent alpha cluster)

According to the docs, the firmware starts on your current layer, then keeps searching down the layer stack until it finds the first layer with something other than KC_TRANS, which in this case would be the Dvorak layer. Which means it's impossible to use the numpad overlay layers with QWERTY.

Unless, of course, you just make a layer for every conceivable combination, but that becomes unmanageable very quickly. There is also a 32-layer limit, which seems like a lot until you realize that 3 numpad layers and 3 alpha layers yields a total of 3³ = 27 layers.

That's why it would be necessary to be able to combine them programmatically at runtime.

I see what you are saying.  I was recommending doing a layer for each combination (which might be less than you expect), but that may not be appropriate for what you want.  If you were to program a new layer class, you could have a separate switch toggle between QWERTY and DVORAK and just have a bunch of normal layer toggles for the numpad and anything else.  My pseudocode thinking is:

Code: [Select]

//layouttoggle
if switch.state = 1
    assign [q]->[']
    [w]->[,]
    etc.
else return default layout

//normal layers
[3] = numpad gaming overlay (transparent alpha cluster),
[4] = numpad CAD overlay (transparent alpha cluster)

By taking whatever matrix location is [q] and telling the firmware to now treat that as ['] you could possibly do this without creating a class that separates the board into fragments.  This is a more rudimentary approach to solving the problem, but it might be easier to implement.

Your approach could work, and I've actually thought about that before, implementing a function in TMK that can create alternate layouts (Dvorak, Colemak, Workman, etc.) simply by juxtaposing their indexed positions. It would be extensible for other layouts just by creating new mappings, like so:

Code: [Select]

# QWERTY to Dvorak
q2d = [
  [A, A],
  [S, O],
  [D, E],
  [F, U],
  ...

This would be easier to maintain when changing layouts, because you really only have to create the QWERTY mapping and then just run the subsequent alternate layouts through the conversion process. You might even be able to do this with the macro preprocessor, although I'm admittedly inexperienced with C code.

For my Monarch idea, though, I am trying to think beyond this particular use case and to hopefully create an extensible system for multiple layout zones.

[e_l_tang]

njbair, I believe that BlueNalgene's original answer to your question is correct. If I'm not mistaken, if the keyboard spots a "TRNS" code on a layer, it will look down to the highest active layer with a keycode in that position that is not "TRNS".

[hasu]

It seems like those keys spit scan code "80 xx" for press and "80 F0 xx" for release. Prefix code "80" is not known in general, probably specific to your keyboard. TMK PS/2 converter doesn't support it and I think Soarer's also not, they will just ignore "80".

To support those scan codes you have to fix ps2_usb/matrix.c to handle "80" prefix.

Thank you for the answer - I don't know C but I did gave it a try:
https://github.com/bergstar/tmk_keyboard/commit/f170fd174a4a2d523d8c8cc62337cf05a869a7dc

Will this be sufficient?

It is not perfect but it may work.
You can handle 80-prefix codes as psuedo E0-prefix ones, though some of 80-prefix codes may crash with E0-prefix ones. But I think you can tolerable that, for example, ord(80 3A) key interferes 'WWW HOME' key(E0 3A) and etc.

See this for E0-prefix codes in Code Set 2(PS/2 scan codes).
http://www.computer-engineering.org/ps2keyboard/scancodes2.html


You can map the ord '80 3A' key with name 'KBA'(BA=80|3A) in keymap. You will need to change keymap macro for the other 80-prefix keys.
https://github.com/bergstar/tmk_keyboard/blob/f170fd174a4a2d523d8c8cc62337cf05a869a7dc/converter/ps2_usb/keymap_common.h#L36-L87

[Koren]

This won't work as you start adding more layers, because of the way layer stacking works.

Say you set up your layers like this (pseudo-code):

Code: [Select]

[0] = qwerty w/ numpad,
[1] = dvorak w/ numpad,
[3] = numpad gaming overlay (transparent alpha cluster),
[4] = numpad CAD overlay (transparent alpha cluster)

According to the docs, the firmware starts on your current layer, then keeps searching down the layer stack until it finds the first layer with something other than KC_TRANS, which in this case would be the Dvorak layer. Which means it's impossible to use the numpad overlay layers with QWERTY.

I may have misunderstood what you're after, but I think there's a slight error in the way layers works.

It starts with the higher active layer and go through lower *active* layers till it find a non-TRNS key.

If you have 0 and 3 as active, you'll get gaming keypad with qwerty alpha...

Unless, of course, you just make a layer for every conceivable combination, but that becomes unmanageable very quickly. There is also a 32-layer limit, which seems like a lot until you realize that 3 numpad layers and 3 alpha layers yields a total of 3³ = 27 layers.

It's definitively not a lot, I'm using 31, and that's with a lot of tricks to avoid multiplying layers. And I still can't do what I want. But that's because I want strange things ^_^

I'm running out of macros, too, but since I'm also at 99% memory usage...

That's why it would be necessary to be able to combine them programmatically at runtime.

Working on it for at least a different reasons (I want the keyboard layout and layout output both switchable... so that I can, for example, tell my keyboard that the computer wants QWERTY, or AZERTY, and translate its layout into the one the computer wants)

[njbair]

This won't work as you start adding more layers, because of the way layer stacking works.

Say you set up your layers like this (pseudo-code):

Code: [Select]

[0] = qwerty w/ numpad,
[1] = dvorak w/ numpad,
[3] = numpad gaming overlay (transparent alpha cluster),
[4] = numpad CAD overlay (transparent alpha cluster)

According to the docs, the firmware starts on your current layer, then keeps searching down the layer stack until it finds the first layer with something other than KC_TRANS, which in this case would be the Dvorak layer. Which means it's impossible to use the numpad overlay layers with QWERTY.

I may have misunderstood what you're after, but I think there's a slight error in the way layers works.

It starts with the higher active layer and go through lower *active* layers till it find a non-TRNS key.

If you have 0 and 3 as active, you'll get gaming keypad with qwerty alpha...

Unless, of course, you just make a layer for every conceivable combination, but that becomes unmanageable very quickly. There is also a 32-layer limit, which seems like a lot until you realize that 3 numpad layers and 3 alpha layers yields a total of 3³ = 27 layers.

It's definitively not a lot, I'm using 31, and that's with a lot of tricks to avoid multiplying layers. And I still can't do what I want. But that's because I want strange things ^_^

I'm running out of macros, too, but since I'm also at 99% memory usage...

That's why it would be necessary to be able to combine them programmatically at runtime.

Working on it for at least a different reasons (I want the keyboard layout and layout output both switchable... so that I can, for example, tell my keyboard that the computer wants QWERTY, or AZERTY, and translate its layout into the one the computer wants)

Are you sure this is the case? AFAIK there is only one active layer at a time. And if not, how do you select multiple layers for activation?

So if I'm understanding you correctly, you want to take a computer that's set up for AZERTY at the software level, and send it the necessary hardware codes while the keyboard is configured for QWERTY? That is definitely an obscure use case, but one I'm familiar with. I'm fact, I can instantly recognize "bhxacp" when I try to type "njbair" means I've got a double-Dvorak condition, just like I recognize "lcnago" means I'm in QWERTY when I should be in Dvorak.

[e_l_tang]

njbair, the state of every layer is independently stored as a bit. You are correct that there can be only one working layer, which is the highest layer that's active at a given time. You can use the functions below to activate and deactivate layers independently. 

Code: [Select]

layer_on(/*layer*/);
layer_off(/*layer*/);


[Koren]

Are you sure this is the case? AFAIK there is only one active layer at a time. And if not, how do you select multiple layers for activation?

Totally sure, I'm using it (a lot). Unless it's a fork difference, but I doubt it.

Each layer can be on or off independantly, and there's 32 layers because the state of each layer is store as a bit in a 32 bits word.

You can set / unset layers under the current active one without any issue with the normal way, btw.

So if I'm understanding you correctly, you want to take a computer that's set up for AZERTY at the software level, and send it the necessary hardware codes while the keyboard is configured for QWERTY?

Not exactly...


Imagine that I want a Dvorak on my keyboard, where the first character of the home row is A.

When I press the key, I want a A, obviously.

Now, if the computer driver believe the keyboard is a qwerty one, I need to send "2nd key, home row". If the computer believe the keyboard is an azerty one, I need to send "2nd key, upper row".

I want to be able to change this on the fly, having the same layout on the keyboard even if the layout defined in the computer change.


Another way to look at it, if you look at the TMK source code, you don't put a "Q" on your layout, but "KEY_Q", which is a macro that send "the key where there is a Q on a QWERTY keyboard". If you have another layout defined in the computer, you have to import a different definition file.

TMK translate

key  ---(layout)-->  scancode

I want

key  ---(layout)-->  character   ---(translation table)-->  scancode

where the translation table is also switchable on-the-fly.


Could be done by defining the 32 layers for each possible layout the computer may want (AZERTY, QWERTY, etc.), but I'm far from having enough memory for this...

All this come from the fact that keyboard still use scancodes to communicate with the computer instead of unicode points, which is just awfully crude...

[e_l_tang]

Does anyone know how I can make my keyboard momentarily cut off its data connection to my computer?

[vvp]

If the firmware does not support firmware reboot (in my fw it is Prg-B) then design your hardware so that you can hardware reset the keyboard.

[njbair]

I have a question about something I read in the docs:

Keymap layer '0' is usually default_layer and which is the only valid layer and other layers is initially off after boot up firmware, though, you can configured them in config.h.

So it says you can initialize other layers to be on by default in config.h, but I don't see any examples of this, or any documentation on which flags to set.

So how do I initialize Layer 31 to be on by default?

[nephiel]

Are you sure this is the case? AFAIK there is only one active layer at a time. And if not, how do you select multiple layers for activation?

Totally sure, I'm using it (a lot). Unless it's a fork difference, but I doubt it.

Each layer can be on or off independantly, and there's 32 layers because the state of each layer is store as a bit in a 32 bits word.

You can set / unset layers under the current active one without any issue with the normal way, btw.

So if I'm understanding you correctly, you want to take a computer that's set up for AZERTY at the software level, and send it the necessary hardware codes while the keyboard is configured for QWERTY?

Not exactly...


Imagine that I want a Dvorak on my keyboard, where the first character of the home row is A.

When I press the key, I want a A, obviously.

Now, if the computer driver believe the keyboard is a qwerty one, I need to send "2nd key, home row". If the computer believe the keyboard is an azerty one, I need to send "2nd key, upper row".

I want to be able to change this on the fly, having the same layout on the keyboard even if the layout defined in the computer change.


Another way to look at it, if you look at the TMK source code, you don't put a "Q" on your layout, but "KEY_Q", which is a macro that send "the key where there is a Q on a QWERTY keyboard". If you have another layout defined in the computer, you have to import a different definition file.

TMK translate

key  ---(layout)-->  scancode

I want

key  ---(layout)-->  character   ---(translation table)-->  scancode

where the translation table is also switchable on-the-fly.


Could be done by defining the 32 layers for each possible layout the computer may want (AZERTY, QWERTY, etc.), but I'm far from having enough memory for this...

All this come from the fact that keyboard still use scancodes to communicate with the computer instead of unicode points, which is just awfully crude...

I attempted to do this, because my board layout is Spanish but sometimes I use it on machines that expect an English layout. I tried to make a layer that I could toggle in that case, but ditched the idea because Spanish has 4 symbols per key (no mods, Shift, AltGr and Shift+AltGr) and not all of them are in the same key on English, so I'd have to check for 2 mods on each key before deciding what key to map to.

[Koren]

I attempted to do this, because my board layout is Spanish but sometimes I use it on machines that expect an English layout. I tried to make a layer that I could toggle in that case, but ditched the idea because Spanish has 4 symbols per key (no mods, Shift, AltGr and Shift+AltGr) and not all of them are in the same key on English, so I'd have to check for 2 mods on each key before deciding what key to map to.

Yes, it's difficult to do perfectly with 32 layers... That's the reason I want a double translation (also, it would be easier to define)

My current dox layout has 7 symbols per key (not counting arrows, Fn, media, mouse, japanese and shortcuts layers), and indeed it's a nightmare to map because symbols are not on the same keys/modifiers. Even worse, I still want shift to work like a normal shift key (plently of programs use shift) but shift should also work as a layer switcher for *some* layers (which isn't an issue) but sometimes (often) on the "shifted" layer I have symbols that require a non-shifted scancode, so I have to create a macro that un-shift just the time to send the scancode.

It fully works with computer set on my azerty variant, and I have a fallback on plain azerty and on plain qwerty, but it's really basic. But the worst part is that it's insanely time consuming to setup :/

[e_l_tang]

Koren, I am going to send a pull request to the QMK repository in a few weeks that will make creating keymaps like yours a lot easier. Do you want me to notify you when I do?

[Koren]

Koren, I am going to send a pull request to the QMK repository in a few weeks that will make creating keymaps like yours a lot easier. Do you want me to notify you when I do?

I'm checking from time to time the repo, because I'm interested in how people tackle the problems even if I intend to develop my own solution (probably this summer). If you have tome to send me a notification, that would be nice, indeed, but if you forget, that's not a big deal, I'll see it anyway.

[njbair]

According to the docs, keymap_call_function is called every time a key event is triggered. Is it possible to use this to detect which key is pressed and override the output with a different key code? This way you could translate QWERTY to Dvorak, for example, without having to hard-code the keymaps.

Or maybe there's a different function which would be better suited for this purpose?

[axtran]

Just finished adding LEDs to my GH60 Rev. C -- now playing off of the Caps Lock configuration in led.c (GH60 config folder) everything works as intended. I tried adding a layer config notification LED and it bombs out and sends the keyboard into just typing junk all over the place... anyone else experience this issue on GH60 Rev. C?

[e_l_tang]

njbair, why don't you just have separate layers for QWERTY and Dvorak?

[njbair]

njbair, why don't you just have separate layers for QWERTY and Dvorak?

Right now I do. But I have a bunch of keyboards running TMK and it gets tedious to recreate several different keymap definitions for each one (QWERTY, Dvorak, Colemak). Since QWERTY S is always Dvorak O and Colemak R, regardless of the board layout, I don't see why this step can't be automated. This could even be built into the magic commands and free up the function keys for other things. Just an idea.