Powertoys: Keyboard Manager remaps don't work consistently with FZ and Shortcut Guide

[arjunbalgovind]

KBM currently does not always work consistenly with FZ and Shortcut guide if the Win key is remapped. The current workaround for a user would be to disable and enable KBM (since this will restart the hook), however we should automatically do this for v1.

[arjunbalgovind]

Also applies to all the other PowerToys that use low level hooks i.e. PT Run, Color Picker and any future ones.

[arjunbalgovind]

Fixing this would also fix #4205 and #4360

[crutkas]

Wouldn't the #6060 work help correct this issue. @enricogior as FYI

[arjunbalgovind]

It won't since KBM and SG wouldn't be running out of the centralized handler. Since these still have independent hooks we need to ensure that the KBM hook is restarted whenever any of them gets enabled.
As @yuyoyuppe suggested offline in a mail thread, using IPC would be the best way to do this.

[crutkas]

@saahmedm how does this have both a pri3 and pri1?

[ryanbodrug-microsoft]

@arjunbalgovind How much effort / risk do you think this has.

[enricogior]

@ryanbodrug-microsoft
this is a much larger work item that it might seem, in FZ we need to be able to turn lowlevel keyboard hooks on and off, so the API to provide such functionality has to work the other way around compared to the current module interface where the runner calls the API. In this case is the module that needs to be able to call the runner to turn stuff on/off.
And we need multiple hooks, or multiple set of keys that we can turn on/off.
It's not straightforward since in some cases we process the keyboard notification and then only after some processing we determine that the key event needs to be bubbled up or not.

[ryanbodrug-microsoft]

@enricogior Thanks for the context. Do you agree that this is something that InVEST shouldn't take on given this is our last month?

[enricogior]

@ryanbodrug-microsoft
I agree, this work item can become a rabbit hole.
Also, I would like to investigate how much work would be required to implement the KM remapping at keyboard driver level, of course not in the upcoming weeks, but as a long term solution for this type of issues.

[arjunbalgovind]

Just for context for anyone who will work on this I'm adding the context from the mail thread about the non-driver approach. It would require setting up an IPC channel between KBM and the other modules (one way to KBM), so that whenever any module calls SetWindowsHookEx it would send a message to KBM to notify it to restart it's own hook. To make this more generalized the best way would be to have definition for settings a keyboard hook in common which would in turn send the IPC message and call SetWindowsHookEx so that all modules can call this version of the API instead.

[enricogior]

@arjunbalgovind
thanks for the clarification.
The approach seems OK in general, but in FZ we turn on/off hooks every time a window is dragged, and it has to be instantaneous otherwise the UX would be problematic. Doing IPC in that scenario doesn't seem ideal. That's why I prefer to consider other solutions.

[yuyoyuppe]

We could use shared memory IPC. We're already using a primitive for locked access to it for VCMute.