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