From: Raffael Stocker <r.stocker@mnet-mail.de>
To: 68914@debbugs.gnu.org
Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys
Date: Sat, 03 Feb 2024 21:45:46 +0100 [thread overview]
Message-ID: <yplmh6iptchv.fsf@mnet-mail.de> (raw)
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
next reply other threads:[~2024-02-03 20:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-03 20:45 Raffael Stocker [this message]
2024-02-04 6:31 ` bug#68914: Windows makes Emacs choke on and swallow the WIN keys Eli Zaretskii
2024-02-04 13:02 ` Raffael Stocker
2024-02-04 14:14 ` Eli Zaretskii
2024-02-12 20:13 ` Raffael Stocker
2024-02-04 13:32 ` Nikolay Kudryavtsev
2024-02-04 13:56 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yplmh6iptchv.fsf@mnet-mail.de \
--to=r.stocker@mnet-mail.de \
--cc=68914@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).