refactor(hog): Cleanup ble message sending

[khoek]

We deduplicate a bunch of code removing about 80 lines (not clear from the diff due to dependence on other PR), fixing a very minor copy-paste typo in the process. No functional change.

Stacked on top of #2257 since we use a struct from there. Tested on an Adv360.

[petejohanson]

Thanks for the PR! Seems like a very reasonable approach. See my one comment about some additional cleanup that's likely possibly with this change.

[petejohanson]

I kind of like this idea... I do wonder: Do we really need to keep around types like struct zmk_hid_mouse_report with this change?

[petejohanson]

@khoek Any chance you are still interested in working on this?

[khoek]

@petejohanson Sorry about the radio silence, I forgot about your question, and remember interpreting it as slightly more contemplative at the time. Sure, I'll have a play around and see if I can get rid of them.

By the way while I have your attention: I've been having a bunch of trouble with applications correctly interpreting some taps coming out of hold-tap because of their very fast duration (coincidentally the same phenomenon which triggered the race condition bug which got me poking around in the first place)---mainly this is happening in e.g. video game engines which poll the key states themselves instead of handling events, and I guess the key is being press-released within a single frame. Anyhow, is there a natural way to integrate a configurable tiny delay into the current way ZMK works to alleviate this problem?---if that would be a bit awkward, is this more motivation for me to take another look at unblocking the main thread and adding a message queue for outbound USB messages (of course queuing a message to be sent later after some delay is then very cheap to implement in that setting)?

[khoek]

By the way, besides the upsides about queuing multiple messages instead of waiting which I evangelized in that other thread, the only downside I could think of was that, naively implemented, there would be a tiny latency slowdown which people interested in maximum responsiveness wouldn't like. So I just wanted to note that I was attentive to that and I'd be changing the USB send function to immediately commit a USB transaction if there wasn't a pending operation in progress, and only queue in the alternative case (of if e.g. the message was to be transmitted after some delay).

[petejohanson]

@petejohanson Sorry about the radio silence, I forgot about your question, and remember interpreting it as slightly more contemplative at the time. Sure, I'll have a play around and see if I can get rid of them.

By the way while I have your attention: I've been having a bunch of trouble with applications correctly interpreting some taps coming out of hold-tap because of their very fast duration (coincidentally the same phenomenon which triggered the race condition bug which got me poking around in the first place)---mainly this is happening in e.g. video game engines which poll the key states themselves instead of handling events, and I guess the key is being press-released within a single frame. Anyhow, is there a natural way to integrate a configurable tiny delay into the current way ZMK works to alleviate this problem?---if that would be a bit awkward, is this more motivation for me to take another look at unblocking the main thread and adding a message queue for outbound USB messages (of course queuing a message to be sent later after some delay is then very cheap to implement in that setting)?

You'd need to modify the hold-tap behavior to add a devicetree configurable release-delay and implement a sleep for that amount in the decide code for hold-tap.