Potential fix for CMD key woes in macOS

[readgs]

TL;DR (see below under "Details" if interested)
Forces a "key-up" event to be generated when combining CMD key with some other key. For example, the following sequence will result in the "R" key being held down on the remote side...

-Press down CMD
-Press down R
-Release R

The "R" will not register as being released until the "CMD" key is released. This is sub-optimal with most things (especially things like FN-CMD-TAB, etc.).

Details
In macOS using Chrome or Safari, when sending a key sequence that includes the CMD (Meta) key, the browser will never actually observe a "Key Up" for the key event. This results in "stuck" keys when performing actions like FN-CMD-TAB, CMD-S, etc. For scenarios where you have a macOS machine on both the client and host, it is common to use FN-CMD-TAB to tab between windows on the host machine. The current version of kvmd will behave as though you never release "TAB" until you also release the "CMD" key.

This behavior can be observed on macOS (in Chrome and Safari) using the following test page...
https://w3c.github.io/uievents/tools/key-event-viewer.html

The proposed solution here does the following...

1. Retains whether the Meta (CMD) key is down or up
2. If it is down, the code will automatically inject a "Key Down" even for any keys pressed while the Meta key is still down.
3. When the Meta key is released, code will work as it has previously.

The only downside I see thus far here is it prevents you from being able to actually hold down a key when the Meta key is also depressed. There are likely very few scenarios, if any, where a user would actually WANT to do this. But perhaps instead of this code ALWAYS being enabled, we offer a setting in Keyboard settings like "Enable CMD Key Fix" or however kvmd maintainers would like it to be named.

So far this fix is working well locally for me, and really eliminates a major headache. I'm happy to make adjustments to this as maintainers see fit, in order to get this into the base repo. Thanks.

[mdevaev]

Hi! Thanks for the detailed description. I'm already tired of these jokes from Apple. In fact, I've already done several approaches to this problem, including what you suggested, as I remember. One of our clients reported that the current implementation works best because it allows you to use CMD+R when booting macOS from the macOS client to get into the UEFI menu. Here the current fix.

There doesn't seem to be a way to fix this completely :/

[readgs]

Hi! Thanks for the detailed description. I'm already tired of these jokes from Apple. In fact, I've already done several approaches to this problem, including what you suggested, as I remember. One of our clients reported that the current implementation works best because it allows you to use CMD+R when booting macOS from the macOS client to get into the UEFI menu. Here the current fix.

There doesn't seem to be a way to fix this completely :/

Thanks for taking a look at my PR. I need to look at the current implementation you pointed me to, in detail. I feel like my fix and current fix are possibly addressing two different issues. But I'd like to dig deeper into the existing code before I say that for sure.

Without my PR, I get an issue where things like CMD-TAB end up being "sticky" on the host machine. I've been using my fix for severals days now and it seems to fix the issue without adverse effects.

But as I said, let me look at the current code you sent me, more thoroughly, when I get a chance. Then I will post a follow-up comment on this PR with my thoughts, so a better determination can be made.

[mdevaev]

Thank you 👌