tentator wrote: ↑
23 Mar 2020, 00:18
Now I'd be super curious to know your opinion on my secret wish: being able to implement in xwhatsit dual role keys (like "space-fn" if you know it or if you take a fn key like shift, I'd like to make it output arrow up if only pressed/tapped, while continue to be a shift when pressed and hold, because a predefined timeout has passed while holding that key, say 150ms).
I think it's possible, if I understand your idea right. It would be possible to do something like:
1) When the key is pressed, nothing is sent to the host
2) If the key is released, before time T passes, a quick immediate sequence of key A press-release is sent to the host
3) When time T passes, and the key is still pressed, then key B press is sent to the host (or layer is changed, if it's a keyboard-side function key)
4) When the key is released AFTER time T passes, then key B release is sent to the host (or layer is restored, if it's a keyboard-side function key)
Is this what you thought about? I just want to say, that the quick-press key A might feel sluggish in this case, since it's only sent on key-up.
consolation wrote: ↑
23 Mar 2020, 04:56
If I follow your fix, you are using two bits to set the layer? That puts a hard limit of layers at four?
Asking as I had vague plans to change the source code to allow more layers. I use multiple languages, so tend to just have different layouts on different layers, two layers per language - it adds up quickly. But, tbh, I can easily switch a keyboard at home and the F77 isn't something I'm going to carry around in the laptop bag; so if I read your change correctly, I'll save myself the hassle.
Yes, but you can always tweak it to be more to your liking. For example if debounce threshold can never be more then 7, then you can take a bit from the scanState part, and add it to the layer selection. You just modify the access macros in scan.h, and you can reshuffle storage as you whish.
Or -- I just double-checked, there is actually 379 bytes free in SRAM. An array of [cols][rows] size is 128 bytes. So I was wrong above about not being enough space for a separate sticky data structure. (My initial data structure idea didn't fit though, but that was different. So just modifying the acces macros, you can put the different fields in different variables.
The bigger problem that will make it harder for you to add more layers is not my change, but the lack of space in EEPROM.
As it is designed currently, each layer occupies 128 bytes of eeprom, and right now, eeprom has only 72 bytes of free space left.
It contains as follows:
1) Layer configuration for 4 layers: 4 * 128 bytes
2) Macro configuration: 424 bytes
3) Other smaller stuff: 16 bytes
Some of the things you could do to go around this limitation is to:
1) rip out macros (or to reduce macro capability)
2) move layer configuration into program space, where it won't be configurable anymore, but hardcoded. There's around 20K of program space left, so there's plenty of room there. But then you will have to rebuild your .hex file everytime you change layer layout, and it will be more complicated to set it all up manually without the aid of the GUI.
3) there may be other ways to shuffle things around, so you have more space for layers.
Saying all that I just picked up on what you said -- 2 layers per language -- what do you mean by language? Do you mean keyboard layout for special characters such as áéóúöőűíșâățî?
If yes, then there aren't any usb scancodes for those, languages like that can't be hardcoded into keyboards, those are always handled by the OS.