-
-
Notifications
You must be signed in to change notification settings - Fork 39.6k
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
Draft: [Core] Register multiple key events/presses per USB report #12686
base: develop
Are you sure you want to change the base?
Draft: [Core] Register multiple key events/presses per USB report #12686
Conversation
This may be intentional, but this breaks I have the polling rate set to 1000hz so taps from Setting If I disable the feature with I tested the following keycodes: |
Thanks for the feedback! The breakage is not intentional, I have added tap delays to the unregister process and those keycodes should be working again! |
cc6c5b6
to
da7269f
Compare
da7269f
to
6375202
Compare
I had a nice long message typed out about a issue I was having but it made me think a little, it was partly user error. I didn't have |
Fixed both the typo and the warning. Thank you for the feedback. |
0a4b1d2
to
e036bb7
Compare
Thank you for your contribution! |
The stale bot brought me here, so just thought I'd add I've been using this for sometime now and not noticed any issues. Thanks again. |
0f6ff08
to
b4c70cf
Compare
Looks like there are some merge conflicts here that need to be resolved. |
54911d6
to
8e5c489
Compare
Rebased my commits onto develop and squashed my commits into a single one. Should be good to merge now. |
This definitely causes issues for me. I'm not sure about other keys, but oneshot mods... if I hit both the OSM key and a regular key at the same time, neither are registered. Disabling this option immediately fixes the issue. I'm not sure if this effects LT/MT keys too, but I suspect that it may, depending on the tap-hold config options set. |
Oh well, I guess this is the point where more unit-tests have to be added to spot regressions like this. I'll see what the root cause is and add those tests. |
Just going to give this a little bump, been using this for quite some time with no noticeable problems. Merging it early this cycle would give it plenty of extra testing time. 😉 |
#endif | ||
|
||
#if !defined(QMK_KEYS_PER_SCAN) | ||
# define UNREGISTER_KEYCODES_BUFFER_SIZE 1 |
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.
not documented?
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.
Not configurable?
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.
Actually I'll would like to drop QMK_KEYS_PER_SCAN
entirely and give the main keyboard loop a facelift :-), will add documentation nevertheless.
'm consistently having problems with this, actually. Se previos statements for... n/m.... yeah. You can see exactly what 'm talking about. Edit: Note, I do use oneshot mods, and that seems to be where a majority of the issue occurs. but once in a while, mod tap also triggers it. |
I would very much like to merge #13789 first, afterwards I'll rebase and continue with these issues with proper unit-tests. |
Also I think it would be great if you could a test case that shows how this is different from the current behaviour. Something like this (not tested and not event sure this is the current behaviour because I can't make it compile with
This can be run with
In my opinion this test is good to have although is more for reference/documenting actual behaviour (more than to test regressions). On closer inspection, you already have this in the current PR although the code is separated, in the two section of the big #if #else , so nevermind |
Hi @ecerulm I'm currently working on #15292 which deprecates Some Unit-tests are already in place in this PR but more shall be added of course. |
Looking forward to see this as the standard and only behaviour I don't think there is any need to keep the old behaviour around. I think it should be mentioned in the documentation in this PR that QMK does not suffer from "chord splitting" anymore and that is suitable for gaming and for rythm games in particular where pressing multiple keys at once with accurate timing is essential (especially at lower polling rates). So that it's easy to find this information for people that google it. |
Yeah, If you look in the |
Thank you for your contribution! |
bump? |
Still WIP, I intend to continue with it after #15292 |
It looks like this code does not work when the matrix scan rate is significantly higher than the USB polling rate |
You're right. My (yet to be implemented) approach would be to just cap/couple the matrix scanning frequency to the USB polling frequency. The state of the implementation as it is won't be merged tough. I want to revisit the design choices and make the multiple key events behavior the standard/default one. |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
Pardon me for being naïve but for anyone subscribed to this PR in anticipation, what is keeping this draft from being merged as is in a separate commit? |
|
@tzarc I get that but it needs to be explicitly enabled and shouldn't affect existing configurations at all. Why couldn't it benefit users who knowingly enable it today? |
You’re more than welcome to apply the PR to your own fork if you’re happy with its current state. The original author is not, and that’s enough reason for it not to go to QMK mainline. |
Description
This is a continuation of #10955 by @hongaaronc (great work!) and addresses open issues with the implementation. Namely tapped key codes and shifted key codes. Please see the original PR for discussion and issues related to it.
Changes to adapt for tapped and subsequent shifted key events
Tapped key events by default work only on key release by sending a key press event and a subsequent key release event to the host. Now with deferring the send event after the complete matrix scan these events are merged and erase each other becoming effectively a nop. The idea is to buffer the unregister event of the key release for all tapped keys (normal keys are not buffered) and send these in a separate keyboard report just after the key press events have been send.
Unregister events/key codes are stored in the
unregister_keycodes
struct byunregister_code_buffered()
which is called for all tapped key codes and send to the host after a complete scan is completed bysend_keyboard_report_buffered_unregister_keys()
.Subsequent shifted key codes like pressing
KC_EQL
andKC_PLUS
(KC_LSHIFT
+KC_EQL
) while holding the former need an additional key release event ofKC_EQL
before sending the combination again. This release event isn't deferred anymore but send as a report immediately.All failing unit-tests have been fixed or rather adapted for this feature. As it turns out most of the failing key press cases expect one report per key event so they are false negatives. ATM the adapted unit-tests are behind a
#if defined
guard, I'm not familiar with the CI infrastructure and this needs addressing, currently two binaries would have to be compiled one with the default processing enabled and one withREGISTER_MULTIPLE_KEYEVENTS_ENABLE
. I have added a unit-test to ensure that this behavior works as intended.DEFER_KEYBOARD_REPORT_ENABLE
was renamed toREGISTER_MULTIPLE_KEYEVENTS_ENABLE
because it rather states a implementation detail but doesn't communicate purpose very well in my opinion.Types of Changes
Issues Fixed or Closed by This PR
Checklist