From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Raffael Stocker Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Feb 2024 22:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 68914@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.170699893932542 (code B ref -1); Sat, 03 Feb 2024 22:23:02 +0000 Received: (at submit) by debbugs.gnu.org; 3 Feb 2024 22:22:19 +0000 Received: from localhost ([127.0.0.1]:47196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWOOw-0008Sn-I8 for submit@debbugs.gnu.org; Sat, 03 Feb 2024 17:22:18 -0500 Received: from lists.gnu.org ([2001:470:142::17]:41538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWOOt-0008SU-5b for submit@debbugs.gnu.org; Sat, 03 Feb 2024 17:22:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWOOb-00083u-RY for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2024 17:21:57 -0500 Received: from mail-out.m-online.net ([212.18.0.9]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWOOZ-0000V1-Le for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2024 17:21:57 -0500 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4TS6Z612Z9z1qsP9 for ; Sat, 3 Feb 2024 23:21:50 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 4TS6Z60qNWz1qqlS for ; Sat, 3 Feb 2024 23:21:50 +0100 (CET) X-Virus-Scanned: amavis at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024) with ESMTP id GtXh4AJphJhK for ; Sat, 3 Feb 2024 23:21:49 +0100 (CET) X-Auth-Info: LynUtpxjqMkSm2J+cQgTVuMV+uU2ysFDqGBSW2qvQJ/XMiIpSvvIkaoPmsYw+1La Received: from Whiteflame (ppp-212-114-182-115.dynamic.mnet-online.de [212.114.182.115]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA for ; Sat, 3 Feb 2024 23:21:49 +0100 (CET) User-agent: mu4e 1.10.8; emacs 29.2 From: Raffael Stocker Date: Sat, 03 Feb 2024 21:45:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=212.18.0.9; envelope-from=r.stocker@mnet-mail.de; helo=mail-out.m-online.net X-Spam_score_int: -5 X-Spam_score: -0.6 X-Spam_bar: / X-Spam_report: (-0.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URI_TRY_3LD=1.997 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 3.0 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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 [...] Content analysis details: (3.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 T_SCC_BODY_TEXT_LINE No description available. 2.0 URI_TRY_3LD "Try it" URI, suspicious hostname X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 =E2=80=98funhook=E2=80=99 callback function in =E2=80=98src/w32fnc.c=E2= =80=99. 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>=20 MS> HKEY_CURRENT_USER**\**Control Panel**\**Desktop MS>=20 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>=20 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 =E2=80=98WM_KEYUP=E2=80=99 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 =E2=80=98LowLevelHooksTimeout= =E2=80=99, 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 =E2=80=98funhook=E2=80=99 seem to use incorrect scan codes, for example sta= rting at line 2630 in w32fns.c: --8<---------------cut here---------------start------------->8--- inputs[0].type =3D INPUT_KEYBOARD; inputs[0].ki.wVk =3D hs->vkCode; inputs[0].ki.wScan =3D hs->vkCode; inputs[0].ki.dwFlags =3D KEYEVENTF_EXTENDEDKEY; inputs[0].ki.time =3D 0; inputs[1].type =3D INPUT_KEYBOARD; inputs[1].ki.wVk =3D hs->vkCode; inputs[1].ki.wScan =3D hs->vkCode; inputs[1].ki.dwFlags =3D KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP; inputs[1].ki.time =3D 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 =E2=80=98KEYEVENTF_EXTENDEDKEY=E2=80=99 flag is set, whic= h IIUC would require adding =E2=80=980xE0=E2=80=99 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 =E2=80=98funhook=E2=80=99? 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/lowlevelkeyboard= proc [1] https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-= keybdinput From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Feb 2024 06:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Raffael Stocker Cc: 68914@debbugs.gnu.org Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.170702829920218 (code B ref 68914); Sun, 04 Feb 2024 06:32:02 +0000 Received: (at 68914) by debbugs.gnu.org; 4 Feb 2024 06:31:39 +0000 Received: from localhost ([127.0.0.1]:48077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWW2V-0005G1-9D for submit@debbugs.gnu.org; Sun, 04 Feb 2024 01:31:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWW2S-0005Fl-QV for 68914@debbugs.gnu.org; Sun, 04 Feb 2024 01:31:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWW2A-0008Ur-Sc; Sun, 04 Feb 2024 01:31:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=YbOoHVVyrOCC5i5yr4zlclxX35xVGI0rwtGBdvFOJH0=; b=SDzpDD4BOpb/jl33o3/U xwdn7qccIvtkCAgtXu7FWA5c8In+zXhwqpqNiI+2TPcVnfh5WAdPAeApihqFpOybCjIoNWde1vtMT ybpwE/qtN9D7Y/arCy/YxZJPDuiRiCTW5rtX2JJKFUlnrDKg9eHpWlm5YFGV1WmuLalt7dzFeKAvh JWkJFL+0fO0gjxS7tW9620F5ixpyy9Oqa7BVrdyiWd0kI3K9O5TePjXkqWBXBi2sLi27bQJd8Co4O DyMGbVqF1yXgiR45iiUtZxzA0kkWbDtbaEZBWRmTg7Bx+RlGpBFn0Vt1OugFRLWrBeVQ0S7xcKpZd 9jxKqontNuS1Lg==; Date: Sun, 04 Feb 2024 08:31:15 +0200 Message-Id: <86mssg3fm4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Raffael Stocker on Sat, 03 Feb 2024 21:45:46 +0100) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Raffael Stocker > Date: Sat, 03 Feb 2024 21:45:46 +0100 > > 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. 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? 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. 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. > - 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...). That's probably tricky, given the time constraints. > - 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. > - 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. > 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? 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). > 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. I think this question is for the author of the code. I'm not sure he is reading this. There's nothing wrong with the name from my POV. Thanks. From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Raffael Stocker Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Feb 2024 13:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 68914@debbugs.gnu.org Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.170705255530472 (code B ref 68914); Sun, 04 Feb 2024 13:16:01 +0000 Received: (at 68914) by debbugs.gnu.org; 4 Feb 2024 13:15:55 +0000 Received: from localhost ([127.0.0.1]:48412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWcLi-0007vP-Nb for submit@debbugs.gnu.org; Sun, 04 Feb 2024 08:15:55 -0500 Received: from mail-out.m-online.net ([212.18.0.9]:52224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWcLg-0007vC-5z for 68914@debbugs.gnu.org; Sun, 04 Feb 2024 08:15:53 -0500 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4TSVPQ5KZ6z1qsPQ; Sun, 4 Feb 2024 14:15:38 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 4TSVPQ4CB5z1qqlS; Sun, 4 Feb 2024 14:15:38 +0100 (CET) X-Virus-Scanned: amavis at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024) with ESMTP id 3HfmO4VOuHCr; Sun, 4 Feb 2024 14:15:37 +0100 (CET) X-Auth-Info: 1NcffMxGd9NO9XGcY0bewBQlbJESTebTDTI3HMZ6TJ8vlSThgY3ZAThKZOo5krs0 Received: from Whiteflame (ppp-212-114-182-115.dynamic.mnet-online.de [212.114.182.115]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Sun, 4 Feb 2024 14:15:37 +0100 (CET) References: <86mssg3fm4.fsf@gnu.org> User-agent: mu4e 1.10.8; emacs 29.2 From: Raffael Stocker Date: Sun, 04 Feb 2024 14:02:02 +0100 In-reply-to: <86mssg3fm4.fsf@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii 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 LowLevelHooksTimeo= ut >> 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 =E2=80=9CWindows Keyboard= =E2=80=9D section. >> This sets both ki.wVk and ki.wScan to the virtual-key code (0x5B for >> VK_LWIN), but the =E2=80=98KEYEVENTF_EXTENDEDKEY=E2=80=99 flag is set, w= hich IIUC would >> require adding =E2=80=980xE0=E2=80=99 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 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Document-workaround-for-a-stuck-Windows-key-on-MS-Wi.patch Content-Description: msdos.texi patch >From d227643ab02d8cf8b955df4034c6c00219a0cbc1 Mon Sep 17 00:00:00 2001 From: Raffael Stocker Date: Sun, 4 Feb 2024 13:41:28 +0100 Subject: [PATCH] Document workaround for a stuck Windows key on MS-Windows (bug#68914) * doc/emacs/msdos.texi (Windows Keyboard): describe workaround --- doc/emacs/msdos.texi | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/doc/emacs/msdos.texi b/doc/emacs/msdos.texi index 861c0d90dc6..1c633adde65 100644 --- a/doc/emacs/msdos.texi +++ b/doc/emacs/msdos.texi @@ -697,6 +697,16 @@ Windows Keyboard its normal effect: for example, @kbd{@key{Lwindow}} opens the @code{Start} menu, etc. +@cindex Windows key getting stuck (MS-Windows) + Some users experience the Windows key getting ``stuck'' while Emacs is +running, that is, Windows behaves as if the key were permanently pressed +down. This may happen even when no Emacs frame is focussed. If you see +this behavior, you can try setting the variable +@code{LowLevelHooksTimeout} in the registry key +@samp{HKEY_CURRENT_USER\Control Panel\Desktop} to a higher value, adding +it if it does not yet exist. The default value is 200 ms, and it can be +increased to up to 1000 ms. + @vindex w32-recognize-altgr @kindex AltGr @r{(MS-Windows)} @cindex @key{AltGr} key (MS-Windows) -- 2.43.0 --=-=-=-- From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Nikolay Kudryavtsev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Feb 2024 13:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Raffael Stocker , 68914@debbugs.gnu.org Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.170705359332289 (code B ref 68914); Sun, 04 Feb 2024 13:34:02 +0000 Received: (at 68914) by debbugs.gnu.org; 4 Feb 2024 13:33:13 +0000 Received: from localhost ([127.0.0.1]:48430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWccS-0008Oi-T3 for submit@debbugs.gnu.org; Sun, 04 Feb 2024 08:33:13 -0500 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:49513) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWccP-0008OS-C6 for 68914@debbugs.gnu.org; Sun, 04 Feb 2024 08:33:11 -0500 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5111e5e4e2bso5549680e87.3 for <68914@debbugs.gnu.org>; Sun, 04 Feb 2024 05:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707053571; x=1707658371; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=QjED7NEkTzWEId1Cf6oiJ+LnSWDDCxr9uTDSCsbbPbA=; b=ZoLv79Ywn973w/avlB5hpFmxk7BGlBLKpjbWALw5BBBCXPpWorr0JimyEmHuTV6q5a vwbk4PypyvpxG3gKnRvsn7VtBm/fotmJUXbK1x1bxShCDANvaBj21YARN5WBnzxhIABf Lpe6Dr9z6/zbtmSP5cOvXMS9I8b4BDr3sCL38qv6ZvLqHVWfs1qFkR0avSG2Ff5DiO2g NMZ2ZhUt6l0SQlh0SBLoiq4EsG5rL1klxL/dgmh1zwUZEioEkA9JzPiItBbfKoaMvpmj IKb0h6Hl5ffU5lcjqRnKRovOWaNxYA+dQO+PJ8W8W1ldJpg91RUflCR9iWl98QArTLAJ SfyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707053571; x=1707658371; h=content-transfer-encoding:in-reply-to:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QjED7NEkTzWEId1Cf6oiJ+LnSWDDCxr9uTDSCsbbPbA=; b=eP+pSlRkCAvyKBcmrQ1Qa0EeMs06BKJV6KbwlqLzo/YsGiEjBviYJbxVcfl5+T4Bn0 hKx0X+hTV5pTxRy1pW1P52VZ5fWjUQH7Fu3F/YNj4gefEmVI4yjJb2ol2Z44oB2GMQO4 EEN+Ki2mYuFEB3nG+hLAAniLMLU9NYMgeOU6oqClNlAdQo5zOIUa5VSoEYyVQ5SqN156 zgwmUTa0A/z2fm8zsOJqlUzScCdY3H8vOgZHsi9vGsa12JWLa2Q62DhNhC5vFQHEVF1S UQikz6Py2BYrYVGaeEiQk5WkXU8d/2o85OyJ7nsOVVZ8qt2NlDbgPhdmyAT17bjlN5Zq UVWg== X-Gm-Message-State: AOJu0Yz5yscfdu0z5H1tHZfXJITOqkAeG+dQKaH+c0ARP8dl8HoLSwmK YoPvG5928IHs/oC3NM/VU7vxeocMEnmPQKo7VinZKdH6KKCgNIrQ X-Google-Smtp-Source: AGHT+IEf8ezDAI/ek+JP0HIX+DcR0JB0tPQx9u9pdxOeygg8GMGuzByaKU5x0GNiSZ9KLpC50C3DAA== X-Received: by 2002:a19:f605:0:b0:511:3b8b:6eb2 with SMTP id x5-20020a19f605000000b005113b8b6eb2mr2903621lfe.42.1707053571055; Sun, 04 Feb 2024 05:32:51 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUXjY+QZqOi1Air+916u1mFRVmYDONqYD63BriPC9HwUdZsNVdU+cFMJXQdyQQ3ohf24UXxgWi775XeVT6GQr1sc6HboPQ= Received: from ?IPV6:2a02:2168:b3fc:9700:2991:4f30:ddb4:6ec7? ([2a02:2168:b3fc:9700:2991:4f30:ddb4:6ec7]) by smtp.gmail.com with ESMTPSA id t10-20020a19910a000000b005114b8b2aaesm231156lfd.117.2024.02.04.05.32.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Feb 2024 05:32:50 -0800 (PST) From: Nikolay Kudryavtsev X-Google-Original-From: Nikolay Kudryavtsev Message-ID: <08fd4dda-576f-48a7-aa04-5c24135d21ba@gmail.com> Date: Sun, 4 Feb 2024 16:32:48 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: ru, en-US References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello. I think I've seen this bug in the wild a couple of times too. But there's something else. I'm not sure if it's the same bug, but something's been iffy about Emacs keyboard input handling on Windows for the last few major versions. Unfortunately I've yet to find a simple reproduction recipe and hence why I haven't filled that one the tracker. The problem is as follows. I use a certain piece of software that switches between keyboard layouts by CAPS LOCK. So CAPS LOCK, the feature, is normally mostly inactive on my machine and requires a certain other combination to activate. Emacs normally respects that. Except when it's under a load running lisp code. During that time there are time intervals during which pressing CAPS LOCK would incorrectly set it on for me. One way I can reliably reproduce this is by doing M-x list-packages and then tapping CAPS LOCK. At some point it would light up. Thus I believe that the input handling intermittently breaks during the high load(lisp evaluation). My testing had shown that the last version that does not suffer from this is Emacs 25. Just posting this in case it's the same problem and this information is of any use in debugging. From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Feb 2024 13:57:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nikolay Kudryavtsev Cc: r.stocker@mnet-mail.de, 68914@debbugs.gnu.org Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.17070550172336 (code B ref 68914); Sun, 04 Feb 2024 13:57:03 +0000 Received: (at 68914) by debbugs.gnu.org; 4 Feb 2024 13:56:57 +0000 Received: from localhost ([127.0.0.1]:48466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWczQ-0000bc-Qk for submit@debbugs.gnu.org; Sun, 04 Feb 2024 08:56:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWczP-0000bR-T5 for 68914@debbugs.gnu.org; Sun, 04 Feb 2024 08:56:56 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWcz7-0005k5-7A; Sun, 04 Feb 2024 08:56:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=tomt7q/pxpQixvQdNN9daajBuaSMMRMkhhTgKmD9oJU=; b=OR74oFVrcYSx173CuKs+ pWdukA/TtK6CIlTARW+IC4GbH0sIsKW/MQ8ftItnxaLb92atCfYkXTYxvYk2baANwM9ClwNWr0OtG OtoqRIyGczt1mY3gAdDhwfzTwhhoAStsAj1EU291/46BKiKdUJZVgARIyqHLoQIpGnDCDFGjkWgzr sSkX5A1OI1WqMpOOdicTeKoDfDargDLJp00jPRcdTL8IjpCrOEPVhq2u/T9XgZS5uWJa4pkcYugYM mNKlpW6gdBT0gpLr3MMRduVMdsKSNTynqaO5RoHa74kV5kWVd29Moq1BKjmw8HIT6n+5l95jJ2IP2 hHhU7ilJCbVgiA==; Date: Sun, 04 Feb 2024 15:56:31 +0200 Message-Id: <867cjk2v00.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <08fd4dda-576f-48a7-aa04-5c24135d21ba@gmail.com> (message from Nikolay Kudryavtsev on Sun, 4 Feb 2024 16:32:48 +0300) References: <08fd4dda-576f-48a7-aa04-5c24135d21ba@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Nikolay Kudryavtsev > Date: Sun, 4 Feb 2024 16:32:48 +0300 > > But there's something else. I'm not sure if it's the same bug, but > something's been iffy about Emacs keyboard input handling on Windows for > the last few major versions. I don't think it's the same issue. I suggest submitting a separate bug report with the details. > Unfortunately I've yet to find a simple reproduction recipe and hence > why I haven't filled that one the tracker. The problem is as follows. > > I use a certain piece of software that switches between keyboard layouts > by CAPS LOCK. So CAPS LOCK, the feature, is normally mostly inactive on > my machine and requires a certain other combination to activate. Emacs > normally respects that. Except when it's under a load running lisp code. > During that time there are time intervals during which pressing CAPS > LOCK would incorrectly set it on for me. > > One way I can reliably reproduce this is by doing M-x list-packages and > then tapping CAPS LOCK. At some point it would light up. In the bug report I suggest to submit, please describe in more detail how to reproduce this using list-packages. How to "tap CAPS LOCK" and what to look for while doing that. I just tried naïvely to reproduce that and didn't see any problems, probably because I didn't know where to look. > Thus I believe that the input handling intermittently breaks during the > high load(lisp evaluation). > > My testing had shown that the last version that does not suffer from > this is Emacs 25. Emacs 26 introduced the low-level keyboard hook. From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Feb 2024 14:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Raffael Stocker Cc: 68914@debbugs.gnu.org Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.17070561224036 (code B ref 68914); Sun, 04 Feb 2024 14:16:01 +0000 Received: (at 68914) by debbugs.gnu.org; 4 Feb 2024 14:15:22 +0000 Received: from localhost ([127.0.0.1]:48474 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWdHF-000132-M5 for submit@debbugs.gnu.org; Sun, 04 Feb 2024 09:15:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWdHA-00012k-Su for 68914@debbugs.gnu.org; Sun, 04 Feb 2024 09:15:21 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWdGt-0008HH-4q; Sun, 04 Feb 2024 09:14:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=rod+OXEUTV87sntcaBsbsTVyJ8WxnkigrEf2CpcW4/Q=; b=IiGgAVxSuM3wipVO6FIu aUfvUFxveIpjEiAFSn3eVmLRnk7ahWR1heIHV/61DJr+TRQB20TLQ256LV6Q0UVSdnaVejNgGUL9Y Z6RyLCQ6G/+cqVEf5v8EJiSQ9zBtBkku4Tv7/OWdQYiPCd3udOMTBOUpUG/UdZvdwJkg6rWCpCy51 Tez3pa8atPFQcJi0v7zVucE+WPC1ePFhII0PxjOIvmK1ktVkDPsN7ysOnpWgpKiW7uqhx9KYVodVk ogylaV/ZX8ZqbccTQGRmdXzdLpot5Y26IQWpJNqBUz8cMW+YukXI/r9ycExYQMx8aZ3SWS/00QKCL kEVVt0xC8T51tA==; Date: Sun, 04 Feb 2024 16:14:57 +0200 Message-Id: <865xz42u5a.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Raffael Stocker on Sun, 04 Feb 2024 14:02:02 +0100) References: <86mssg3fm4.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Raffael Stocker > Cc: 68914@debbugs.gnu.org > Date: Sun, 04 Feb 2024 14:02:02 +0100 > > > 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. That could be a good solution, yes. > > 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). That's even weirder. > > 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. Thanks. > >> - 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... Our input thread doesn't write to any files, not in our code anyway. It just runs the message pump and little else. > >> - 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. On second thought, I think this kind of problems are better described in etc/PROBLEMS, so I have now added something there with the description of the problem and the workaround/ From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Raffael Stocker Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Feb 2024 20:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 68914@debbugs.gnu.org Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.170777132422121 (code B ref 68914); Mon, 12 Feb 2024 20:56:01 +0000 Received: (at 68914) by debbugs.gnu.org; 12 Feb 2024 20:55:24 +0000 Received: from localhost ([127.0.0.1]:58455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rZdKk-0005ka-BE for submit@debbugs.gnu.org; Mon, 12 Feb 2024 15:55:23 -0500 Received: from mail-out.m-online.net ([212.18.0.9]:58560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rZd7L-0004dI-09 for 68914@debbugs.gnu.org; Mon, 12 Feb 2024 15:41:32 -0500 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4TYbvr5KN1z1r2Zb; Mon, 12 Feb 2024 21:41:12 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 4TYbvr3V9jz1qqlS; Mon, 12 Feb 2024 21:41:12 +0100 (CET) X-Virus-Scanned: amavis at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024) with ESMTP id OMeCC0E0w531; Mon, 12 Feb 2024 21:41:11 +0100 (CET) X-Auth-Info: IOWg63HDI62cbqhiPuinPqXJRBFLUR+BrvhJC82QCaPYtP90EF3XnuOueWPfGQNk Received: from Whiteflame (ppp-212-114-182-193.dynamic.mnet-online.de [212.114.182.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Mon, 12 Feb 2024 21:41:11 +0100 (CET) References: <86mssg3fm4.fsf@gnu.org> <865xz42u5a.fsf@gnu.org> User-agent: mu4e 1.10.8; emacs 29.2 From: Raffael Stocker Date: Mon, 12 Feb 2024 21:13:27 +0100 In-reply-to: <865xz42u5a.fsf@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I have added debug output to the keyboard hook (see the attached patch) and was able to observe the bug while Emacs was unresponsive (either because the current master is iffy on Windows or because of [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [212.114.182.193 listed in zen.spamhaus.org] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [212.18.0.9 listed in list.dnswl.org] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [212.18.0.9 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I have added debug output to the keyboard hook (see the attached patch) and was able to observe the bug while Emacs was unresponsive (either because the current master is iffy on Windows or because of [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [212.114.182.193 listed in zen.spamhaus.org] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [212.18.0.9 listed in wl.mailspike.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [212.18.0.9 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have added debug output to the keyboard hook (see the attached patch) and was able to observe the bug while Emacs was unresponsive (either because the current master is iffy on Windows or because of my output...). The locked windows key problem seems to appear when an s- combination is pressed. Normal debug output looks like this: --8<---------------cut here---------------start------------->8--- KEYDOWN 0x5b, 0x5b: 0.0018 ms Simulated S-x combination: 0.647 ms KEYUP received, winsdown: 1, w: 0x101 no key pressed anymore, clear flags KEYUP processed normally: 4.57 ms --8<---------------cut here---------------end--------------->8--- Emacs first registers the windows key to be pressed in a WM_KEYDOWN event, then upon the second call of =E2=80=98funhook=E2=80=99 sees the othe= r key in the combination and sends a WIN+ input to the system and then in the third call receives the WM_KEYUP event, cleans up its state and calls =E2=80=98CallNextHookEx=E2=80=99 to let other applications in the hook chai= n process the combination normally. The times are the execution times of the hook. With the bug present, I get the following output: --8<---------------cut here---------------start------------->8--- KEYDOWN 0x5b, 0x5b: 0.0005 ms Simulated S-x combination: 1.08 ms 0 < winsdown =3D 1: 0.0015 ms 0 < winsdown =3D 1: 0.0015 ms 0 < winsdown =3D 1: 0.0016 ms --8<---------------cut here---------------end--------------->8--- The WM_KEYUP event is missing here; instead, if I press any key, Emacs ignores it and calls =E2=80=98CallNextHookEx=E2=80=99 normally; the above o= utput shows three such key presses. If I press =E2=80=98e=E2=80=99 now, Windows Explor= er will open. That is, Emacs doesn't seem to receive the WM_KEYUP event, but the system doesn't seem to see it either (unless my understanding of the situation is completely wrong). Note that the times shown above are very short; I have seen up to 15 ms, but nothing longer. Emacs was unresponsive for a few seconds while the behaviour occurred; but if the hook was removed by Windows, this was not permanent, as the remaining output shows. Also, pressing a windows key seems to cure the problem in this case. I will continue to observe this and try to find out more, but any insights are welcome. Regards, Raffael --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=funhook-debug-prints.patch Content-Description: funhook debug output diff --git a/src/w32fns.c b/src/w32fns.c index 1d5a591466c..b2572463e04 100644 --- a/src/w32fns.c +++ b/src/w32fns.c @@ -20,6 +20,7 @@ Copyright (C) 1989, 1992-2024 Free Software Foundation, Inc. /* Added by Kevin Gallo */ #include +#include /* Override API version to get the latest functionality. */ #undef _WIN32_WINNT #define _WIN32_WINNT 0x0600 @@ -2556,6 +2557,8 @@ funhook (int code, WPARAM w, LPARAM l) int console = 0; KBDLLHOOKSTRUCT const *hs = (KBDLLHOOKSTRUCT*)l; + struct timespec begin; + clock_gettime (CLOCK_MONOTONIC, &begin); if (code < 0 || (hs->flags & LLKHF_INJECTED)) return CallNextHookEx (0, code, w, l); @@ -2595,6 +2598,11 @@ funhook (int code, WPARAM w, LPARAM l) kbdhook.winseen = 1; kbdhook.winsdown++; } + struct timespec end; + clock_gettime (CLOCK_MONOTONIC, &end); + fprintf (stderr, "KEYDOWN 0x%lx, 0x%lx: %.3g ms\n\n", hs->vkCode, hs->scanCode, + (double)(end.tv_nsec - begin.tv_nsec)/1000000); + /* Returning 1 here drops the keypress without further processing. If the keypress was allowed to go through, the normal Windows hotkeys would take over. */ @@ -2602,6 +2610,8 @@ funhook (int code, WPARAM w, LPARAM l) } else if (kbdhook.winsdown > 0 && (w == WM_KEYUP || w == WM_SYSKEYUP)) { + fprintf (stderr, "KEYUP received, winsdown: %d, w: 0x%llx\n", kbdhook.winsdown, w); + /* A key that has been captured earlier is being released now. */ if (hs->vkCode == VK_LWIN && kbdhook.lwindown) { @@ -2640,29 +2650,43 @@ funhook (int code, WPARAM w, LPARAM l) = KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP; inputs[1].ki.time = 0; SendInput (2, inputs, sizeof (INPUT)); + fprintf (stderr, "Simulated KEYUP to system\n"); } else if (focus != NULL) { /* When not passed to system, must simulate privately to Emacs. */ PostMessage (focus, WM_SYSKEYDOWN, hs->vkCode, 0); PostMessage (focus, WM_SYSKEYUP, hs->vkCode, 0); + fprintf (stderr, "passing to system, simulating privately\n"); } + else + fprintf (stderr, "winsdown == 0, but nothing to do\n"); } } if (kbdhook.winsdown == 0) { + fprintf (stderr, "no key pressed anymore, clear flags\n"); /* No Windows keys pressed anymore - clear the state flags. */ kbdhook.suppress_lone = 0; kbdhook.winseen = 0; } if (!kbdhook.send_win_up) { + struct timespec end; + clock_gettime (CLOCK_MONOTONIC, &end); + fprintf (stderr, "swallowing KEYUP: %.3g ms\n\n", + (double)(end.tv_nsec - begin.tv_nsec)/1000000); + /* Swallow this release message, as not to confuse applications who did not get to see the original WM_KEYDOWN message either. */ return 1; } kbdhook.send_win_up = 0; + struct timespec end; + clock_gettime (CLOCK_MONOTONIC, &end); + fprintf (stderr, "KEYUP processed normally: %.3g ms\n\n", + (double)(end.tv_nsec - begin.tv_nsec)/1000000); } } else if (kbdhook.winsdown > 0) @@ -2698,10 +2722,19 @@ funhook (int code, WPARAM w, LPARAM l) channel when the keys are released. */ kbdhook.suppress_lone = 1; kbdhook.send_win_up = 1; + struct timespec end; + clock_gettime (CLOCK_MONOTONIC, &end); + fprintf (stderr, "Simulated S-x combination: %.3g ms\n\n", + (double)(end.tv_nsec - begin.tv_nsec)/1000000); /* Swallow the original keypress (as we want the Win key down message simulated above to precede this real message). */ return 1; } + struct timespec end; + clock_gettime (CLOCK_MONOTONIC, &end); + fprintf (stderr, "0 < winsdown = %d: %.3g ms\n\n", + kbdhook.winsdown, + (double)(end.tv_nsec - begin.tv_nsec)/1000000); } /* Next, handle the registered Alt-* combinations. */ @@ -2905,6 +2938,7 @@ reset_w32_kbdhook_state (void) kbdhook.send_win_up = 0; kbdhook.suppress_lone = 0; kbdhook.winseen = 0; + fprintf (stderr, "Resetting state\n"); } /* GetKeyState and MapVirtualKey on Windows 95 do not actually distinguish @@ -3526,6 +3560,7 @@ send_deferred_msg (deferred_msg * msg_buf, WPARAM wParam, LPARAM lParam) { + fprintf(stderr, "Sending deferred message\n"); /* Only input thread can send deferred messages. */ if (GetCurrentThreadId () != dwWindowsThreadId) emacs_abort (); @@ -4343,6 +4378,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) case VK_LWIN: if (!w32_kbdhook_active && NILP (Vw32_pass_lwindow_to_system)) { + fprintf (stderr, "kbdhook not active, processing VK_LWIN\n"); /* Prevent system from acting on keyup (which opens the Start menu if no other key was pressed) by simulating a press of Space which we will ignore. */ @@ -4362,6 +4398,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) case VK_RWIN: if (!w32_kbdhook_active && NILP (Vw32_pass_rwindow_to_system)) { + fprintf (stderr, "kbdhook not active, processing VK_RWIN\n"); if (GetAsyncKeyState (wParam) & 1) { if (FIXNUMP (Vw32_phantom_key_code)) --=-=-=-- From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Raffael Stocker Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Sep 2024 13:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 68914@debbugs.gnu.org Cc: Eli Zaretskii X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.172623430625740 (code B ref -1); Fri, 13 Sep 2024 13:32:01 +0000 Received: (at submit) by debbugs.gnu.org; 13 Sep 2024 13:31:46 +0000 Received: from localhost ([127.0.0.1]:42714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sp6On-0006h6-IR for submit@debbugs.gnu.org; Fri, 13 Sep 2024 09:31:45 -0400 Received: from lists.gnu.org ([209.51.188.17]:49942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sp6Ok-0006gs-UC for submit@debbugs.gnu.org; Fri, 13 Sep 2024 09:31:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sp6Oa-0002q1-Oy for bug-gnu-emacs@gnu.org; Fri, 13 Sep 2024 09:31:33 -0400 Received: from mail-out.m-online.net ([212.18.0.9]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sp6OY-0004r1-Iv; Fri, 13 Sep 2024 09:31:32 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4X4wFB0v5Vz1qtqF; Fri, 13 Sep 2024 15:31:26 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 4X4wFB0ZW4z1qqlS; Fri, 13 Sep 2024 15:31:26 +0200 (CEST) X-Virus-Scanned: amavis at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024) with ESMTP id ZAFSqZYn9s-f; Fri, 13 Sep 2024 15:26:25 +0200 (CEST) X-Auth-Info: PFev1t1DNI1H2rOnUzx2UlbLWgE8Yfj8bkbJj0F7LTv0OOhhs82j0SkPZY6kEJBP Received: from Whiteflame (ppp-212-114-182-51.dynamic.mnet-online.de [212.114.182.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 13 Sep 2024 15:26:25 +0200 (CEST) From: Raffael Stocker In-Reply-To: (Raffael Stocker's message of "Sat, 03 Feb 2024 21:45:46 +0100") References: Date: Fri, 13 Sep 2024 15:26:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=212.18.0.9; envelope-from=r.stocker@mnet-mail.de; helo=mail-out.m-online.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Raffael Stocker writes: > 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. > [...] > We have had good results with increasing the =E2=80=98LowLevelHooksTimeou= t=E2=80=99, 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. I believe I can now provide an update here. The last few (2...3) months we have been running Emacs 30 on two machines, with =E2=80=98LowLevelHooksTimeout=E2=80=99 set to 10 (to more easily trigger th= is bug). In this time, we have not seen the bug at all. To confirm that this is connected to the Emacs version we were running, my colleague has now used Emacs 29.2 for a couple of days. And lo and behold, on the second day, the bug re-surfaced: she pressed the windows key in Emacs, then changed to some other program and there it was. So, it seems we can be reasonably confident that something in Emacs 30 fixed this bug. Perhaps it was the WTS_SESSION fix after all (although then I don't understand how), or it was something else. I don't know whether this qualifies as good enough to close this issue, but I suspect we might not be seeing this bug again. Regards, Raffael From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Sep 2024 14:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Raffael Stocker Cc: 68914@debbugs.gnu.org Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.172623873612645 (code B ref 68914); Fri, 13 Sep 2024 14:46:01 +0000 Received: (at 68914) by debbugs.gnu.org; 13 Sep 2024 14:45:36 +0000 Received: from localhost ([127.0.0.1]:43967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sp7YG-0003Hs-Dv for submit@debbugs.gnu.org; Fri, 13 Sep 2024 10:45:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sp7YE-0003HZ-8l for 68914@debbugs.gnu.org; Fri, 13 Sep 2024 10:45:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sp7Xx-0004Sn-Gy; Fri, 13 Sep 2024 10:45:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=FhKFtkTKlMojTOK+b01C+uYLTfaLNQv9kViVd1LVbOg=; b=cawwknoj2TV6bRhXoSIy J5zVFQgG5D/QTcyNroW7NQATiwqKyhxa2wgnwcZSMS0lTwZEGLE8Y1aluoyWYabQ/DH6kQP9p+wF9 lOXKtcmI0LfUfI/7kqezX5AcPJnwgtnKKM42Z0dHwe5tVujd6M5YppPUPf2/56y+77mVgJwA6AJt0 4xGZ1B//PrrW4oaxPK7Buof2HwIFvoHzmOW0SjoM3oN5JmeZLZnywVwuFQdczAfZgGPCmaLGUzY1f Bh26M6Tf0vFgoCWTnOmQ6oikNbI9rYcFZ8QIMVLDl3q2/ntoyMZusvYI5tsZpWSUipNJ8ZaamZmeX dbbOB8qgiRt0cA==; Date: Fri, 13 Sep 2024 17:45:12 +0300 Message-Id: <86cyl7k3yf.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Raffael Stocker on Fri, 13 Sep 2024 15:26:21 +0200) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Raffael Stocker > Cc: Eli Zaretskii > Date: Fri, 13 Sep 2024 15:26:21 +0200 > > Raffael Stocker writes: > > > 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. > > [...] > > 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. > > I believe I can now provide an update here. The last few (2...3) months > we have been running Emacs 30 on two machines, with > ‘LowLevelHooksTimeout’ set to 10 (to more easily trigger this bug). In > this time, we have not seen the bug at all. > > To confirm that this is connected to the Emacs version we were running, > my colleague has now used Emacs 29.2 for a couple of days. And lo and > behold, on the second day, the bug re-surfaced: she pressed the windows > key in Emacs, then changed to some other program and there it was. > > So, it seems we can be reasonably confident that something in Emacs 30 > fixed this bug. Perhaps it was the WTS_SESSION fix after all (although > then I don't understand how), or it was something else. > > I don't know whether this qualifies as good enough to close this issue, > but I suspect we might not be seeing this bug again. Thanks, I will soon close this bug if no further comments are posted. From unknown Sun Jun 15 08:05:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Sep 2024 09:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: r.stocker@mnet-mail.de Cc: 68914@debbugs.gnu.org Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.172691214714809 (code B ref 68914); Sat, 21 Sep 2024 09:50:02 +0000 Received: (at 68914) by debbugs.gnu.org; 21 Sep 2024 09:49:07 +0000 Received: from localhost ([127.0.0.1]:37215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1srwjj-0003qj-08 for submit@debbugs.gnu.org; Sat, 21 Sep 2024 05:49:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1srwjg-0003qB-Fp; Sat, 21 Sep 2024 05:49:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1srwjG-0001LQ-Dh; Sat, 21 Sep 2024 05:48:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=LDWe38ThIOpZcC9zzyG8UP7i/zOiUkE6Ksf/z+Yc39E=; b=gbT2162RfXu08tqhriBw 2v6+SbHj8U2KxAt4rmzw0JdDRqO8tQeU99SVDkmBQvYYefYBL8rnesC9EMVKV6adzcXcQfoWtTg3p RHHf1YmoaE13dNztFmkGtqLPmaiQIwLMXwOPRY6c2r23AeZiVGs1KvwbVeVIvEQAcAsrevR0SW2eQ EKuEKf9AyAoQkycgLejdCGvp8bqy2z0c6rAvazTZxS12IDN32oNy/exs52vlXERpy17HPpXqUC8jW tyAILucH0dO3uTCF4Y/q+7ZkMltdXiyVzM6uHppipnI2dyY2X8DmXZnas2vJlpfQr/5+zNjqAATOq lbhwxNUTddXJWA==; Date: Sat, 21 Sep 2024 12:48:34 +0300 Message-Id: <86frpt49sd.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86cyl7k3yf.fsf@gnu.org> (message from Eli Zaretskii on Fri, 13 Sep 2024 17:45:12 +0300) References: <86cyl7k3yf.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 68914 30.1 thanks > Cc: 68914@debbugs.gnu.org > Date: Fri, 13 Sep 2024 17:45:12 +0300 > From: Eli Zaretskii > > > From: Raffael Stocker > > Cc: Eli Zaretskii > > Date: Fri, 13 Sep 2024 15:26:21 +0200 > > > > Raffael Stocker writes: > > > > > 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. > > > [...] > > > 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. > > > > I believe I can now provide an update here. The last few (2...3) months > > we have been running Emacs 30 on two machines, with > > ‘LowLevelHooksTimeout’ set to 10 (to more easily trigger this bug). In > > this time, we have not seen the bug at all. > > > > To confirm that this is connected to the Emacs version we were running, > > my colleague has now used Emacs 29.2 for a couple of days. And lo and > > behold, on the second day, the bug re-surfaced: she pressed the windows > > key in Emacs, then changed to some other program and there it was. > > > > So, it seems we can be reasonably confident that something in Emacs 30 > > fixed this bug. Perhaps it was the WTS_SESSION fix after all (although > > then I don't understand how), or it was something else. > > > > I don't know whether this qualifies as good enough to close this issue, > > but I suspect we might not be seeing this bug again. > > Thanks, I will soon close this bug if no further comments are posted. Closing.