Adding features from QMK

[eltang]

Here is a list of features from QMK that I think would be worthwhile to incorporate into TMK. I'll keep this list updated as I see new features being developed.

1. Ability to define key matrix with pin names
2. Magic keycodes
3. WS2812 RGB light effects
4. Scripts for setting up build environment
5. A cache that prevents keys from getting stuck when switching layers

If anyone has any questions about these features, I can try to answer them.

[tmk]

Yeah, I think this is most wanted and I'll like to make it as default.

• Prevent stuck modifiers Fix the layer-dependent modifiers handling qmk/qmk_firmware#182

[eltang]

I pushed for the feature to become default in QMK, but for some reason it was not made that way.

As you can see, I actually wrote the final encoding for that pull request. I am quite proud of it as it saves a lot of memory space.

I am trying to clean up the code right now, but I have a question that you might be able to answer. layer_switch_get_action is called not only by process_action but also process_tapping and is_tap_key. I don't quite understand the tapping code yet, so I am not sure if it is appropriate to use the cache in the latter two cases.

I'll send a pull request each to you and @vifon when I finish.

[tmk]

@yashikno is not related to me and this project, but github displays his avtar on my old commits. Becuase I've used 'noname@nowhere' as email address when making commits before, but then he registered @yashikno on github.com with 'noname@nowhere'. Not his fault, maybe github's.

Yeah, tapping code is mess and I also don't want to thouch :)
I'll look into those cases later and cherry-pick from QMK.

[eltang]

Okay. Do you want me to send you the code I have so far (to a new branch)?

[eltang]

Also, do you have plans to clean up the tapping code? I have tried and failed a few times to understand it.

[tmk]

Yes, I like to refactor it, the current code is result of heuristic tunes to my typing and set of ad hoc fixes. It is very difficut to understand it even for me.

I remember 'touch cursor' tool has very clean code and works well. I would refer to its code If I refactor tapping.
http://martin-stone.github.io/touchcursor/
https://github.com/martin-stone/touchcursor

[eltang]

Awesome. Maybe we should delay the integration of the cache until after the tapping code has been refactored. We should have a clearer idea of where the cache should be used then.

[eltang]

Could you please point me to the relevant part of the code? I can't seem to find it.

[eltang]

Do you have a timeline for implementing this feature?

[tmk]

I have no definite plan about jackhumbert#182 so far. But I'll try if I have time enough.

[tmk]

Or you mean refactor of tapping code? hmm, I don't know, but it won't basically as far as tapping works for me.

[eltang]

Those two changes might have to be done simultaneously, don't you think? Look back at our previous discussion.

[tmk]

If needed I'll try to rewrite. I did't look the patch closer but I thought tapping has no relation. I missed something?

[eltang]

The tapping code calls layer_switch_get_action in multiple places and the cache may or may not be needed in those instances.

[tmk]

could you give me a link to the source code?

[eltang]

https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/common/action.c#L523
https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/common/action_tapping.c#L118

[tmk]

ah, store_or_get_action() doesn't work with tapping? why?

[eltang]

I'm not actually sure whether or not it affects the tapping code. Its original developer kept the original layer_switch_get_action functions in the tapping code. I just thought it might be good to keep in mind that the tapping code calls layer_switch_get_action while implementing the cache and refactoring the tapping code.

store_or_get_action is really only different from layer_switch_get_action when the layer is changed while a key is held down. How does the current tapping code react to that situation? Or is that not relevant because the tapping code will be rewritten?

[tmk]

I don't see any reason it doesn't work but I may be wrong.
As you refered QMK doesn't use store_or_get_action() in those places for some reason.

Thanks for headsup!

[eltang]

All right then. Best of luck to you in getting those changes made. I'm looking forward to what you come up with. vifon/qmk_firmware#2 contains some unfinished changes to the cache code that I made. You may look at them if you are interested.

[eltang]

@tmk How's this coming along? I just had another idea for a great feature that resulted from a discussion over at the QMK repo. I think that when an ACTION_MACRO_TAP macro times out, the macro should be called a final time with a record->tap.end flag set as true. What do you think? I believe it will be very easy to implement.