From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Date: Sun, 04 Feb 2024 08:31:15 +0200 Message-ID: <86mssg3fm4.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30204"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68914@debbugs.gnu.org To: Raffael Stocker Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 04 07:32:03 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 1rWW2t-0007e0-0f for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Feb 2024 07:32:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWW2i-0003tE-3H; Sun, 04 Feb 2024 01:31:52 -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 1rWW2g-0003sw-RV for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2024 01:31:50 -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 1rWW2g-00008I-JT for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2024 01:31:50 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rWW2s-0005Ge-A9 for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2024 01:32:02 -0500 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.170702829920218 (code B ref 68914); Sun, 04 Feb 2024 06:32:02 +0000 Original-Received: (at 68914) by debbugs.gnu.org; 4 Feb 2024 06:31:39 +0000 Original-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 Original-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 Original-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==; In-Reply-To: (message from Raffael Stocker on Sat, 03 Feb 2024 21:45:46 +0100) 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:279394 Archived-At: > 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.