bug#68914: Windows makes Emacs choke on and swallow the WIN keys

[Raffael Stocker]

Hi,

this is a weird one (and long, apologies).  On MS Windows, it sometimes
happens that a windows key gets stuck, that is, it remains (logically)
pressed down, and this behaviour is correlated with Emacs use.  A
colleague and I are seeing this on two installations with Emacs 28.2 and
29.2 on Windows 10 and 11.  Unfortunately, this is somewhat random and
we have not found a way to trigger it directly.

Emacs implements WIN key handling using the low level keyboard API in
the ‘funhook’ callback function in ‘src/w32fnc.c’.  Microsoft write
about this hook that the application must handle the hook within some
timeout.  If it doesn't, the hook is silently removed [0]:

MS> The hook procedure should process a message in less time than the data
MS> entry specified in the LowLevelHooksTimeout value in the following
MS> registry key:
MS> 
MS> HKEY_CURRENT_USER**\**Control Panel**\**Desktop
MS> 
MS> The value is in milliseconds. If the hook procedure times out, the
MS> system passes the message to the next hook. However, on Windows 7
MS> and later, the hook is silently removed without being called. There
MS> is no way for the application to know whether the hook is removed.
MS> 
MS> Windows 10 version 1709 and later The maximum timeout value the
MS> system allows is 1000 milliseconds (1 second). The system will
MS> default to using a 1000 millisecond timeout if the
MS> LowLevelHooksTimeout value is set to a value larger than 1000.

It seems that this might be what happens to Emacs.  Possibly Windows
removes the keyboard hook due to a timeout, not giving Emacs a chance to
produce a ‘WM_KEYUP’ event.  And it seems to be correlated with working
on Windows network shares; we also have Windows Defender active, which
might make matters worse by slowing Emacs down while it is writing to a
file.

We have had good results with increasing the ‘LowLevelHooksTimeout’, but
we had to set it to the maximum value of 1000 ms.  I am not sure about
the default value; the internet claims it to be 200 ms.  A mid-range
value (500 ms) alleviated the problem somewhat, but it seems to require
the maximum to vanish, at least judging by a limited experience of a few
days of observation.

I am not sure there is an Emacs bug at all here, but I think it warrants
some investigation:

- Might it be possible to find a way to trigger this behaviour using a
  debugger?  Unfortunately, I can neither compile nor debug on the
  Windows machines (company computers with limited usefulness...).
- If Emacs being too slow somewhere is indeed the problem, can it be
  sped up, maybe by putting the slow stuff in a different thread than
  the low level keyboard handling?
- Can we put the workaround described above (with the LowLevelHooksTimeout
  value) into the Emacs documentation so it is findable?

In related news, I noticed that the input events constructed in
‘funhook’ seem to use incorrect scan codes, for example starting at line
2630 in w32fns.c:

--8<---------------cut here---------------start------------->8---
inputs[0].type = INPUT_KEYBOARD;
inputs[0].ki.wVk = hs->vkCode;
inputs[0].ki.wScan = hs->vkCode;
inputs[0].ki.dwFlags = KEYEVENTF_EXTENDEDKEY;
inputs[0].ki.time = 0;
inputs[1].type = INPUT_KEYBOARD;
inputs[1].ki.wVk = hs->vkCode;
inputs[1].ki.wScan = hs->vkCode;
inputs[1].ki.dwFlags
= KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP;
inputs[1].ki.time = 0;
--8<---------------cut here---------------end--------------->8---

This sets both ki.wVk and ki.wScan to the virtual-key code (0x5B for
VK_LWIN), but the ‘KEYEVENTF_EXTENDEDKEY’ flag is set, which IIUC would
require adding ‘0xE0’ to the virtual-key code to obtain the scan code,
e.g. 0xE05B for LWIN [1].  Can this cause any (additional) problems?

And, BTW, why is the callback called ‘funhook’?  Using the Windows low
level keyboard API doesn't seem to be much fun and I can't see anyone
get hooked on this either.

Regards,
Raffael

[0] https://learn.microsoft.com/en-us/windows/win32/winmsg/lowlevelkeyboardproc
[1] 
https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-keybdinput