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#69083: Emacs's keyboard hook state is not reset on session lock (Windows) Date: Thu, 29 Feb 2024 21:22:13 +0100 Message-ID: References: <86cyt1qvmt.fsf@gnu.org> <861q9exmhe.fsf@gnu.org> <86v86im1r9.fsf@gnu.org> <868r36uzdh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38156"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.12.0; emacs 29.2 Cc: 69083@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 29 21:24:00 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 1rfmwg-0009gG-Ep for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 29 Feb 2024 21:23:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rfmwL-0006Ml-1E; Thu, 29 Feb 2024 15:23:37 -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 1rfmwJ-0006MX-9t for bug-gnu-emacs@gnu.org; Thu, 29 Feb 2024 15:23:35 -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 1rfmwJ-0006Ji-22 for bug-gnu-emacs@gnu.org; Thu, 29 Feb 2024 15:23:35 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rfmwk-0004NI-4Y for bug-gnu-emacs@gnu.org; Thu, 29 Feb 2024 15:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Raffael Stocker Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Feb 2024 20:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69083 X-GNU-PR-Package: emacs Original-Received: via spool by 69083-submit@debbugs.gnu.org id=B69083.170923823316802 (code B ref 69083); Thu, 29 Feb 2024 20:24:02 +0000 Original-Received: (at 69083) by debbugs.gnu.org; 29 Feb 2024 20:23:53 +0000 Original-Received: from localhost ([127.0.0.1]:35466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rfmwb-0004Mw-89 for submit@debbugs.gnu.org; Thu, 29 Feb 2024 15:23:53 -0500 Original-Received: from mail-out.m-online.net ([212.18.0.10]:57726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rfmwY-0004Ml-AL for 69083@debbugs.gnu.org; Thu, 29 Feb 2024 15:23:51 -0500 Original-Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4Tm2hF5SlNz1sBpm; Thu, 29 Feb 2024 21:22:21 +0100 (CET) Original-Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 4Tm2hF3bL9z1qqlY; Thu, 29 Feb 2024 21:22:21 +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 6w_rIy1GEkPh; Thu, 29 Feb 2024 21:22:20 +0100 (CET) X-Auth-Info: vcitnGZ1PsWvudo8ZnlqcZGTJ31ue9kTVY9lhWrYktdbnYjZdTetftxZPJWzOElj Original-Received: from Whiteflame (ppp-212-114-182-252.dynamic.mnet-online.de [212.114.182.252]) (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; Thu, 29 Feb 2024 21:22:20 +0100 (CET) In-Reply-To: <868r36uzdh.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 27 Feb 2024 09:42:34 +0200") 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:280810 Archived-At: Eli Zaretskii writes: >> + /* Register session notifications so we get notified about the >> + computer being locked. */ >> + if (hwnd !=3D NULL) >> + { >> + kbdhook.window =3D hwnd; >> + HMODULE wtsapi32_lib =3D LoadLibrary ("wtsapi32.dll"); >> + WTSRegisterSessionNotification_Proc WTSRegisterSessionNotification_fn >> + =3D (WTSRegisterSessionNotification_Proc) >> + get_proc_addr (wtsapi32_lib, "WTSRegisterSessionNotification"); >> + WTSUnRegisterSessionNotification_fn =3D (WTSUnRegisterSessionNotific= ation_Proc) >> + get_proc_addr (wtsapi32_lib, "WTSUnRegisterSessionNotification"); >> + if (WTSRegisterSessionNotification_fn !=3D NULL) >> + WTSRegisterSessionNotification_fn (hwnd, NOTIFY_FOR_THIS_SESSION); >> + } > > This code is run every time Emacs creates a new frame, doesn't it? If > so, calling LoadLibrary and get_proc_addr each time is a waste of > cycles. It is better to make both WTSRegisterSessionNotification_fn > and WTSUnRegisterSessionNotification_fn global, and introduce a > boolean flag to indicate that this was already done. Then the above > code should be run only once per session, and all the other calls > should use the function pointers already set up (if non-NULL). The code is run when a first frame is created, because only then =E2=80=98kbdhook.hook_count=E2=80=99 equals 1. If Emacs runs as daemon, th= is can happen several times in a session, when the user deletes all frames and then creates a new one again. > OTOH, there's something I don't understand here. If this code is run > for every frame we create/delete, then what window exactly does the > kbdhook.window member record? It sounds like we overwrite that member > with another window's handle on each call to setup_w32_kbdhook? And > if so, what is the window handle we will pass to > WTSUnRegisterSessionNotification in remove_w32_kbdhook? Or is the > hwnd argument to setup_w32_kbdhook somehow non-NULL only once, for the > main session window or something? I feel that I'm missing something > here. You are right, this is iffy. Setting up the hook for the first frame works well, as the hook is per-process. I thought I could use the same approach here, but the session notifications are per-window. So if the user creates two frames, the session notification is registered for the first one only. If she deletes the first frame (leaving the second one alone), the notification gets unregistered and the hook reset is not called anymore upon session lock. So, I guess the options I have are either somehow juggling window handles, making sure the session notification is always registered for exactly one window handle no matter how many frames are created and deleted (so =E2=80=98reset_w32_kbdhook_state=E2=80=99 is called exactly onc= e for every session lock), or registering the notification for every frame. In the latter case I would either have to find a way to ensure the reset function is only called once, or just not care that it is called for every existing frame. The latter option is simple, but a bit dirty. OTOH, the reset function only sets the state variables to zero, so there shouldn't be a problem with this approach. I'll think about this a bit more, maybe I can come up with a nice solution that doesn't require keeping too much state just for the reset function. I am thinking about registering the notification for the first created frame, and when that is deleted, i.e. receives the =E2=80=98WM_DESTROY=E2=80=99 message, "handing" it over to some other frame= if there is one. I don't know much about the internals of Emacs frame handling. Could =E2=80=98w32_frame_list_z_order=E2=80=99 be used (from the input thre= ad) for something like that? Or is there a better approach? Regards, Raffael