Skip to content
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

Merged
merged 2 commits into from Nov 28, 2020

Conversation

okke-formsma
Copy link
Collaborator

implements sticky keys for #160

@innovaker innovaker added behaviors enhancement New feature or request labels Oct 16, 2020
@okke-formsma okke-formsma changed the title Sticky keys behavior Sticky keys behavior (one-shot mods and one-shot layers) Oct 27, 2020
@okke-formsma
Copy link
Collaborator Author

@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.

@okke-formsma okke-formsma force-pushed the sticky-keys branch 3 times, most recently from 64bf16a to 897320e Compare November 11, 2020 16:09
@okke-formsma
Copy link
Collaborator Author

rebased onto latest main, please review.

@innovaker
Copy link
Contributor

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.

@petejohanson
Copy link
Contributor

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.

@okke-formsma
Copy link
Collaborator Author

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.

@innovaker
Copy link
Contributor

innovaker commented Nov 12, 2020

@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.

Copy link
Contributor

@innovaker innovaker left a 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.

6348afb:

  • 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.

app/include/zmk/events/keycode-state-changed.h Outdated Show resolved Hide resolved
@innovaker innovaker self-requested a review November 12, 2020 20:20
Copy link
Contributor

@innovaker innovaker left a 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.

app/dts/bindings/behaviors/zmk,behavior-sticky-key.yaml Outdated Show resolved Hide resolved
app/src/behaviors/behavior_sticky_key.c Show resolved Hide resolved
app/src/behaviors/behavior_sticky_key.c Outdated Show resolved Hide resolved
app/src/behaviors/behavior_sticky_key.c Outdated Show resolved Hide resolved
These timestamps are necessary to correctly deal with delayed events due to hold-tap shenanigans.
@okke-formsma
Copy link
Collaborator Author

Thanks for the review @innovaker, I've made most fixes you proposed except for the rename of the constants.

Copy link
Contributor

@petejohanson petejohanson left a 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.

app/src/behaviors/behavior_sticky_key.c Show resolved Hide resolved
app/src/behaviors/behavior_sticky_key.c Outdated Show resolved Hide resolved
app/src/behaviors/behavior_sticky_key.c Outdated Show resolved Hide resolved
app/src/behaviors/behavior_sticky_key.c Outdated Show resolved Hide resolved
app/src/behaviors/behavior_sticky_key.c Show resolved Hide resolved
app/src/behaviors/behavior_sticky_key.c Show resolved Hide resolved
app/src/behaviors/behavior_sticky_key.c Show resolved Hide resolved
@okke-formsma
Copy link
Collaborator Author

Repushed with updated type signatures. Also renamed the array with active sticky keys to active_sticky_keys from active_sticky_key

@okke-formsma
Copy link
Collaborator Author

@petejohanson I've addressed all cancerns, can you have a look some time?

Copy link
Contributor

@petejohanson petejohanson left a 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

app/src/behaviors/behavior_sticky_key.c Show resolved Hide resolved
continue;
}

if (strcmp(sticky_key->config->behavior.behavior_dev, "KEY_PRESS") == 0 &&
Copy link
Contributor

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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 ...

Copy link
Contributor

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) \
Copy link
Contributor

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.

Copy link
Collaborator Author

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine by me.

Copy link
Contributor

@petejohanson petejohanson left a 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))
Copy link
Contributor

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 &&
Copy link
Contributor

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.

@petejohanson petejohanson merged commit 76a6d7b into zmkfirmware:main Nov 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants