search

sebeksd / Multi-Keyboard-For-AutoHotkey

Multi unique keyboard support for AutoHotkey
23 stars 0 forks source link

Original keys bypassing to MSFS 2020 #6

Open ptlrk opened 9 months ago

ptlrk commented 9 months ago

Works overall nice and I thought already having found the working follow up to HID Macros. Within less than two hours I could adapt it to AHK v2 and build a conversion function for a Sharkoon Rushpad with 48 replacement.

Unfortunately, original keys are still bypassing to MSFS 2020. I assume, this is because MSFS 2020 registers to the keyboard at very early stage, effectively before "MultiKB_For_AutoHotkey.exe".

Actually, AHK can block the original keys of all keyboard simultaneously by its inputhook() function and the right options (eg. "{All}", "+S" ). Thereby also "MultiKB_For_AutoHotkey.exe" stops working, too, why I guess, that it is intercepting after the hook of AHK and also the MSFS connection.

I don't know if there is any chance to tap on that. For sure, a solution would make a lot of home-cockpit users very happy.

If you need somebody for testing I'm prepared.

sebeksd commented 9 months ago

I did some testing today but for now I have no solution for this problem. I will try to look into it more, maybe I will buy MSFS or at least Xbox Game Pass.

Similar problem exists with Remote desktop so it would be awesome if both of them could be resolved.

ptlrk commented 9 months ago

Thanks for throwing an eye on it. Would be really awesome, if a solution could be found. Maybe the way AHK's inputhook() achieves it could give a hint, and because its open source this can be analyzed. I had already tried a pure AHL apporach based on this: https://www.autohotkey.com/boards/viewtopic.php?f=83&t=104629&p=464765&hilit=dllcall+RegisterRawInputDevices#p464765 by modifying it to registering to keyboards (i. UsagePage 1/Usage 6) and finding just the keyboard, and switching the key translation accordingly. Unfortunately, depending on the use of inputhook, either at lease some (if not all) of the original keys are getting through to the target app, or the callback WM_INPUT for identifying the sending keyboard does not receive keyboard messages anymore at all. This lets me think, it might be a matter of the individual position of the various hooks in the callback chain. Unfortunately I couldn't find a way to influence this. Neither I was successful in using "return 0" in the callback for the keyboard detection (to my understanding, this means "event processing complete", so the key should not show up in the target app.) I admit, I'm a newbie in WM-qeue processing, maybe my understanding is completely wrong.

sebeksd commented 9 months ago

I have installed Microsoft Flight Simulator 40th Anniversary (from Steam) but unfortunatly I can not replicate your problem. While game is running my secondary keyboard works fine with AutoHotkey.

So I was unable to test idea locally. I put it on new Git branch called "LowLevelEvent", If you can please try it. To enable new mode you need to add "ExperimentalLLHook=1" in general section of config file. When running in new mode you should see "Exp." in About window right next to file version. Remember to build both the main app and DLL (from project group).

If you need me to build it for you then please just leave me a message.

New mode uses LowLevelKeyboardProc instead of KeyboardProc, not 100% surte but this might be wat AutoHotkey is using. Even if it would work this is not finished product so there might be other problems like working only sometimes and not all the time.

ptlrk commented 9 months ago

Thank's a lot for the effort. I looked up the Delphi Community Edition, but it seems currently unavailable. So could you perhaps kindly prepare a build?

This is extremely interesting, that it seems to work correctly in the Steam Edition. I'm using the Store Edition via the XBOX-App on Windows 11 in combination with AutoHotkey v2. The main problem actually is not that keys from the intercepted keyboard are not anymore reaching AHK and then, after translation, reaching MSFS, but that also the original keys from the keyboard are reaching MSFS.

The following still relates to Release version: I have attached my AHK_v2 MSFS.ahk script and the Configuration.ini for your program. Therein two keyboards are contained, the primary keyboard "DW5100", disabled, and the secondory keyboard, that shall be translated. Correctly, only the keys from the seondary keyboard reach the script via the functions MsgFunc/OnUniqueKeyboard, got translation and arrive eventually at MSFS, while the keys from the primary keyboard arrive directly at MSFS without translation, as intended. Unfortunately, also the untranslated keys from the secondary keyboard arrive at MSFS, which prevent meaningful application. In the MSFS.ahk there are also two lines (commented out, currently) which activate AHK inputhook, blocking effectively any raw keys passing through to MSFS. Unfortunately, keys from the MsgFunc/OnUniqueKeyboard are no longer arriving anymore at the AHK script. MSFS.zip

sebeksd commented 9 months ago

Here is compiled version https://github.com/sebeksd/Multi-Keyboard-For-AutoHotkey/releases/tag/1.2-LLHook

As for more testing I will probably have time on the weekend :(

ptlrk commented 9 months ago

Thanks again, and don't mind I can wait. Yet, so far it was not successful.

Original keys are still reaching MSFS. Also other software like notepad++ or Windows editor "notepad.exe", is receiving the original keys now, which was not the case with your original version.

One additional observation is, that IsDown-events are not reported anymore by "OnUniqueKeyboard". My first ideas was, that possibly by mistake the new version simply lets the IsDown-event passing through, while other events (in particular "!IsDown" or "WasDown") would possibly blocked now. To verify in MSFS I remapped the standard function "Avionics Master" (PageUp) from "When button pressed (=IsDown)" to "When button relased (=!IsDown)". For easier testing in the AHK script I modified the translation of "PageUp" for the secondary keyboard to letter "l" (switch lights). Pressing "PageUp" on the (non-translated) primary keyboard results into nothing. Releasing "PageUp" toggles the Avionics Master switch, so far ok. On the secondary keyboard, exactly the same happens, despite the translation. So the !IsDown-events are actually propagating to MSFS, too. The result of the translation ("l") is also propagated to MSFS, as the light switches are toggled (Cessna 172).

Enabling the following in the AutoHotkey-Script prevents any keyboard events from reaching MSFS (and any other software)

ih := inputhook("I1 L0") ih.KeyOpt("{All}", "+S") ; Suppress all keys ih.Start()

Apparently, this blocks also keyboard events from "MultiKB_For_AutoHotkey.exe/Winhook.exe" as "OnUniqueKeyboard" is also not triggered.

I'm afraid, that my idea of going to the low-level input routine is not effective. It was based on the assumption, that the low-level input would be the starting point for the higher level input message queue and by catching the events there would solve the other problem as well. This seems to different.

I have attached my AHK-script (MSFS_LL), reduced to the minimum required for demonstrating the mentioned effects.

MSFS_LL.zip

ptlrk commented 9 months ago

One good knews (at least). Today I got Delphi 11 and could create a x64 build myself.

ptlrk commented 9 months ago

What a stupid mistake from my side! Forgot to add "ExperimentalLLHook=1" in general section of config file!

Now it seems actually to work with the little test script (hooray!). I will add again the rest of it and try our more.

ptlrk commented 9 months ago

A short update:

Seems, I was not that wrong eventually 😊

sebeksd commented 9 months ago

So If I read correctly the original problem seems to be resolved by Low Level Hook.

All other problems with new version is probably my fault because I was not paying attention what I was changing in this experimental build :sweat_smile: I just wanted it to "work".

Thanks for testing :smile:

sebeksd commented 9 months ago

Just made new experimental version.

However for some reason every ~second key stroke seems to not working and I don't know why :(

You can test it if you have time

ptlrk commented 9 months ago

I did some testing this afternoon. I put the results in the upload. In short: It appears that with 'ExperimentalLLHook=1' only every second key stroke is associated to the correct keyboard ID (as you wrote already). If the first key press on the captured keyboard went through unprocessed, then the next keypress will be always captured and tagged with the ID of the captured keyboard and translated accordingly, regardless from which keyboard it comes. test.zip

ech3lon42 commented 3 months ago

Hi. For me it also only works with ExperimentalLLHook=1 And then it behaves rather strangely with catching every 2nd keystroke.

Any chance you would improve it to work properly? I tested on Chrome, Windows 11, Skyrim, MSFS

When not using ExperimentalLLHook=1 it doesn't work for me on those applications. Strangely it works on NPP (Notepad++) but not in Chrome, Skyrim, MSFS.

Once this issue it solved it would be perfect for using dual keyboard. Below is my AHK Script for AHK 1.x (rename .txt to .ahk)

test.txt

sebeksd commented 3 months ago

Hi, So this is unfortunate. I did not write anything but I did some work and test with that experimental way however now I'm pretty sure its not possible to do.

Problem is that there are 3 ways to read keys, I will call them A,B,C. A - allows super low level way of reading, and can block the key from being registered (not used in default mode) B - doesn't allow blocking but has additional data that can distinguish devices C - almost the same as A but less low level, can block key strokes from registering in the system

"A" is triggered before every other method, "B" and "C" are triggered later and both of them in the same time (almost). In experimental mode I tried to use "A" but if I use it I have no information in "B" that is necessary. I need to release "A" to get "B" :( The reason it working every second key is because it uses "B" from previous stroke in next stroke of "A".

For now I have no idea how to get it working :(

ech3lon42 commented 2 months ago

Ah, I guess that explains it. Thank you for looking into it and for the explanation. I do wonder why it does work in some apps with the default method (without the low level experimental hook) and in others it doesn't work.

The default method works well (when the app allows it to work) - so if we could get the other apps to accept that method then the issue would also be solved.

sebeksd commented 2 months ago

I think that the reason for it not working with some apps is that they already use "A" or "C" method themselves to catch the Keystrokes.

I'm not sure if the borderless window mode has to do anything with it versus a full screen mode but you can check if changing the screen mode changes anything.

It would be nice If MS made some changes that would allow getting device information with method "A" (LowLevelHook), but for now I think only reliable methods are: