I am going to have too look closer on that code some day =)
Is the locking/non-locking layer keys implemented as two separate functionalities? I had an idea to make shift locking (or act as a caps lock toggle) if it was pressed just shortly, and behave regularly when held for a longer period of time. I never got around to implement that though (as with many other things..).
To answer that question though, I think I'll have to write a quick overview of the firmware paradigm anyway - or feel free to skip the next two paragraphs, I won't be sad
. In this firmware, each keypress and keyrelease generates a function call, which is responsible for doing all the actual work. The function is passed a uint8_t (usually a keycode), along with some other things. The assigned functions and keycodes are stored in 3 separate [layer][row][column] matrices; so for each key, on each layer, we have a keycode, keypress function, and keyrelease function.
So, the functions dealing with layer increment and decrement all manipulate the layer matrix (each key also has its own layer) in the same way. Different behavior is implemented by changing which function gets called at what time. To implement a non-locking layer key, for instance, you'd assign an equal layer increment and decrement to that key's keypress function and keyrelease function. To implement a locking layer key, you'd assign an increment (or decrement) to that key's keypress function, and leave the keyrelease function null. There are a couple other behaviors that can be implemented as well.
Long answer, sorry. And I left out a lot of details, but I hope it's still clear enough.
Locking based on time sounds like a cool idea
. I don't know much of anything about AVR timers though, so if I look into it it'll have to be after I've gotten some other stuff done.
I strongly urge you not to do it. You are going to be entirely dependent on your very own setup, and you are going to _hate_ using anything but. Fun thing is that it sounds like a lot of work to learn that stuff, but in the end it's more for lazy people. ;-)
Haha. I realize that. I'm pretty sure this keyboard will be a definite step in the wrong direction then
Yes, actually, adding that flexibility would be interesting: one would achieve an Alt+Function key press without increasing the number of keys to be pressed. Same for a Control+fn and Shift+fn.
Added to the 'dev' branch
. Still to early to promise which features'll be in the final release, or be visible from the UI, but at least it's been through preliminary testing.
[image]
Looks good