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

[Raffael Stocker]

Eli Zaretskii <eliz@gnu.org> writes:

> It would be better to have some independent verification that this is
> what happens.  Is there any way to find out whether the hook was
> removed, even from outside of Emacs?

MS say there is no direct way.  But for debugging it might be possible
to produce some output whenever the hook is called, if that is missing,
we would know.

> I find it hard to believe that
> we could miss the 200-ms deadline on modern systems.  Are your systems
> heavily loaded at times?  What kind of CPU do you have on those
> systems?  Emacs can hog CPU with only a single thread, so if your
> systems have a reasonably modern CPU, Windows should have plenty of
> execution units to spread any additional load without preempting
> Emacs.

It (also) happens when the systems are basically idle, with only some
keyboard input.  The systems are also relatively new (Intel i7 or i5
from a few years ago).

> Another idea is to add code to Emacs that measures the time it takes
> Emacs to produce the WM_KEYUP event, and log some message if that
> takes more than some threshold.

I have managed to set up a build environment on one of the machines and
I will try to experiment with this in the coming weeks. Perhaps I can
find out more.

>> - 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?
>
> According to the MS documentation, the hook is called by sending a
> message to the thread that installed the hook, which in our case is
> already a separate thread, not the main Lisp thread (which is likely
> to be busy at times).  The thread which handles the hook callbacks is
> the input thread, which is relatively light-weight and shouldn't be
> too busy.

We saw the correlation with working on a network share and IIUC Windows
Defender blocks a process/thread while writing (or only closing?) a
file.  Therefore my suspicion.  But if saving files is not done in the
same thread as input, that can't be it...

>> - Can we put the workaround described above (with the LowLevelHooksTimeout
>>   value) into the Emacs documentation so it is findable?
>
> Please suggest the text to put in the manual to document this.

I attached a patch that adds a paragraph to the “Windows Keyboard” section.

>> 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?
>
> I'm not an expert, but this code was working for years.  However, you
> could try making the change you propose and see if that solves the
> problem (or causes new ones).

I'll give it a try.

Regards,
Raffael

0001-Document-workaround-for-a-stuck-Windows-key-on-MS-Wi.patch
Description: msdos.texi patch