GNU bug report logs - #61241
29.0.60; Incoherent last_mouse_window (xterm.c) between XInput and XInput 2

Previous Next

Full log

Message #20 received at 61241 <at> debbugs.gnu.org (full text, mbox):

From: Adrián Medraño Calvo <adrian <at> medranocalvo.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 61241 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c)
 between XInput and XInput 2
Date: Tue, 22 Aug 2023 07:45:53 +0200

[Message part 1 (text/plain, inline)]

Dear Po Lu,

> On 6. Feb 2023, at 02:40, Po Lu <luangruo <at> yahoo.com> wrote:
> 
> Adrián Medraño Calvo <adrian <at> 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 (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.