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

With eager_pk, fast key stroke will give stucked key event #6032

Closed
elfmimi opened this issue May 31, 2019 · 10 comments · Fixed by #6081
Closed

With eager_pk, fast key stroke will give stucked key event #6032

elfmimi opened this issue May 31, 2019 · 10 comments · Fixed by #6081
Assignees
Labels

Comments

@elfmimi
Copy link
Contributor

elfmimi commented May 31, 2019

Describe the Bug

When you select eager_pk as your debouncing filter,
if you press and release a key before the DEBOUNCE period ends,
that key will get stucked and keep appears to be held down to the OS and the user.

How to Reproduce

rules.mk:
DEBOUNCE_TYPE=eager_pk
config.h:
#define DEBOUNCE 100
and hit any key real quick.

Additional Context

The bug is introduced with this commit.
d0fb700 #5621

Here is an example how to fix this.
elfmimi@c69f740

Push notice: @alex-ong

@drashna
Copy link
Member

drashna commented May 31, 2019

not just eager per key. I've seen this with eager per row, and I think that ZSA (Ergodox EZ) has a number of reports of this too

@alex-ong
Copy link
Contributor

Thanks - yeah as a result of using changed to do cycle optimization this bug was introduced.
The fix looks solid, and would apply to eager per row too, since the algorithm is (gasp) the same

@alex-ong
Copy link
Contributor

@elfmimi could you test to ensure your fix is symmetric?
Feel free to add a pull request if you haven't already. While you're there, could you fix eager_per_row too?

e.g. set define DEBOUNCE 100
Press key for > 100ms
release key, and press again in <100ms
output should be key is pressed, then detects release, then detects press (timing may not line up due to 100ms debounce, but final state should be key is held down.

@drashna
Copy link
Member

drashna commented May 31, 2019

glad to hear that!

And yeah, @elfmimi could you open a PR with this change?
If you don't want to, let us know and one of us can handle that

@drashna
Copy link
Member

drashna commented May 31, 2019

Well, worst case, I'm testing out drashna/qmk_firmware@d9525c0db as that looks to include the changes to both, and I'll report back of that fixes the issues that I've been having.

@elfmimi
Copy link
Contributor Author

elfmimi commented May 31, 2019

I'd like to leave it to you two.

@alex-ong I checked and it behaved just as you mentioned. the final state is key down.

@drashna
Copy link
Member

drashna commented Jun 5, 2019

@alex-ong could you double check my commit?

I'm pretty sure that's correct, but .... I would like a double check.

@elfmimi awesome. And I've just created a PR to address this, for both PK and PR.

@alex-ong
Copy link
Contributor

alex-ong commented Jun 6, 2019

@drashna code looks right. If it seems like it works (set debounce to say 100 ms and then test it) then it.. probably works :)

@alex-ong
Copy link
Contributor

Was this eventually fixed? Can this be closed?

@drashna
Copy link
Member

drashna commented Jun 13, 2019

There is a PR for it, which is waiting on being merged. But yeah, I think it's fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants