New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sticky keys behavior (one-shot mods and one-shot layers) #284
Conversation
a157f59
to
bd36023
Compare
bd36023
to
252ff14
Compare
@petejohanson do you know of a way to test the sensors in our test suite? It's not even compiling on a board with sensors like kyria even though the normal test suite succeed. |
64bf16a
to
897320e
Compare
rebased onto latest main, please review. |
897320e
to
ddcba37
Compare
ddcba37
to
310925b
Compare
Can we please not bundle vaguely related commits (the mass license headers) into PRs? A decent git tool will let you fire off a second PR with ease. |
I'd second @innovaker's request. Please do the header add (which is welcome!) as a fresh PR. Thanks! In the meantime, I'll review the code from the other two commits. |
Can we focus on the code instead of bikeshedding which commits are in this PR? Frankly I'm a bit bummed out about this thing being open for six weeks and only getting comments about license headers and trivial commits that could be split out to another PR. I don't think that's the thing we should focus on, especially considering the limited time each of us has available. I'll split the header commit out to another PR after the reviews are done, so I can batch all changes in one go instead of working on this N times. |
@okke-formsma, your contributions are always most appreciated and we're grateful for your patience. As someone who rebases daily, I can appreciate how frustrating it can be when PRs linger. With greatest respect though, please keep in mind that as maintainers and reviewers we also have competing priorities and other concerns that might not be immediately obvious. Also remember that doing a thorough review of an entirely new feature requires a significant block of time. Tidying up a PR takes far less time in comparison, yet makes it significantly easier (faster) for reviewers, which increases the chances of it being reviewed sooner. So far you've had cursory feedback - as in, we've done a quick scan and commented on any quick wins, as we do with any other PR - so that we can find an appropriate block of time for studying it in detail. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed the first commit, will do the second later.
- Looks fine, only minor suggestions.
- Commit title:
feat(events): add timestamp to keycode_state_changed and sensor_event
- Please be specific. I had to dig around a little to gather it was only two of the event types.
- Commit message:
dueto
>due to
- Can confirm this commit is formatted and passes existing tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a quick pass of eca8a2c, I'll let @petejohanson do the deep dive.
eca8a2c
to
6fbe84c
Compare
These timestamps are necessary to correctly deal with delayed events due to hold-tap shenanigans.
6fbe84c
to
462804c
Compare
Thanks for the review @innovaker, I've made most fixes you proposed except for the rename of the constants. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few review thoughts/questions.
462804c
to
cd29f36
Compare
Repushed with updated type signatures. Also renamed the array with active sticky keys to |
@petejohanson I've addressed all cancerns, can you have a look some time? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few more minor follow up.s
continue; | ||
} | ||
|
||
if (strcmp(sticky_key->config->behavior.behavior_dev, "KEY_PRESS") == 0 && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... I don't love keying off this label, but this might be the pragmatic way to do this. Any other options you'd considered?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously I had this keyed on key_position, but that requires keycode_state_changed
to gain a position
field too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while implementing this, I ran into the issue with
static int on_sensor_binding_triggered(struct zmk_behavior_binding *binding, struct device *sensor,
s64_t timestamp) {
a sensor does not have a "position", so the keycode_state_changed event can't have a position value.
instead we could also compare the timestamp, that's probably unique and matching too. May be a bit obscure though ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's leave it then, and consider circling back on this later.
struct behavior_sticky_key_data {}; | ||
static struct behavior_sticky_key_data behavior_sticky_key_data; | ||
|
||
#define _TRANSFORM_ENTRY(idx, node) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to extra this somewhere? Seems like this is duplicated from the keymap code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah it's copied in hold taps too. Mind if we commit this as-is and refactor the three common usages out in a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine by me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one minor comment, not worth holding this up.
|
||
LOG_MODULE_DECLARE(zmk, CONFIG_ZMK_LOG_LEVEL); | ||
|
||
#if DT_NODE_EXISTS(DT_DRV_INST(0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should really be:
#if DT_HAS_COMPAT_STATUS_OKAY(DT_DRV_COMPAT)
continue; | ||
} | ||
|
||
if (strcmp(sticky_key->config->behavior.behavior_dev, "KEY_PRESS") == 0 && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's leave it then, and consider circling back on this later.
implements sticky keys for #160