From: Po Lu <luangruo@yahoo.com>
To: Madhu <enometh@meer.net>
Cc: emacs-devel@gnu.org
Subject: Re: Possible XInput2 cursor bug ?
Date: Sun, 12 Dec 2021 13:27:59 +0800 [thread overview]
Message-ID: <871r2i1jfk.fsf@yahoo.com> (raw)
In-Reply-To: <20211212.104121.676618396851953065.enometh@meer.net> (Madhu's message of "Sun, 12 Dec 2021 10:41:21 +0530 (IST)")
Madhu <enometh@meer.net> writes:
> 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)
You have to tell Emacs how your window manager behaves in this regard by
setting `focus-follows-mouse' appropriately. In this case, it should be
set to `t'. Please try setting it to that and see if the problem
persists.
> The test case is evaluating
>
> (select-frame-set-input-focus (selected-frame))
> ^ C-x C-e
FWIW, I can't reproduce it here.
> 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.
I find the best solution to that problem to be running the program being
debugged inside Xephyr (or some other nested X server).
> 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.
That's expected.
> 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=<optimized out>, hold_quit=0x7fffffffc6d0)
> at ../../src/xterm.c:10865
That's a LeaveNotify event, not a GenericEvent. The important question
is how many times the code for GenericEvents is called, so could you set
a breakpoint here instead, and see if it is called an abnormal amount of
times:
if (!((xi_event->evtype == XI_Enter
|| xi_event->evtype == XI_Leave)
&& (focus_state & FOCUS_EXPLICIT)))
------> x_focus_changed ((xi_event->evtype == XI_Enter
|| xi_event->evtype == XI_FocusIn
? FocusIn : FocusOut),
(xi_event->evtype == XI_Enter
|| xi_event->evtype == XI_Leave
? FOCUS_IMPLICIT : FOCUS_EXPLICIT),
dpyinfo, frame, bufp);
> I looked at xev on the window in both cases and could spot no
> difference there.
No worries there: xev doesn't know about XInput 2, so it can't display
anything meaningful.
Thanks.
next prev parent reply other threads:[~2021-12-12 5:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87v90wmh6m.fsf.ref@yahoo.com>
2021-11-13 11:24 ` XInput 2 support (again) Po Lu via Emacs development discussions.
2021-11-13 15:04 ` Stefan Monnier
2021-11-14 1:29 ` Po Lu via Emacs development discussions.
2021-11-14 15:29 ` Stefan Monnier
2021-11-14 16:12 ` Eli Zaretskii
2021-11-14 18:11 ` Stefan Monnier
2021-11-14 18:51 ` Eli Zaretskii
2021-11-15 0:26 ` Po Lu
2021-11-15 2:48 ` Stefan Monnier
2021-11-15 2:54 ` Po Lu
2021-11-15 3:18 ` Stefan Monnier
2021-11-15 4:50 ` Po Lu
2021-12-07 17:23 ` Possible XInput2 cursor bug ? (Was: Re: XInput 2 support (again)) Madhu
2021-12-08 1:27 ` Possible XInput2 cursor bug ? Po Lu
2021-12-08 2:33 ` Madhu
2021-12-08 2:39 ` Po Lu
2021-12-12 5:11 ` Madhu
2021-12-12 5:27 ` Po Lu [this message]
2021-12-12 6:02 ` Po Lu
2021-12-12 14:45 ` Madhu
2021-12-13 1:21 ` Po Lu
2021-12-13 4:18 ` Madhu
2021-12-12 7:26 ` Eli Zaretskii
2021-12-12 14:55 ` Madhu
2021-12-12 15:08 ` Eli Zaretskii
2021-12-12 18:15 ` Madhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871r2i1jfk.fsf@yahoo.com \
--to=luangruo@yahoo.com \
--cc=emacs-devel@gnu.org \
--cc=enometh@meer.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.