unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Ami Fischman <ami@fischman.org>
Cc: 66765-done@debbugs.gnu.org
Subject: bug#66765: 30.0.50; Building emacs with xinput2 breaks receiving XSendEvent events
Date: Fri, 27 Oct 2023 08:32:44 +0800	[thread overview]
Message-ID: <875y2szyz7.fsf@yahoo.com> (raw)
In-Reply-To: <CAGKqTXVr+LFL7PfV7gDzt+BSWV5D21H9ZuNKB3XFdYYxqoqdfQ@mail.gmail.com> (Ami Fischman's message of "Thu, 26 Oct 2023 10:49:30 -0700")

tags 66765 + notabug wontfix
thanks

Ami Fischman <ami@fischman.org> writes:

> 1. Run: `emacs -Q` on an X11 display for a binary that's been built
> with (the default) `--with-xinput2`
> 2. From another program, trigger an XSendEvent targeting the above
> emacs' window sending a key event.
> Expected:
> 3. The sent key event is seen by emacs.
> Actual:
> 4. Emacs doesn't seem to receive the sent key event.
>
> Simplest way to execute step 2 above is:
> $ git clone http://github.com/epitron/xse.git
> $ cd xse && ./configure  && xmkmf && make depend && make
> $ xwininfo
> (click the emacs window and note its reported "Window id" for the next command)
> $ ./xse -win <EMACS_WINDOW_ID> -Debug '<Key>l'
>
> When emacs is built with `--without-xinput2` the issue is gone, and
> sent events are received properly.
> Issue is not present in 27.1 or 28.1, but is present in 29.1 and HEAD.
> Confirmed with a git bisect that the issue showed up when xinput2 was
> enabled by default in
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0105a4ddb8a58146f3fc71c265e57291c873af0b
>
> I stumbled across this issue when upgrading from 27.1 to 29.1 and
> noticing that ratpoison can no longer send its escape key (in my case,
> this is C-a) to emacs, even though it has no problems sending the same
> key to every other app on my system.

When the X input extension is in use, both Emacs and the X server ignore
core events.  It's also impossible to send extension events, so this
extension renders external event delivery effectively impossible.

This isn't a bug we can fix, sorry; but the XTEST extension is capable
of simulating real key presses, so I suggest whatever tools send Emacs
events be rewritten to make use of that extension.

The same issue can be observed in programs written to use version 3 or 4
of the GTK toolkit.





  reply	other threads:[~2023-10-27  0:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-26 17:49 bug#66765: 30.0.50; Building emacs with xinput2 breaks receiving XSendEvent events Ami Fischman
2023-10-27  0:32 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-10-27  6:04   ` Eli Zaretskii
2023-10-27  7:03     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-27  7:30       ` Eli Zaretskii
2023-10-27  7:38         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-27 10:27           ` Eli Zaretskii
2023-10-27 10:34             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-27 10:53               ` Eli Zaretskii
2023-10-27 10:57               ` Dmitry Gutov
2023-11-04  8:28     ` Eli Zaretskii
2023-11-04 10:25       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-04 11:04         ` Eli Zaretskii
     [not found] ` <handler.66765.D66765.169836681613748.notifdone@debbugs.gnu.org>
2023-10-27 17:37   ` bug#66765: closed (Re: bug#66765: 30.0.50; Building emacs with xinput2 breaks receiving XSendEvent events) Ami Fischman
2023-10-28  0:36     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-28 17:26       ` Ami Fischman
2023-10-28 17:52         ` Ami Fischman
2023-10-29  0:43           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875y2szyz7.fsf@yahoo.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=66765-done@debbugs.gnu.org \
    --cc=ami@fischman.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).