stability of low-level keyboard interface
When pressing sequences of keys, it would be expected that the keyboard interface behaves exactly as the native Windows keyboard interface does. This means that slow and fast typists would recognize no change in the behavior of the keyboard interface when working inside a specific application. Even on multiple sequential key presses with overlap of keys, the interface should behave just like native windows. That would be the optimal case, I guess..
With JigsawWM I see some issues:
- one example is that when e.g. changing to
neovimapplication and trying to issue commands incommandmode, the command mode is suddenly closed when trying to insert a standard Windows path containing a\BACHSLASH character. - another example is, when typing fast and thus sometimes holding two keys down simultaneously while typing a word. The keys don't get recognized in a reliably stable way. So, sometimes the
<SPACE>character is missing. Or other keys.
@nnako Thanks for reporting the issue. I would need your key configuration related to the problematic behavior to analyze what went wrong,
thanks. please see #5 for the description of my configuration.
Hi @klesh ,
here you see a video (please excuse my spoken English, hope you understand anyway) showing a severe keyboard issue which seems to occur connected to this situations:
-
pressing a couple of keys quickly while they might overlap at times this seems to trigger unpredictable behaviours within the active application
-
especially pressing
backslashkey leads to unexpected behaviour and even seems to neutralize / freeze the<WIN>key for further actions.
the halt / neutralization of the <WIN> key seems to get healed when randomly pressing <CTRL>, <ALT> and <WIN> keys. Maybe even simultaneously in one or the other combination. Unfortunately, even switching on DEBUG mode on PowerShell does just log the ordinary actions (switching of application windows).
here the video:
https://github.com/klesh/JigsawWM/assets/5845602/589d1275-04c1-4e64-b453-37ced2acbd3a
During the video you saw other windows pop up. These normally get opened when actively pressing the <WIN> key. But in my case I didn't press that key. Just randomly typed some "ordinary" letters like <A>, <S>, <D>, <F>, <Y>, <X>, <Q> and <W> . Partially simultaneously and with different typing speeds.
Thanks for the video, it is quite informative, I can reproduce the problem on my local machine. Will see to it.❤️
I just updated the main branch, the problem should be fixed now, feel free to reopen the issue if is wasn't.
Hi @klesh , thanks for your efforts. Unfortunately, you solved #5 . So, now with the current main branch, the "bleeding" has stopped. I would like to re-open this issue. The essence of the issue was:
-
a kind of unpredictable reaction when pressing "normal" keys like e.g.
<A>,<S>,<D>,<F>,<Y>,<X>,<Q>and<W>in an partly overlapping manner. Now, when pressing and holding<Y>and then additionally pressing<X>, in Neovim the letters<F2>appear. As if the key<F12>had been pressed. pressing<Y>and then<C>in the same manner lets<F3>appear. In Germany, we use<Y>in the lower row left of<X>. Dunno, if this might cause a difference. -
pressing
\causes the<WIN>key to loose its function until the keys<CTRL>,<WIN>and<ALT>had been pressed multiple times (even overlapping). After that, the<WIN>key works properly again. But the<\>key does not show any physical representation on the screen.
These issues are still visible on my computer. Sorry for describing too much within the video above. Please have a look from 1:45 . There you see the issue. It is still active.
Hi, @nnako
Hi @klesh , thanks for your efforts. Unfortunately, you solved #5 . So, now with the current main branch, the "bleeding" has stopped. I would like to re-open this issue. The essence of the issue was:
- a kind of unpredictable reaction when pressing "normal" keys like e.g.
<A>,<S>,<D>,<F>,<Y>,<X>,<Q>and<W>in an partly overlapping manner. Now, when pressing and holding<Y>and then additionally pressing<X>, in Neovim the letters<F2>appear. As if the key<F12>had been pressed. pressing<Y>and then<C>in the same manner lets<F3>appear. In Germany, we use<Y>in the lower row left of<X>. Dunno, if this might cause a difference.
Hi, It is the default configuration, then when the <Y> key is held and tap the <X> key will produce a <F2>
- https://github.com/klesh/JigsawWM/blob/main/examples/jmk.pyw#L28 switch to layer 3 when held
- https://github.com/klesh/JigsawWM/blob/main/examples/jmk.pyw#L102 map
<X>to<F2>key
You can change the configuration to fit your need, all files in the examples folder are meant for demonstration, please copy them somewhere and change it as you see fit.
As for the unpredictable behavior when fast typing, it is a little bit complicated to explain, it is unavoidable when turning an Orindary Key to react differently for Tapping and Holding. You may take a look at this article https://docs.qmk.fm/#/tap_hold
- pressing
\causes the<WIN>key to loose its function until the keys<CTRL>,<WIN>and<ALT>had been pressed multiple times (even overlapping). After that, the<WIN>key works properly again. But the<\>key does not show any physical representation on the screen.These issues are still visible on my computer. Sorry for describing too much within the video above. Please have a look from 1:45 . There you see the issue. It is still active.
As of \ key... I don't know what was wrong. can you try running command py -m jigsawwm.w32.hook and press it and share the console output here? Thanks.
when entering that phrase, I get loads of output. So fast that I can not even press <CTRL> + <C> fast enough to be able to not fill my console buffer entirely. During execution of py -m jigsawwm.w32.hook mouse movements are very slow (low frequency). Here is a tiny part of what I see:
==================================
==================================
[01:09.949618] UNKNOWN 590960 ido: 0 idc: -1 Eingabeaufforderung - py -m jigsawwm.w32.hook
hwnd : 590960
title : Eingabeaufforderung - py -m jigsawwm.w32.hook
pid : c_ulong(4404)
class name : ConsoleWindowClass
exe path : C:\Windows\System32\cmd.exe
style : BORDER, CLIPSIBLINGS, DLGFRAME, GROUP, MAXIMIZEBOX, SIZEBOX, SYSMENU, VISIBLE, VSCROLL
exstyle : ACCEPTFILES, APPWINDOW, LAYERED, WINDOWEDGE
is_cloaked : False
rect : -2630 1278 -946 1589
bound : -2623 1278 -953 1582
is_app_window: True
is_manageable: True
is_evelated : False
==================================
==================================
[01:09.952599] UNKNOWN 590960 ido: 131006464 idc: 131006496 Eingabeaufforderung - py -m jigsawwm.w32.hook
hwnd : 590960
title : Eingabeaufforderung - py -m jigsawwm.w32.hook
pid : c_ulong(4404)
class name : ConsoleWindowClass
exe path : C:\Windows\System32\cmd.exe
style : BORDER, CLIPSIBLINGS, DLGFRAME, GROUP, MAXIMIZEBOX, SIZEBOX, SYSMENU, VISIBLE, VSCROLL
exstyle : ACCEPTFILES, APPWINDOW, LAYERED, WINDOWEDGE
is_cloaked : False
rect : -2630 1278 -946 1589
bound : -2623 1278 -953 1582
is_app_window: True
is_manageable: True
is_evelated : False
==================================
==================================
[01:09.956676] UNKNOWN 590960 ido: 0 idc: -1 Eingabeaufforderung - py -m jigsawwm.w32.hook
hwnd : 590960
title : Eingabeaufforderung - py -m jigsawwm.w32.hook
pid : c_ulong(4404)
class name : ConsoleWindowClass
exe path : C:\Windows\System32\cmd.exe
style : BORDER, CLIPSIBLINGS, DLGFRAME, GROUP, MAXIMIZEBOX, SIZEBOX, SYSMENU, VISIBLE, VSCROLL
exstyle : ACCEPTFILES, APPWINDOW, LAYERED, WINDOWEDGE
is_cloaked : False
rect : -2630 1278 -946 1589
bound : -2623 1278 -953 1582
is_app_window: True
is_manageable: True
is_evelated : False
==================================
==================================
[01:09.958676] UNKNOWN 590960 ido: 131006464 idc: 131006505 Eingabeaufforderung - py -m jigsawwm.w32.hook
hwnd : 590960
title : Eingabeaufforderung - py -m jigsawwm.w32.hook
pid : c_ulong(4404)
class name : ConsoleWindowClass
exe path : C:\Windows\System32\cmd.exe
style : BORDER, CLIPSIBLINGS, DLGFRAME, GROUP, MAXIMIZEBOX, SIZEBOX, SYSMENU, VISIBLE, VSCROLL
exstyle : ACCEPTFILES, APPWINDOW, LAYERED, WINDOWEDGE
is_cloaked : False
rect : -2630 1278 -946 1589
bound : -2623 1278 -953 1582
is_app_window: True
is_manageable: True
is_evelated : False
==================================
==================================
[01:09.961675] UNKNOWN 590960 ido: 0 idc: -1 Eingabeaufforderung - py -m jigsawwm.w32.hook
hwnd : 590960
title : Eingabeaufforderung - py -m jigsawwm.w32.hook
pid : c_ulong(4404)
class name : ConsoleWindowClass
exe path : C:\Windows\System32\cmd.exe
style : BORDER, CLIPSIBLINGS, DLGFRAME, GROUP, MAXIMIZEBOX, SIZEBOX, SYSMENU, VISIBLE, VSCROLL
exstyle : ACCEPTFILES, APPWINDOW, LAYERED, WINDOWEDGE
is_cloaked : False
rect : -2630 1278 -946 1589
bound : -2623 1278 -953 1582
is_app_window: True
is_manageable: True
is_evelated : False
==================================
==================================
[01:09.964676] UNKNOWN 590960 ido: 131006464 idc: 131006563 Eingabeaufforderung - py -m jigsawwm.w32.hook
hwnd : 590960
title : Eingabeaufforderung - py -m jigsawwm.w32.hook
pid : c_ulong(4404)
class name : ConsoleWindowClass
exe path : C:\Windows\System32\cmd.exe
style : BORDER, CLIPSIBLINGS, DLGFRAME, GROUP, MAXIMIZEBOX, SIZEBOX, SYSMENU, VISIBLE, VSCROLL
exstyle : ACCEPTFILES, APPWINDOW, LAYERED, WINDOWEDGE
is_cloaked : False
rect : -2630 1278 -946 1589
bound : -2623 1278 -953 1582
is_app_window: True
is_manageable: True
is_evelated : False
==================================
==================================
[01:09.967675] UNKNOWN 590960 ido: 131006564 idc: 458828 Eingabeaufforderung - py -m jigsawwm.w32.hook
hwnd : 590960
title : Eingabeaufforderung - py -m jigsawwm.w32.hook
pid : c_ulong(4404)
class name : ConsoleWindowClass
exe path : C:\Windows\System32\cmd.exe
style : BORDER, CLIPSIBLINGS, DLGFRAME, GROUP, MAXIMIZEBOX, SIZEBOX, SYSMENU, VISIBLE, VSCROLL
exstyle : ACCEPTFILES, APPWINDOW, LAYERED, WINDOWEDGE
is_cloaked : False
rect : -2630 1278 -946 1589
bound : -2623 1278 -953 1582
is_app_window: True
is_manageable: True
is_evelated : False
==================================
==================================
[01:09.969676] UNKNOWN 590960 ido: 0 idc: -1 Eingabeaufforderung - py -m jigsawwm.w32.hook
hwnd : 590960
title : Eingabeaufforderung - py -m jigsawwm.w32.hook
pid : c_ulong(4404)
class name : ConsoleWindowClass
^C
Hi, It is the default configuration, then when the
<Y>key is held and tap the<X>key will produce a<F2>
- https://github.com/klesh/JigsawWM/blob/main/examples/jmk.pyw#L28 switch to layer 3 when held
- https://github.com/klesh/JigsawWM/blob/main/examples/jmk.pyw#L102 map
<X>to<F2>keyYou can change the configuration to fit your need, all files in the
examplesfolder are meant for demonstration, please copy them somewhere and change it as you see fit.
Hmmm... please, could you explain how it comes that I get the defaults of jmk.pyw activated when I started wm.pyw? How do those configurations relate to each other? And how can I take, for example, wm.pyw as a basis for my own configurations and put it into my own location, then, without still activating the defaults within jmk.pyw?
As for the unpredictable behavior when fast typing, it is a little bit complicated to explain, it is unavoidable when turning an Orindary Key to react differently for Tapping and Holding. You may take a look at this article https://docs.qmk.fm/#/tap_hold
you sent the link for explanation of technique "holding and tapping", right? generally, there is no connection between JigsawWM and the QMK firmware and drivers, right? As far as I see it, the concept for "holding and tapping" is now understood. Not too complicated ;-) .
- For the
py -m jigsawwm.w32.hook, I failed to mention that you may need to comment Line 352 to 363 so that only the mouse and keyboard events would be printed. - The reason why
wm.pywcauses thejmk.pywget activated with its configuration is thatwm.pywimportsjmk.pywbecause it relies on thehksvariable for registering hotkeys andjmk.pywwould register itself and gets activated automatically. The.pywshould act more like a configuration rather than a feature, so it would be better to place your new feature under thejmkfolder and configure it with a.pywfile in theexamplesfolder. So, you should avoid importing thejmk.pywbut initialize thejmkin your own.pywfile if it is undesirable. - There is no physical connection between the
JigsawWMand theQMKfor sure. I just try to mimic some basic features from the greatQMK.😊
Hi @klesh ,
I have checked as you asked me to. Now, I try to explain what I did in order to see the keyboard low-level debug output, after I started wm.pyw from another terminal until I ended it using <CTRL> + <C>:
change to Neovim application...
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6459015 extra: 554696706
TAB WM_SYSKEYDOWN : vkCode 9 scanCode 0 flags: 48, time: 6459171 extra: 554696706
TAB WM_SYSKEYUP : vkCode 9 scanCode 0 flags: 176, time: 6459250 extra: 554696706
TAB WM_SYSKEYDOWN : vkCode 9 scanCode 0 flags: 48, time: 6459625 extra: 554696706
TAB WM_SYSKEYUP : vkCode 9 scanCode 0 flags: 176, time: 6459734 extra: 554696706
TAB WM_SYSKEYDOWN : vkCode 9 scanCode 0 flags: 48, time: 6460015 extra: 554696706
TAB WM_SYSKEYUP : vkCode 9 scanCode 0 flags: 176, time: 6460125 extra: 554696706
LMENU WM_KEYUP : vkCode a4 scanCode 0 flags: 144, time: 6460250 extra: 554696706
press some keys <:> (colon using <SHIFT> + <.> on a German keyboard), then <A>, <S>, ... which results in...
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462000 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462500 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462546 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462562 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462593 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462640 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462687 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462703 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462750 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462781 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462796 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462828 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462859 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462906 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462937 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6462968 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463000 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463031 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463062 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463093 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463125 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463156 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463187 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463234 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463265 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463296 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463328 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463375 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463390 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463421 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463453 extra: 554696706
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 0 flags: 17, time: 6463484 extra: 554696706
OEM_PERIOD WM_KEYDOWN : vkCode be scanCode 0 flags: 16, time: 6463531 extra: 554696706
OEM_PERIOD WM_KEYUP : vkCode be scanCode 0 flags: 144, time: 6463734 extra: 554696706
RSHIFT WM_KEYUP : vkCode a1 scanCode 0 flags: 145, time: 6464046 extra: 554696706
A WM_KEYDOWN : vkCode 41 scanCode 0 flags: 16, time: 6465359 extra: 554696706
A WM_KEYUP : vkCode 41 scanCode 0 flags: 144, time: 6465359 extra: 554696706
S WM_KEYDOWN : vkCode 53 scanCode 0 flags: 16, time: 6465953 extra: 554696706
S WM_KEYUP : vkCode 53 scanCode 0 flags: 144, time: 6465953 extra: 554696706
D WM_KEYDOWN : vkCode 44 scanCode 0 flags: 16, time: 6466546 extra: 554696706
D WM_KEYUP : vkCode 44 scanCode 0 flags: 144, time: 6466562 extra: 554696706
F WM_KEYDOWN : vkCode 46 scanCode 0 flags: 16, time: 6467140 extra: 554696706
F WM_KEYUP : vkCode 46 scanCode 0 flags: 144, time: 6467140 extra: 554696706
now, I press BACKSLASH by pressing <R-ALT> + <SZLIG> (the latter one being the appropriate key on German keyboards. pressing it with <SHIFT> would result in a question mark). which results in ...
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6468703 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6468703 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469218 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469250 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469281 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469312 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469343 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469375 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469421 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469453 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469484 extra: 554696706
RMENU WM_KEYDOWN : vkCode a5 scanCode 0 flags: 16, time: 6469515 extra: 554696706
OEM_4 WM_KEYDOWN : vkCode db scanCode 0 flags: 16, time: 6469515 extra: 554696706
OEM_4 WM_KEYUP : vkCode db scanCode 0 flags: 144, time: 6469718 extra: 554696706
RMENU WM_KEYUP : vkCode a5 scanCode 0 flags: 144, time: 6470312 extra: 554696706
the leading LCONTROL WM_KEYDOWN in the previous debug block seems off to me, as I have definitely not pressed <LCONTROL> in order to create a BACKSLASH.
After having pressed BACKSLASH, I see (as described further above in this thread) that the Neovim commandline closes. Instead of printing a BACKSLASH.
Now, I want to test whether or not I am still able to switch applications by pressing the ordinary <L-ALT> + <TAB>. And I see, while pressing these keys, applications don't switch...
LMENU WM_KEYDOWN : vkCode a4 scanCode 0 flags: 16, time: 6477359 extra: 554696706
TAB WM_KEYDOWN : vkCode 9 scanCode 0 flags: 16, time: 6477656 extra: 554696706
TAB WM_KEYUP : vkCode 9 scanCode 0 flags: 144, time: 6477781 extra: 554696706
LMENU WM_KEYUP : vkCode a4 scanCode 0 flags: 144, time: 6478500 extra: 554696706
LMENU WM_KEYDOWN : vkCode a4 scanCode 0 flags: 16, time: 6479562 extra: 554696706
TAB WM_KEYDOWN : vkCode 9 scanCode 0 flags: 16, time: 6479656 extra: 554696706
TAB WM_KEYUP : vkCode 9 scanCode 0 flags: 144, time: 6479796 extra: 554696706
LMENU WM_KEYUP : vkCode a4 scanCode 0 flags: 144, time: 6480078 extra: 554696706
LMENU WM_KEYDOWN : vkCode a4 scanCode 0 flags: 16, time: 6480562 extra: 554696706
TAB WM_KEYDOWN : vkCode 9 scanCode 0 flags: 16, time: 6480750 extra: 554696706
TAB WM_KEYUP : vkCode 9 scanCode 0 flags: 144, time: 6480875 extra: 554696706
LMENU WM_KEYUP : vkCode a4 scanCode 0 flags: 144, time: 6481015 extra: 554696706
LMENU WM_KEYDOWN : vkCode a4 scanCode 0 flags: 16, time: 6481187 extra: 554696706
TAB WM_KEYDOWN : vkCode 9 scanCode 0 flags: 16, time: 6481343 extra: 554696706
TAB WM_KEYUP : vkCode 9 scanCode 0 flags: 144, time: 6481453 extra: 554696706
TAB WM_KEYDOWN : vkCode 9 scanCode 0 flags: 16, time: 6481609 extra: 554696706
TAB WM_KEYUP : vkCode 9 scanCode 0 flags: 144, time: 6481734 extra: 554696706
TAB WM_KEYDOWN : vkCode 9 scanCode 0 flags: 16, time: 6481890 extra: 554696706
TAB WM_KEYUP : vkCode 9 scanCode 0 flags: 144, time: 6482000 extra: 554696706
TAB WM_KEYDOWN : vkCode 9 scanCode 0 flags: 16, time: 6482203 extra: 554696706
TAB WM_KEYUP : vkCode 9 scanCode 0 flags: 144, time: 6482312 extra: 554696706
TAB WM_KEYDOWN : vkCode 9 scanCode 0 flags: 16, time: 6482515 extra: 554696706
TAB WM_KEYUP : vkCode 9 scanCode 0 flags: 144, time: 6482625 extra: 554696706
LMENU WM_KEYUP : vkCode a4 scanCode 0 flags: 144, time: 6482703 extra: 554696706
Instead of switching applications, the start menu has opened. thus I press <ESC> to close it...
ESCAPE WM_KEYDOWN : vkCode 1b scanCode 0 flags: 16, time: 6486750 extra: 554696706
ESCAPE WM_KEYUP : vkCode 1b scanCode 0 flags: 144, time: 6486796 extra: 554696706
ESCAPE WM_KEYDOWN : vkCode 1b scanCode 0 flags: 16, time: 6488109 extra: 554696706
ESCAPE WM_KEYUP : vkCode 1b scanCode 0 flags: 144, time: 6488203 extra: 554696706
Now, I press <LCONTROL>, then <LWIN>, then <L-ALT>, ... and some variations of it in order to get the application switchin to run again...
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6488953 extra: 554696706
LCONTROL WM_KEYUP : vkCode a2 scanCode 0 flags: 144, time: 6489093 extra: 554696706
LWIN WM_KEYDOWN : vkCode 5b scanCode 0 flags: 16, time: 6489250 extra: 554696706
LWIN WM_KEYUP : vkCode 5b scanCode 0 flags: 144, time: 6489375 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6489484 extra: 554696706
LMENU WM_KEYUP : vkCode a4 scanCode 0 flags: 144, time: 6489609 extra: 554696706
LWIN WM_KEYDOWN : vkCode 5b scanCode 0 flags: 16, time: 6490062 extra: 554696706
LWIN WM_KEYUP : vkCode 5b scanCode 0 flags: 144, time: 6490187 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6490281 extra: 554696706
LCONTROL WM_KEYUP : vkCode a2 scanCode 0 flags: 144, time: 6490421 extra: 554696706
LWIN WM_KEYDOWN : vkCode 5b scanCode 0 flags: 16, time: 6490593 extra: 554696706
LWIN WM_KEYUP : vkCode 5b scanCode 0 flags: 144, time: 6490734 extra: 554696706
LWIN WM_KEYDOWN : vkCode 5b scanCode 0 flags: 16, time: 6491187 extra: 554696706
LWIN WM_KEYUP : vkCode 5b scanCode 0 flags: 144, time: 6491312 extra: 554696706
Now, I try switching applications using <L-ALT> + <TAB>, and it works properly again. applications get switched...
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6492062 extra: 554696706
TAB WM_SYSKEYDOWN : vkCode 9 scanCode 0 flags: 48, time: 6492437 extra: 554696706
TAB WM_SYSKEYUP : vkCode 9 scanCode 0 flags: 176, time: 6492531 extra: 554696706
LMENU WM_KEYUP : vkCode a4 scanCode 0 flags: 144, time: 6493125 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6493515 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494015 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494046 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494078 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494109 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494140 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494187 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494218 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494250 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494281 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494312 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494343 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494375 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494406 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494437 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494484 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494515 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494546 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494578 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494609 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494640 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494671 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494703 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494750 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6494781 extra: 554696706
TAB WM_SYSKEYDOWN : vkCode 9 scanCode 0 flags: 48, time: 6494796 extra: 554696706
TAB WM_SYSKEYUP : vkCode 9 scanCode 0 flags: 176, time: 6494906 extra: 554696706
TAB WM_SYSKEYDOWN : vkCode 9 scanCode 0 flags: 48, time: 6495234 extra: 554696706
TAB WM_SYSKEYUP : vkCode 9 scanCode 0 flags: 176, time: 6495359 extra: 554696706
LMENU WM_KEYUP : vkCode a4 scanCode 0 flags: 144, time: 6495500 extra: 554696706
LMENU WM_SYSKEYDOWN : vkCode a4 scanCode 0 flags: 48, time: 6497296 extra: 554696706
TAB WM_SYSKEYDOWN : vkCode 9 scanCode 0 flags: 48, time: 6497468 extra: 554696706
TAB WM_SYSKEYUP : vkCode 9 scanCode 0 flags: 176, time: 6497625 extra: 554696706
LMENU WM_KEYUP : vkCode a4 scanCode 0 flags: 144, time: 6498546 extra: 554696706
having reached the terminal where I started wm.pyw, I can now send a <CTRL> + <C> to end the process...
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500187 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500687 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500734 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500765 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500796 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500828 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500859 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500890 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500921 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6500953 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6501000 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6501031 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6501062 extra: 554696706
LCONTROL WM_KEYDOWN : vkCode a2 scanCode 0 flags: 16, time: 6501093 extra: 554696706
C WM_KEYDOWN : vkCode 43 scanCode 0 flags: 16, time: 6501109 extra: 554696706
C WM_KEYUP : vkCode 43 scanCode 2e flags: 128, time: 6501375 extra: 0
LCONTROL WM_KEYUP : vkCode a2 scanCode 1d flags: 128, time: 6501671 extra: 0
That's all.
Thanks, @nnako , very thorough...
The unexpected LControl from the 3rd step caused all the mess IMO.
However, I don't have a clue why it happened yet, can it be reproduced stably?
What if you don't enter the ASDF, will it produces the unexpected LControl again?
PS, do you mind posting a picture of your keyboard? thanks.
Hi @klesh , yes, the <LControl> seems odd, here. And odd is also that it appears before long pressing the <RMenu> prior to the <BACKSLASH>. So, it does not even seem to have anything to do with pressing the <BACKSLASH> key but with something preceeding it.
here my keyboard (Keychron K8 PRO German):
I just checked the low-level keyboard interface WITHOUT further pyw file by opening the standard console, walking into the project folder and issuing py -m jigsawwm.w32.hook. This is what I get for the specific key presses:
for a capital "L" I press <SHIFT> + <L> . In the console I get...
RSHIFT WM_KEYDOWN : vkCode a1 scanCode 36 flags: 1, time: 29816906 extra: 0
L WM_KEYDOWN : vkCode 4c scanCode 26 flags: 0, time: 29817031 extra: 0
L WM_KEYUP : vkCode 4c scanCode 26 flags: 128, time: 29817234 extra: 0
RSHIFT WM_KEYUP : vkCode a1 scanCode 36 flags: 129, time: 29817281 extra: 0
for a "BACKSLASH" I press <R-ALT> + <SZLIG> as seen before...
LCONTROL WM_SYSKEYDOWN : vkCode a2 scanCode 21d flags: 32, time: 29490734 extra: 0
RMENU WM_SYSKEYDOWN : vkCode a5 scanCode 38 flags: 33, time: 29490734 extra: 0
OEM_4 WM_SYSKEYDOWN : vkCode db scanCode c flags: 32, time: 29491171 extra: 0
OEM_4 WM_SYSKEYUP : vkCode db scanCode c flags: 160, time: 29491281 extra: 0
LCONTROL WM_KEYUP : vkCode a2 scanCode 21d flags: 128, time: 29491546 extra: 0
RMENU WM_KEYUP : vkCode a5 scanCode 38 flags: 129, time: 29491546 extra: 0
for a "[]" (opening and closing square brackets) I hold <R-ALT> and press <8> then <9>...
LCONTROL WM_SYSKEYDOWN : vkCode a2 scanCode 21d flags: 32, time: 29649187 extra: 0
RMENU WM_SYSKEYDOWN : vkCode a5 scanCode 38 flags: 33, time: 29649187 extra: 0
KEY_8 WM_SYSKEYDOWN : vkCode 38 scanCode 9 flags: 32, time: 29649578 extra: 0
KEY_8 WM_SYSKEYUP : vkCode 38 scanCode 9 flags: 160, time: 29649656 extra: 0
KEY_9 WM_SYSKEYDOWN : vkCode 39 scanCode a flags: 32, time: 29649906 extra: 0
KEY_9 WM_SYSKEYUP : vkCode 39 scanCode a flags: 160, time: 29650046 extra: 0
LCONTROL WM_KEYUP : vkCode a2 scanCode 21d flags: 128, time: 29650218 extra: 0
RMENU WM_KEYUP : vkCode a5 scanCode 38 flags: 129, time: 29650218 extra: 0
when I press and release the single key <R-ALT>, I see...
LCONTROL WM_SYSKEYDOWN : vkCode a2 scanCode 21d flags: 32, time: 30392812 extra: 0
RMENU WM_SYSKEYDOWN : vkCode a5 scanCode 38 flags: 33, time: 30392812 extra: 0
LCONTROL WM_KEYUP : vkCode a2 scanCode 21d flags: 128, time: 30393078 extra: 0
RMENU WM_KEYUP : vkCode a5 scanCode 38 flags: 129, time: 30393078 extra: 0
So, the problem does not seem to have a relation to "BACKSLASH" at all. But rather the <R-ALT> key:
- it misteriously triggers a
LCONTROL down, then aRMENU down(which seems to be the<R-ALT>) - when releasing all keys, the release order for
LCONTROLandRMENUseems inverted, here - and in my former example,
LCONTROLwas not even released.
According to https://en.wikipedia.org/wiki/AltGr_key#Ctrl+Alt , AltGr is an equivalent of Ctrl + Alt, I think it makes sense for the console to output sth like that. So, if i understand it correctly:
-
\and[]can be entered as expected when typing casually. -
LControlwas not released when typing fast withASDFbefore entering\or any other symbols that involveAltGr
Am I correct?
PS: nice keyboard there.
Interesting.
\and[]can be entered as expected when typing casually
yes, those keys are presented on the text input when generated using <ALTGR> with the appropriate key.
LControlwas not released when typing fast withASDFbefore entering\or any other symbols that involve<AltGr>
correct. LControl seems to have been swallowed, looking at the keyboard debug trace.
I just tried to generate \ by pressing <LCONTROL> + <ALT> + <SZLIG> (not using <ALTGR>), as seen in the link you posted about alternative key presses for <ALTGR>. I see that \ gets NOT displayed. So, it seems that <LCONTROL> + <ALT> is not a reliable replacement for <ALTGR>. If the low-level keyboard implementation could forward the "real" <ALTGR>, not the alternative <LCONTROL> + <ALT> the problem might be solved.
What do you think?
@nnako
The way I see it , the AltGr events are being forwarded correctly so \ and [] popped out in your input textbox without problem. To clarify, the low-level keyboard implementation doesn't do anything for AltGr events, in fact, whatever you saw on the console were the events that hook.py received from the OS, in other words, the OS generates the following events when you press AltGr
LCONTROL WM_SYSKEYDOWN : vkCode a2 scanCode 21d flags: 32, time: 30392812 extra: 0
RMENU WM_SYSKEYDOWN : vkCode a5 scanCode 38 flags: 33, time: 30392812 extra: 0
LCONTROL WM_KEYUP : vkCode a2 scanCode 21d flags: 128, time: 30393078 extra: 0
RMENU WM_KEYUP : vkCode a5 scanCode 38 flags: 129, time: 30393078 extra: 0
I think it was caused by the F(LControl when held) and AltGr being pressed simultaneously. Can you reproduce the phenomenon stably?
Hi @klesh ,
The way I see it , the
AltGrevents are being forwarded correctly so\and[]popped out in your input textbox without problem.
This is only the case when I haven't started wm.pyw. So, in normal operation (without interception by JigsawWM), the keys \ and [] appear as usual within whatever currently active text editor. Even when the low-level key debugger (started in some terminal via py -m jigsawwm.w32.hook is running, the "normal" behaviour is seen. But as soon as I start JigsawWM (in my case via python .\examples\wm.pyw, the chars \ and [] don't appear on the input row as seen in the screen recordings. And the WM_KEYUP event for LCONTROL is missing (not visible in the key debugger running in parallel) after pressing and releasing any key and <ALTGR>.
here another video:
https://github.com/klesh/JigsawWM/assets/5845602/ed9f7b95-c306-4fce-b092-0e4cc95b9066
Hi @klesh ,
The way I see it , the
AltGrevents are being forwarded correctly so\and[]popped out in your input textbox without problem.This is only the case when I haven't started
wm.pyw. So, in normal operation (without interception by JigsawWM), the keys\and[]appear as usual within whatever currently active text editor. Even when the low-level key debugger (started in some terminal viapy -m jigsawwm.w32.hookis running, the "normal" behaviour is seen. But as soon as I start JigsawWM (in my case viapython .\examples\wm.pyw, the chars\and[]don't appear on the input row as seen in the screen recordings. And theWM_KEYUPevent forLCONTROLis missing (not visible in the key debugger running in parallel) after pressing and releasing any key and<ALTGR>.here another video:
odd_keyboard_behavior_in_neovim_app__02__rf32.mp4
Aah, I see. Thanks for the clarification.
I just updated the main branch, please see if it fixes your problem.
Hi @klesh , thanks for the fix.
Unfortunately, it does not yet work quite well, as a LCONTROL seems to still be halted (active). Please see the new video:
https://github.com/klesh/JigsawWM/assets/5845602/b06b4c1e-a4aa-49c1-b0bc-ad62046debae
Some further explanation of the effect that is seen on the video:
- after pressing
<ALTGR> + <SZLIG>, the correctBACKSLASHcharacter is created within the editor - the debugging states an additional
LCONTROLKEYUP, which seems odd as it was already said two debug lines before. I would (for the visible effect) have at least expected aLCONTROLKEYDOWN. - the
LCONTROLis still pressed, though, as seen in the shift operations within the editor - after pressing and releasing the
<WIN>key, the haltedLCONTROLseems to be healed again
yeah, the extra LControl UP event is undesirable, I can reproduce it on my PC, seems like the OS would produce an extra LControl UP event for whatever reason.
However, an extra UP event should not be causing any problems... weird 😂
Hi @klesh , could it be that this was a real operating system problem? I recall these hanging CONTROL keys from other issues within other similar projects (e.g. within the "keyboard" module). In my opinion, we (on the non-system-development side) would only have a few options:
- spot the cause of our issue as close as possible and then hand it over to Microsoft's support ;-)
- for the time being, try to provide a workaround by identifying this hanging
CONTROLkey (maybe, there is a list of active keys where this hanging key would be visible?), make it plausible as actually "hanging", and then neutralize it (I achieved it by pressing<WIN>). - try to figure out what workaround other projects have found to cope with it. There is a project named ahk which is a wrapper around the AutoHotKey project, thus providing a Python interface as a replacement for the "cryptic" AHK syntax of the original project. I tried that one some weeks ago and I haven't encountered our issue concerning "hanging keys", yet.
what do you think?
@nnako Yup, they all make sense to me... The problem is that I couldn't reproduce the hanging Control key on my PC with German keyboard layout... I need a stable way to reproduce the bug before I can fix it.
Maybe, I could try to fix it on my side. But I would need your help in navigating me through your code until I have gained some confidence with it. Please see my attached structure diagram. It tries to describe "how the information flows"
- from the physical keyboard
- through the operating system layers (visible as OS events for us)
- then through your source code files
- until their end points (applications like text editors)
As soon as this diagram resembles the "real" world, fixing those problems would become much easier for me, I guess.
Nice, you got it pretty much correct except for the jmk module, it is more like the following:
-
SystemInputintercepts related events and sends them to theJmkCore -
JmkCoreinterprets and transforms events based on the configuration (TapHold and Key, etc.) and sends them to theJmkHotkey -
JmkHotkeychecks if the registered hotkeys should be fired or redirect events to theSystemOutput -
SystemOutputsimply callssendinputto send kbd/mouse events to the OS
Hi @klesh , thanks for your feedback. I updated the drawing a bit. Please note the following:
- the abstraction level is a bit higher than the class level, so that the technical implementation is only structured using the source files. not the classes within files. I think, it makes the first-understanding without too many details much easier than class diagrams.
- the blue arrow heads tell the reader where information is "generated" or "actively read" / polled. so, they are located at tools, scripts, filters and hardware components.
- the green connection lines show where user information (in our case, keyboard events) flow.
- the dashed black lines carry other trigger or configuration information between the participants.
Yup, it looks good to me.