Windows: update side-aware modifiers information on state change

[eugenesvk]

• Windows Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• n/a Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

Addresses #3611, but won't completely fix it since the physical state of modifier keys is sometimes unknown to Winit since it doesn't track the raw physical keys

[kchibisov]

Could we roll back to old behavior where the check of key_pressed(VK_CONTROL) and such was used, except for META key where this is how it's being detected anyway.

[eugenesvk]

Why would you waste another system API call to get information you have already requested?

[kchibisov]

Are you sure that it matches? Could you link docs saying so, so the change is equivalent and it won't regress existing code, especially considering that we have virtual mods, etc?

[eugenesvk]

I couldn't find docs that say this with 100% certainty, only that it seems to follow from the description.
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getasynckeystate

You can use the virtual-key code constants VK_SHIFT, VK_CONTROL, and VK_MENU as values for the vKey parameter. This gives the state of the SHIFT, CTRL, or ALT keys without distinguishing between left and right.
You can use the following virtual-key code constants as values for vKey to distinguish between the left and right instances of those keys.

Also checked it with on-screen keyboards, but that, of course, doesn't guarantee very much either.

Do you have any key tests in Winit that are capable of verifying that?

Or is making ~33% more calls than needed the only way to avoid this risk?

[kchibisov]

Well more calls is only in a bad state, arguably, you can check for virtual, and only if it's present, check for left/right specifically, which would save calls on average, since most of the time you have only one modifier pressed.

[eugenesvk]

hm, good point

[eugenesvk]

ah, remember another reason for the current design - with altgr you can't use the side-agnostic state of Ctrl/Alt to then decide whether to check for the left/right sides, so the old approach only works for Shift.

[kchibisov]

Then it's an example of itself that the left/right are not attached to modifier itself. Like if logical is not active, but e.g. right is active, it still means that modifier is not active.

So e.g. modifier input is not applied to compose input.

[eugenesvk]

No, this is an example of how Windows is poorly designed that can be partially fixed within Winit, that's all.

Like if logical is not active, but e.g. right is active, it still means that modifier is not active.

No, it will be logically active since on Windows AltGr = RAlt+LCtrl, so you can't have Alt not active, but Right Alt active, both will be active

compose input

Again, this is not compose input, it's Ctrl+Alt = AltGr modifier input

[eugenesvk]

Anyway, updated for Shift where this actually saves 1 call, thanks for the tip!

[eugenesvk]

By the way, do you know why on every single mouse event you get modifier update calls if only keyboard events change modifier state? Isn't that excessive?

[kchibisov]

By the way, do you know why on every single mouse event you get modifier update calls if only keyboard events change modifier state? Isn't that excessive?

modifier can change without any key press or when key press was not visible to your application, so when you click mouse button the current modifier state will be considered, since modifiers are also carried on mouse events. IIRC.

[eugenesvk]

modifier can change without any key press

But not without a key/mod change event which are tracked separately? Or in what case would happen and not be caught by Winit?

or when key press was not visible to your application,

Can this happen when app has focus? Otherwise there is already a modifier update on when app gains focus. Maybe similarly a cheaper way would be to update modifiers when mouse is within app's window area (if focus change isn't enough).

[kchibisov]

But not without a key/mod change event which are tracked separately? Or in what case would happen and not be caught by Winit?

What if the window was out of focus though?

Can this happen when app has focus? Otherwise there is already a modifier update on when app gains focus. Maybe similarly a cheaper way would be to update modifiers when mouse is within app's window area (if focus change isn't enough).

I'm not sure, I know that on e.g. X11 it's utterly broken, since sometimes you have input that was send by other application to you and it relies on modifiers that were sent in those synthetic-ish events. It's just very easy to break things like that in general if you under update.

I'm pro updating less if we surely can do so, but I just know that any platform that is not Wayland has issues with that.

[eugenesvk]

What if the window was out of focus though?

I noted that below - there is already code that updates mod state on regaining focus. The skipping while out-of-focus part makes sense

Appreciate how overpolling can mask some bugs, just that it seems rather wasteful with all the potential high frequency of mouse input, so though whether it was done as a generic precaution or as an attempt to fix a specific Windows issue.

(> since sometimes you have input that was send by other application to you and it relies on modifiers that were sent in those synthetic-ish events.

and there is no way to add an update only on those events?)

[kchibisov]

and there is no way to add an update only on those events?)

If those can be detected then it should be done that way. I'm not a windows dev, so hard for me to say on that matter. Generally, we can relax the checks on mouse input.