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

[Adrián Medraño Calvo]

Dear Po Lu,

> On 6. Feb 2023, at 02:40, Po Lu <luangruo@yahoo.com> wrote:
> 
> Adrián Medraño Calvo <adrian@medranocalvo.com> 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.

I’ve tried implementing your suggestion to send an XI_Motion event to Emacs 
when the mouse enters the X window managed by EXWM—to no avail:

1. Using SendEvent: XI2 events are GenericEvents, Xorg disallows sending 
GenericEvents within SendEvent.  The following seem to be the cause:
- https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/dix/events.c#L5517, 
and especially
- https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/dix/events.c#L5541

2. Using XTest: although undocumented (as far as I could see), XTest does 
support sending XI device events.  The issue is that EXWM wants to, when 
entering a managed X window, send XI_Motion events to Emacs as well so as to 
trick it into thinking that the pointer entered the Emacs window corresponding 
to the mentioned X window; which marks this Emacs window the last Emacs window 
the pointer was over.  The last think is critical for focus-follows-mouse to 
work on EXWM. The obstacle I find with XTest is that XTest just mimics moving 
the pointer so, when moving the pointer to an X window and then using XTest to 
simulate moving the pointer there (again), nothing changes: the XI_Motion 
events are again sent to this topmost X Window.  I couldn’t think of a way of 
having the XTest events lead to XI_Motion reaching Emacs in such a situation. 

3. I also tried using XWrapPointer which of course does not help as it 
generates no motion events.

Can you think of a way forward?

>> 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.

I prepared a patch (attached below) introducing a new lisp variable holding the 
last "mouse-autoselected” window.  With this patch EXWM can simply select the 
Emacs window corresponding to the managed X window and set it as last 
“mouse-autoselected” window; mouse-autoselect works normally after that.  No 
more sending Motion events.

Using a single variable introduces a significant change, though: when 
`mouse-autoselect-window’ is enabled and emacs runs in different terminals, 
“mouse-autoselecting” a window on a terminal changes the last 
“mouse-autoselected” window for all other terminals.  Slightly moving the mouse 
in a different terminal (within a single Emacs window) will “mouse-autoselect” 
that window, whereas that would not have been the case before this patch, as 
the last “mouse-autoselected” window was terminal-specific.  It’s not clear to 
me whether this behaviour will be beneficial, neutral or unacceptable.  
Moreover, this behaviour is consistent with the behaviour introduced in the 
first patch I sent, where I proposed to merge the last “mouse-autoselected” 
window for Motion and XI_Motion events (other terminals were not affected).

Please let me know your thoughts.

Regards,
Adrián.

0001-Expose-last-window-under-pointer-to-Lisp.patch
Description: Binary data