Subject: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c) between XInput and XInput 2

From: Po Lu <[email-masked]>
Date: Mon, 06 Feb 2023 09:40:50 +0800

Adrián Medraño Calvo <[email-masked]> writes:

> Thank you. I thought already about fixing this in EXWM by sending the
> XI_Motion event when Emacs uses XInput 2 (as you propose below), but
> thought that other users might be in a similar situation. For example,
> a user using xdotool (I must say that I don't know whether xdotool
> relies on XInput, XInput 2, XTest or something else, but for the sake
> of this example please assume the former) would observe the same
> behaviour as us.

These tools should use the record or test extensions, which will not
have these problems.

> If I understand correctly, an XInput 2 enabled Emacs must handle
> regular events as well because some of its frames might be in
> terminals supporting only Xinput 1. If that's the case, would it be
> possible to drop/reject corresponding regular events
> (e.g. MotionNotifiy) on terminals supporting XInput 2? If that's not
> possible, I’d say it’s better applying the patch (or similar) so that,
> even while unsupported, we do a best effort in reducing inconsistency.

XInput 1.x is not supported by Emacs.  You probably mean the X11 core
protocol.

It is ok for MotionNotify events to arrive on a display that has not
selected for input extension events, since Emacs does not keep track of
much state globally across displays.

But once they do on a display that has, then a lot can go wrong.

> I'll implement your suggestion in EXWM shortly, in any case before
> Emacs 29 is released. How can I detect whether Emacs uses XInput 2 in
> a particular terminal?

The function `x-server-input-extension-version'.

> (I’m not sure whether I understand your question, please clarify if
> you think I missed it.) Just focusing the X window (and selecting the
> related Emacs window) is not enough for integrating
> `mouse-autoselect-window', precisely because `last_mouse_window' gets
> out-of-sync, leading to the user being unable to select back the last
> Emacs window by moving the mouse over it. A possible solution to this
> would be to expose `last_mouse_window' to Lisp
> (e.g. `mouse-autoselect-last-window'); presumably EXWM could then set
> its value as part of the above steps and have focus follow the
> pointer. I’d say this is my preferred solution, what do you think
> about this?

Sounds reasonable, except it is too late in the Emacs 29 release cycle
to implement this there.