Add DOUBLE_REPORT to fix RDP modifier key reliability

[Taudris]

Description

QMK has trouble sending modifier keys (eg LSFT(KC_TAB)) to remote computer GUIs via software such as Microsoft's Remote Desktop, and the local Hyper-V viewer. The modifier is frequently lost, causing the unmodified key to be pressed instead. (Exactly how often the modifiers are lost seems to be environment-specific, but I've experienced as high as 50% for some keys.)

This PR adds the ability for QMK to report changes to modifiers separately from changes to keys. Users need only add #define DOUBLE_REPORT to their config.h.

In my testing so far, this almost completely resolves the issue for MS RDP and Hyper-V. Out of several hundred keypresses, one might still fail to have the correct modifiers applied. This error rate is below typical human error when typing, so it is essentially transparent in real use.

The other proposed solutions I've seen so far (eg #19405, and code snippets in the issues referenced below) all involve adding a delay somewhere in the QMK code. I found in my own testing that this type of solution is not adequate; it can reduce the frequency of occurrence, but it does not seem to completely eliminate it, and may not work with all QMK features. Tuning the delay is also a hassle, and a given delay amount may not even work optimally for all environments.

This solution may also make #4198 obsolete.

This PR replaces #19436.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• Windows Remote Desktop Cannot Recognize Shifted Keys like KC_LPRN 100% of the time #1037
• Windows Remote Desktop ignores auto shift [Bug]  #13708
• [Bug] OSM SHIFT sometimes behaves incorrectly (oryx, moonlander) (RDP related) #15134
• Plans to solve the RDP issue? #18931

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[sambaum]

I have tested this for a few weeks now and had no issues with it. I would say this approach is better than in #19405
@drashna, in #19405 you have stated some concerns about solving the RDP issue by introducing a delay. So what do you think about this approach?

[drashna]

I've been using it for a while now, and it does work well. However, I'm not as knowledgeable about the USB stuff, so I'd rather defer to others that are much more knowledgeable.

Though, the name ... Could be better. HOST_SEND_DOUBLE_REPORT or some such. Makes it much clearer what the intent is.

[ntzm]

This solves the issue I was having with Wayland Ubuntu 22.04 terminal not recognising auto shifted keys, thank you

[Taudris]

Other name ideas that include QMK function names in the name:

• HOST_KEYBOARD_SEND_TWICE (I think I prefer this one at the moment)
• DOUBLE_HOST_KEYBOARD_SEND
• SEND_KEYBOARD_REPORT_TWICE
• DOUBLE_SEND_KEYBOARD_REPORT

[IsaacElenbaas]

This solves the issue I was having with Wayland Ubuntu 22.04 terminal not recognising auto shifted keys, thank you

@ntzm Auto Shift doesn't currently apply TAP_CODE_DELAY between modifier changes and key presses/releases, just between the key presses/releases. There are a couple of other issues open related to that. A PR to do that would also probably fix that for you if this ends up having any drawbacks or side effects.

[Roming22]

It does not solve the issue if the press/release of the key occurs in a very short time frame.

Not sure if that's relevant, but in my case the key is part of a layer activated by an LT key.

[cromulus80]

Is there an update on this?

[sambaum]

It does not solve the issue if the press/release of the key occurs in a very short time frame.
Not sure if that's relevant, but in my case the key is part of a layer activated by an LT key.

I had the same issue, so I went back to #19405, and I have never had any issues again. Unfortunately this PR is also stale/awaiting review.

[arman639]

I was using the REPORT_MOD_SEPARATELY from #19436 (by @Taudris as well) for the entire year already and was satisfied with that fix but lately I was noticing inconsistencies like before. Not sure if it was due to RDP itself or network related issue. After trying the solution on this new PR, the error rate becomes significantly lower.