From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Raffael Stocker Newsgroups: gmane.emacs.bugs Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Date: Mon, 12 Feb 2024 21:13:27 +0100 Message-ID: References: <86mssg3fm4.fsf@gnu.org> <865xz42u5a.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16663"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.10.8; emacs 29.2 Cc: 68914@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 12 21:56:17 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rZdLd-0004CR-AE for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Feb 2024 21:56:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZdL8-0008N3-PY; Mon, 12 Feb 2024 15:55:46 -0500 Original-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 1rZdL7-0008Ms-GZ for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2024 15:55:45 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rZdL7-0004EP-9Y for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2024 15:55:45 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rZdLN-0005ng-P7 for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2024 15:56:01 -0500 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.170777132422121 (code B ref 68914); Mon, 12 Feb 2024 20:56:01 +0000 Original-Received: (at 68914) by debbugs.gnu.org; 12 Feb 2024 20:55:24 +0000 Original-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 Original-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 Original-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) Original-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 Original-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 Original-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) In-reply-to: <865xz42u5a.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279928 Archived-At: --=-=-= 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)) --=-=-=--