Re: Possible XInput2 cursor bug ?

[Po Lu]

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.