From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Madhu Newsgroups: gmane.emacs.devel Subject: Re: Possible XInput2 cursor bug ? Date: Sun, 12 Dec 2021 10:41:21 +0530 (IST) Message-ID: <20211212.104121.676618396851953065.enometh@meer.net> References: <87ilvzga2h.fsf@yahoo.com> <87a6hbg6ps.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8319"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: luangruo@yahoo.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 12 06:11:59 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mwH9S-0001x3-F4 for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Dec 2021 06:11:58 +0100 Original-Received: from localhost ([::1]:59690 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mwH9Q-0001rI-G9 for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Dec 2021 00:11:56 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40300) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwH8f-0000wD-HY for emacs-devel@gnu.org; Sun, 12 Dec 2021 00:11:10 -0500 Original-Received: from smtp6.ctinetworks.com ([205.166.61.199]:55504) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwH8d-0002eR-0K for emacs-devel@gnu.org; Sun, 12 Dec 2021 00:11:08 -0500 Original-Received: from localhost (unknown [117.207.24.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp6.ctinetworks.com (Postfix) with ESMTPSA id A237E84BE2; Sun, 12 Dec 2021 00:10:58 -0500 (EST) In-Reply-To: <87a6hbg6ps.fsf@yahoo.com> X-Mailer: Mew version 6.8 on Emacs 29.0.50 X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: A237E84BE2.A99F3 X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-Watermark: 1640149862.31121@QZJ5xoOpMocNWXTQy6cKZw Received-SPF: pass client-ip=205.166.61.199; envelope-from=enometh@meer.net; helo=smtp6.ctinetworks.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281750 Archived-At: * Po Lu <87a6hbg6ps.fsf@yahoo.com> Wrote on Wed, 08 Dec 2021 10:39:59 +0800 > Madhu writes: >> (dwm doesn't have a concept of iconification but) this is not getting >> hit. What is happening (I believe) is that the mouse pointer is getting >> warped to the top right corner -- the window doesn't have any >> decorations -- and emacs probably thinks it has lost focus, but the wm >> keeps the focus on the window anyway. > > Hmm... Could you put a breakpoint here: > > else if (type == FocusOut) > { > -> frame->output_data.x->focus_state &= ~state; > > if (dpyinfo->x_focus_event_frame == frame) > { > dpyinfo->x_focus_event_frame = 0; > x_new_focus_frame (dpyinfo, 0); > > bufp->kind = FOCUS_OUT_EVENT; > XSETFRAME (bufp->frame_or_window, frame); > } > And then show the output of the following command in gdb once it is hit: > (gdb) p dpyinfo->x_focus_event_frame > > Also, what is the value of `focus-follows-mouse', and how is your window > manager configured in that regard? Hello, finally got back to this. To recap: the problem is consistently reproducible only with my own window manager. The window manager does "focus follows mouse", and (list focus-follows-mouse mouse-autoselect-window) => (nil nil) The test case is evaluating (select-frame-set-input-focus (selected-frame)) ^ C-x C-e in a --with-xinput2 build with xt, this causes the block cursor to be replaced by a hollow one, indicating that emacs thought that the focus had gone out of the window. However debugging this with gdb isn't that easy - I can't do it on the same desktop as I have to switch windows to get at the gdb prompt and that interferes with the focus. Accessing the gdb prompt from another machine, I see the breakpoint is hit several times. If the lisp backtrace involves: "x-focus-frame" (0xffffc970) "select-frame-set-input-focus" (0xffffcbf0) "eval" (0xffffcde8) "elisp--eval-last-sexp" (0xffffd0e8) "eval-last-sexp" (0xffffd430) "funcall-interactively" (0xffffd428) "call-interactively" (0xffffd660) "command-execute" (0xffffd9b8) dpyinfo->x_focus_event_frame has the value of the single frame. This gets hit 3-4 times. When the backtrace has the form #0 x_focus_changed (type=10, state=1, dpyinfo=0xbb67b0, frame=0xcfe6e0, bufp=0x7fffffffbf50) at ../../src/xterm.c:4895 #1 0x00000000004e9d41 in handle_one_xevent (dpyinfo=0xbb67b0, event=0x7fffffffc5e0, finish=0x7fffffffc5dc, hold_quit=0x 7fffffffc6d0) at ../../src/xterm.c:9291 #2 0x00000000004edadf in XTread_socket (terminal=, hold_quit=0x7fffffffc6d0) at ../../src/xterm.c:10865 [...] #28 0x000000000050ddc3 in Frecursive_edit () at ../../src/keyboard.c:804 #29 0x000000000042715d in main (argc=4, argv=) at ../../src/emacs .c:2434 Lisp Backtrace: "prin1" (0xffffca68) "elisp--eval-last-sexp-print-value" (0xffffcde0) "elisp--eval-last-sexp" (0xffffd0e8) "eval-last-sexp" (0xffffd430) "funcall-interactively" (0xffffd428) "call-interactively" (0xffffd660) "command-execute" (0xffffd9b8) (gdb) p dpyinfo->x_focus_event_frame $7 = (struct frame *) 0x0 This also happens 3-4 times. Now I tried the same thing in a --without-xinput2 build and noticed that the breakpoint is hit only 3 times (compared to the 8-9 times in the --with-xinput2 build) I looked at xev on the window in both cases and could spot no difference there. Now the clincher: when accessing the gdb prompt through ssh from another box (so the mouse is untouched), sometimes I don't see the problem (of the cursor changing). so this is tricky to debug. [side comment: The GDB footprint for emacs -Q -D is 3-4GB. for native-compilation it seems to be 1GB more. gdb is also slow to load frames with jit on, and a new fingerprint on every `make' makes jit infeasible during "development". already I can't use gdb on my 8G RAM + 8G swap laptop on a regular running emacs without paging to hades and back.] Sorry this is so inconclusive.