Re: Possible XInput2 cursor bug ?

[Madhu <enometh@meer.net>]

*  Po Lu <luangruo@yahoo.com> <87a6hbg6ps.fsf@yahoo.com>
Wrote on Wed, 08 Dec 2021 10:39:59 +0800

> Madhu <enometh@meer.net> 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=<optimized out>, 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=<optimized out>) 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.