bug#66765: 30.0.50; Building emacs with xinput2 breaks receiving XSendEvent events

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 66765@debbugs.gnu.org,  ami@fischman.org
> Date: Fri, 27 Oct 2023 15:03:21 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you please add something to etc/PROBLEMS about this issue?
> >
> > How widely is this mechanism used in the wild?  If it is used widely
> > enough, perhaps we should tell people not to build with XInput2 if
> > they have vested interests in those methods?
> 
> XSendEvent is seldom used to send input events these days, for this and
> many other reasons, and teaching X programming is outside the purview of
> PROBLEMS.  Properly written programs either insert events into the
> server by means of the XTEST extension, or through OS interfaces that
> precede the X server in the input event delivery process.

The OP talked specifically about ratpoison.  There may be other
programs that use this method.  I'm asking whether we know which ones
do that, not whether it's correct or recommended.

> > Also, maybe submitting bug reports to the respective developers would
> > cause them to improve the situation?
> 
> Oh no, this is a studious design choice, and one I agree with; it's not
> possible to transform core events into input extension ones, because too
> much information is absent from the former.

You are saying that ratpoison cannot be changed to use mechanisms
compatible with XInput2?  If so, it would mean ratpoison will never be
compatible with Emacs build with XInput2.  I thought that maybe
telling ratpoison developers about this will encourage them to make
ratpoison compatible with XInput2.