Package: emacs;
Reported by: Yikai Zhao <yikai <at> z1k.dev>
Date: Thu, 28 Nov 2024 13:20:02 UTC
Severity: normal
Found in version 31.0.50
To reply to this bug, email your comments to 74590 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Thu, 28 Nov 2024 13:20:02 GMT) Full text and rfc822 format available.Yikai Zhao <yikai <at> z1k.dev>:bug-gnu-emacs <at> gnu.org.
(Thu, 28 Nov 2024 13:20:03 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: bug-gnu-emacs <at> gnu.org Subject: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Thu, 28 Nov 2024 21:18:52 +0800
I encountered this bug while testing the mps (scratch/igc) branch. I cannot reproduce this with the current master branch. I'm running Linux, X11, fcitx chinese input method. Fcitx input method is popular among CJK users. When it's enabled, all character inputs should be displayed in the "fcitx preedit box"; until a confirmation key (e.g. space) is pressed, the composed characters should then be inserted into the application (e.g. emacs). Now, with the mps branch, occasinoally, some key input would NOT go to the fcitx preedit box; instead, it goes into emacs directly. It happens regardless of whether the fcitx preedit box is currently active. (aka, both first-chars and non-first-chars may have this problem). If the fcitx preedit box is active when is happens, it would remain active. For example, when I type "niha", it starts at this: +----------emacs buffer---------------+ | xxxxxx| | | +-----fcitx box-------+ | | | niha | | | | 你好 你哈 你害 .. | | | +---------------------+ | | | +-------------------------------------+ Then I type "o", the expected behavior is: +----------emacs buffer---------------+ | xxxxxx| | | +-----fcitx box-------+ | | | nihao | | | | 你好 你哈 你害 .. | | | +---------------------+ | | | +-------------------------------------+ But instead, what I get is: +----------emacs buffer---------------+ | xxxxxxo| | | +-----fcitx box-------+ | | | niha | | | | 你好 你哈 你害 .. | | | +---------------------+ | | | +-------------------------------------+ In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10) of 2024-11-24 built on f2908c960c38 Repository revision: 0756b1f2f5452d715396f66d887c137776e360ca Repository branch: scratch/igc Windowing system distributor 'The X.Org Foundation', version 11.0.12101004 System Description: Ubuntu 22.04.5 LTS Configured using: 'configure --prefix=/work/dist/AppDir --disable-locallisppath --with-native-compilation=aot --with-json --with-threads --with-sqlite3 --with-tree-sitter --with-dbus --with-xml2 --with-modules --with-libgmp --with-gpm --with-lcms2 --with-mps --with-x --without-pgtk --without-gconf --with-x-toolkit=gtk3 --with-xft --without-tiff --without-imagemagick --with-gif --with-png --with-rsvg --with-webp --with-harfbuzz --with-cairo --with-libotf --without-m17n-flt --with-jpeg emacs_cv_jpeglib=/usr/lib/x86_64-linux-gnu/libjpeg.a CPPFLAGS=-I/work/dist/AppDir/include LDFLAGS=-L/work/dist/AppDir/lib' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $EMACSDATA: /tmp/.mount_emacsCDP179/share/emacs/31.0.50/etc value of $EMACSDOC: /tmp/.mount_emacsCDP179/share/emacs/31.0.50/etc value of $EMACSLOADPATH: /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp value of $EMACSPATH: /tmp/.mount_emacsCDP179/libexec/emacs/31.0.50/x86_64-pc-linux-gnu value of $LC_MONETARY: en_US.UTF-8 value of $LC_NUMERIC: en_US.UTF-8 value of $LC_TIME: en_US.UTF-8 value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=fcitx locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: evil-vimish-fold-mode: t vimish-fold-mode: t diff-hl-mode: t flycheck-posframe-mode: t flycheck-mode: t ligature-mode: t whitespace-mode: t electric-pair-mode: t hl-todo-mode: t dtrt-indent-mode: t projectile-mode: t tempel-abbrev-mode: t company-mode: t global-git-commit-mode: t magit-auto-revert-mode: t hl-line-mode: t display-line-numbers-mode: t windmove-mode: t recentf-mode: t pixel-scroll-precision-mode: t server-mode: t winner-mode: t global-auto-revert-mode: t save-place-mode: t vertico-mode: t which-key-mode: t global-evil-visualstar-mode: t evil-visualstar-mode: t evil-snipe-override-mode: t evil-snipe-override-local-mode: t evil-owl-mode: t global-evil-surround-mode: t evil-surround-mode: t evil-commentary-mode: t evil-mode: t evil-local-mode: t override-global-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t minibuffer-regexp-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/yikai/.emacs.d/lib/which-key/which-key hides /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/which-key /home/yikai/.emacs.d/lib/transient/lisp/transient hides /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/transient /home/yikai/.emacs.d/lib/editorconfig/editorconfig hides /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig /home/yikai/.emacs.d/lib/editorconfig/editorconfig-tools hides /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-tools /home/yikai/.emacs.d/lib/editorconfig/editorconfig-fnmatch hides /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-fnmatch /home/yikai/.emacs.d/lib/editorconfig/editorconfig-core hides /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-core /home/yikai/.emacs.d/lib/editorconfig/editorconfig-core-handle hides /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-core-handle /home/yikai/.emacs.d/lib/editorconfig/editorconfig-conf-mode hides /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-conf-mode /home/yikai/.emacs.d/lib/compat/compat hides /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/emacs-lisp/compat Features: (shadow sort mail-extr emacsbug evil-vimish-fold vimish-fold f s git-gutter-fringe fringe-helper git-gutter evil-collection-diff-hl diff-hl evil-collection-log-view log-view evil-collection-vc-dir vc-dir ewoc vc vc-dispatcher flycheck-posframe posframe flycheck-google-cpplint evil-collection-flycheck flycheck ligature whitespace elec-pair hl-todo dtrt-indent company-keywords company-dabbrev-code company-dabbrev company-files projectile evil-collection-grep grep ibuf-ext evil-collection-ibuffer ibuffer ibuffer-loaddefs url-queue pr-review-search tempel company-abbrev company-emoji company-emoji-list company-capf company bazel evil-collection-xref xref which-func testcover evil-collection-edebug edebug evil-collection-debug debug backtrace evil-collection-python python treesit project evil-collection-imenu imenu ffap cc-mode cc-fonts cc-guess cc-menus cc-cmds textsec uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check pr-review pr-review-render shr pixel-fill kinsoku url-file svg dom pr-review-action magit-diff smerge-mode diff evil-collection-diff-mode diff-mode track-changes git-commit evil-collection-log-edit log-edit message sendmail yank-media evil-collection-dired dired dired-loaddefs rfc822 mml mml-sec evil-collection-epa epa derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader pcvs-util add-log magit-core magit-autorevert magit-margin magit-transient magit-process with-editor magit-mode transient browse-url benchmark magit-git magit-base crm pr-review-input evil-collection-markdown-mode markdown-mode evil-collection-outline noutline outline mule-util pulse mail-utils network-stream url-cache hl-line display-line-numbers pr-review-notification pr-review-listview pr-review-api ghub-graphql treepy gsexp ghub url-http mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm url-auth url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap let-alist gnutls puny pr-review-common evil-collection-magit-section magit-section dash windmove cl-print igc vertico-directory orderless recentf tree-widget wid-edit evil-collection-consult consult cursor-sensor help-fns time pixel-scroll cua-base auth-source-pass url-parse url-vars server fcitx dbus xml winner evil-collection-vterm vterm evil-collection-bookmark bookmark pp face-remap evil-collection-compile compile text-property-search evil-collection-term term disp-table ehelp find-func vterm-module term/xterm xterm cc-styles cc-align cc-engine cc-vars cc-defs google-c-style midnight autorevert filenotify saveplace tramp-cache time-stamp tramp-sh tramp trampver tramp-integration files-x tramp-message tramp-compat xdg shell pcomplete evil-collection-comint comint ansi-osc parse-time iso8601 time-date auth-source eieio eieio-core password-cache json map ansi-color tramp-loaddefs cus-load evil-collection-vertico vertico compat solarized-light-theme solarized-theme solarized solarized-faces color evil-collection-which-key which-key fringe-scale switch-buffer-functions evil-visualstar evil-snipe evil-owl format-spec evil-surround evil-commentary evil-commentary-integration evil-collection-tabulated-list evil-collection-tab-bar evil-collection-simple evil-collection-replace evil-collection-process-menu evil-collection-kmacro evil-collection-info evil-collection-indent evil-collection-help evil-collection-elisp-mode evil-collection-eldoc evil-collection-buff-menu evil-collection annalist evil evil-integration evil-maps evil-commands evil-digraphs reveal evil-jumps evil-command-window evil-types evil-search evil-ex evil-macros evil-repeat evil-states evil-core advice evil-common thingatpt rect evil-vars ring edmacro kmacro byte-opt delight comp-run use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key easy-mmode use-package-core yaml-mode-autoloads xonsh-mode-autoloads with-editor-autoloads which-key-autoloads wgrep-autoloads vterm-autoloads vimrc-mode-autoloads vimish-fold-autoloads vertico-autoloads treesit-auto-autoloads treepy-autoloads transient-autoloads tempel-autoloads switch-buffer-functions-autoloads suggest-autoloads sudo-edit-autoloads spinner-autoloads solarized-theme-autoloads s-autoloads rust-mode-autoloads rg-autoloads rainbow-mode-autoloads pydoc-autoloads protobuf-mode-autoloads projectile-autoloads pr-review-autoloads posframe-autoloads popup-autoloads pkg-info-autoloads php-mode-autoloads package-lint-autoloads org2elcomment-autoloads org-tree-slide-autoloads orderless-autoloads markdown-mode-autoloads magit-autoloads lv-autoloads lua-mode-autoloads lsp-pyright-autoloads lsp-mode-autoloads lsp-haskell-autoloads loop-autoloads llama-autoloads ligature-autoloads kotlin-mode-autoloads just-mode-autoloads jsonnet-mode-autoloads jinx-autoloads jinja2-mode-autoloads ht-autoloads hl-todo-autoloads haskell-mode-autoloads groovy-mode-autoloads gptel-autoloads goto-chg-autoloads google-c-style-autoloads go-mode-autoloads gn-mode-autoloads git-link-autoloads git-gutter-fringe-autoloads git-gutter-autoloads ghub-autoloads fringe-helper-autoloads flycheck-posframe-autoloads flycheck-package-autoloads flycheck-google-cpplint-autoloads flycheck-autoloads fish-mode-autoloads fcitx-autoloads f-autoloads explain-pause-mode-autoloads expand-region-autoloads exec-path-from-shell-autoloads evil-visualstar-autoloads evil-vimish-fold-autoloads evil-surround-autoloads evil-snipe-autoloads evil-owl-autoloads evil-commentary-autoloads evil-collection-autoloads evil-autoloads epl-autoloads epkg-autoloads embark-autoloads emacsql-autoloads emacs-fringe-scale-autoloads editorconfig-autoloads ebuild-mode-autoloads dumb-jump-autoloads dtrt-indent-autoloads dockerfile-mode-autoloads diff-hl-autoloads devdocs-browser-autoloads delight-autoloads dash-autoloads cuda-mode-autoloads copilot-autoloads consult-flycheck-autoloads consult-autoloads compat-autoloads company-emoji-autoloads company-autoloads codeium-autoloads cl-macs cmake-mode-autoloads closql-autoloads bpftrace-mode-autoloads borg-autoloads bazel-autoloads avy-autoloads annalist-autoloads add-node-modules-path-autoloads borg loaddefs-gen generate-lisp-file lisp-mnt radix-tree pcase info comp cl-seq comp-cstr cl-extra help-mode comp-common warnings icons subr-x rx gv cl-loaddefs cl-lib bytecomp byte-compile rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar make-network-process native-compile mps emacs) Memory information: ((conses 24 0 0) (symbols 56 0 0) (strings 40 0 0) (string-bytes 1 0) (vectors 24 0) (vector-slots 8 0 0) (floats 24 0 0) (intervals 64 0 0) (buffers 1000 0))
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Thu, 28 Nov 2024 13:34:02 GMT) Full text and rfc822 format available.Message #8 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Yikai Zhao <yikai <at> z1k.dev> Cc: 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Thu, 28 Nov 2024 13:32:59 +0000
On Thursday, November 28th, 2024 at 13:18, Yikai Zhao <yikai <at> z1k.dev> wrote: > I encountered this bug while testing the mps (scratch/igc) branch. I > cannot reproduce this with the current master branch. Can you reproduce it on the scratch/igc branch, but compiled without mps support? That might help us narow it down to the MPS code or some unrelated change on that branch. Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Fri, 29 Nov 2024 04:28:01 GMT) Full text and rfc822 format available.Message #11 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Fri, 29 Nov 2024 12:26:39 +0800
I can confirm that the issue does not happen on the scratch/igc branch without mps support (or at least much less frequent) On Thu, Nov 28, 2024 at 9:33 PM Pip Cet <pipcet <at> protonmail.com> wrote: > > On Thursday, November 28th, 2024 at 13:18, Yikai Zhao <yikai <at> z1k.dev> wrote: > > I encountered this bug while testing the mps (scratch/igc) branch. I > > cannot reproduce this with the current master branch. > > Can you reproduce it on the scratch/igc branch, but compiled without mps support? > > That might help us narow it down to the MPS code or some unrelated change on that branch. > > Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Fri, 29 Nov 2024 05:23:02 GMT) Full text and rfc822 format available.Message #14 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Yikai Zhao <yikai <at> z1k.dev> Cc: Pip Cet <pipcet <at> protonmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Fri, 29 Nov 2024 06:21:38 +0100
Yikai Zhao <yikai <at> z1k.dev> writes: > I can confirm that the issue does not happen on the scratch/igc branch > without mps support > (or at least much less frequent) > > On Thu, Nov 28, 2024 at 9:33 PM Pip Cet <pipcet <at> protonmail.com> wrote: >> >> On Thursday, November 28th, 2024 at 13:18, Yikai Zhao <yikai <at> z1k.dev> wrote: >> > I encountered this bug while testing the mps (scratch/igc) branch. I >> > cannot reproduce this with the current master branch. >> >> Can you reproduce it on the scratch/igc branch, but compiled without mps support? >> >> That might help us narow it down to the MPS code or some unrelated change on that branch. >> >> Pip Not sure if that is used in your build, but in x_display_info (xterm.h) I see a number of struct frame pointers that are not fixed in fix_frame, starting with struct frame *x_focus_frame; And if it's not that display info that is being used, I'd bet a small amount that whatever is actually used (pgtk_display_info?) has a similar problems. (Can't fix this myself, sorry, I only have macOS.)
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Fri, 29 Nov 2024 05:57:01 GMT) Full text and rfc822 format available.Message #17 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Yikai Zhao <yikai <at> z1k.dev> Cc: Pip Cet <pipcet <at> protonmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Fri, 29 Nov 2024 06:55:38 +0100
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: Wanted to get Helmut onboard, in case he's interested, but forgot to add him in CC. Now he is. > Yikai Zhao <yikai <at> z1k.dev> writes: > >> I can confirm that the issue does not happen on the scratch/igc branch >> without mps support >> (or at least much less frequent) >> >> On Thu, Nov 28, 2024 at 9:33 PM Pip Cet <pipcet <at> protonmail.com> wrote: >>> >>> On Thursday, November 28th, 2024 at 13:18, Yikai Zhao <yikai <at> z1k.dev> wrote: >>> > I encountered this bug while testing the mps (scratch/igc) branch. I >>> > cannot reproduce this with the current master branch. >>> >>> Can you reproduce it on the scratch/igc branch, but compiled without mps support? >>> >>> That might help us narow it down to the MPS code or some unrelated change on that branch. >>> >>> Pip > > Not sure if that is used in your build, but in x_display_info (xterm.h) > I see a number of struct frame pointers that are not fixed in fix_frame, > starting with > > struct frame *x_focus_frame; > > And if it's not that display info that is being used, I'd bet a small > amount that whatever is actually used (pgtk_display_info?) has a similar > problems. > > (Can't fix this myself, sorry, I only have macOS.)
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Sat, 30 Nov 2024 10:41:02 GMT) Full text and rfc822 format available.Message #20 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Helmut Eller <eller.helmut <at> gmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Pip Cet <pipcet <at> protonmail.com>, Yikai Zhao <yikai <at> z1k.dev>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Sat, 30 Nov 2024 11:39:07 +0100
On Fri, Nov 29 2024, Gerd Möllmann wrote: >> Not sure if that is used in your build, but in x_display_info (xterm.h) >> I see a number of struct frame pointers that are not fixed in fix_frame, >> starting with >> >> struct frame *x_focus_frame; >> >> And if it's not that display info that is being used, I'd bet a small >> amount that whatever is actually used (pgtk_display_info?) has a similar >> problems. >> >> (Can't fix this myself, sorry, I only have macOS.) I think the x_display_info struct (I guess usually only one exists) is allocated in x_term_init (or pgtk_term_init) with igc_xzalloc_ambig. So theoretically it doesn't need to be traced.
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Sat, 30 Nov 2024 10:57:02 GMT) Full text and rfc822 format available.Message #23 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Helmut Eller <eller.helmut <at> gmail.com> Cc: Pip Cet <pipcet <at> protonmail.com>, Yikai Zhao <yikai <at> z1k.dev>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Sat, 30 Nov 2024 11:55:42 +0100
Helmut Eller <eller.helmut <at> gmail.com> writes: > On Fri, Nov 29 2024, Gerd Möllmann wrote: > >>> Not sure if that is used in your build, but in x_display_info (xterm.h) >>> I see a number of struct frame pointers that are not fixed in fix_frame, >>> starting with >>> >>> struct frame *x_focus_frame; >>> >>> And if it's not that display info that is being used, I'd bet a small >>> amount that whatever is actually used (pgtk_display_info?) has a similar >>> problems. >>> >>> (Can't fix this myself, sorry, I only have macOS.) > > I think the x_display_info struct (I guess usually only one exists) is > allocated in x_term_init (or pgtk_term_init) with igc_xzalloc_ambig. So > theoretically it doesn't need to be traced. Then we're good, sorry for the noise. What made me suspicious is that we have this in fix_frame: Lisp_Object *nle = &FRAME_DISPLAY_INFO (f)->name_list_element; IGC_FIX12_OBJ (ss, nle);
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Sat, 30 Nov 2024 16:38:02 GMT) Full text and rfc822 format available.Message #26 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Yikai Zhao <yikai <at> z1k.dev>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Sat, 30 Nov 2024 16:37:03 +0000
[Message part 1 (text/plain, inline)]
On Saturday, November 30th, 2024 at 10:55, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > Helmut Eller eller.helmut <at> gmail.com writes: > > > On Fri, Nov 29 2024, Gerd Möllmann wrote: > > > > > > Not sure if that is used in your build, but in x_display_info (xterm.h) > > > > I see a number of struct frame pointers that are not fixed in fix_frame, > > > > starting with > > > > > > > > struct frame *x_focus_frame; > > > > > > > > And if it's not that display info that is being used, I'd bet a small > > > > amount that whatever is actually used (pgtk_display_info?) has a similar > > > > problems. > > > > > > > > (Can't fix this myself, sorry, I only have macOS.) > > > > I think the x_display_info struct (I guess usually only one exists) is > > allocated in x_term_init (or pgtk_term_init) with igc_xzalloc_ambig. So > > theoretically it doesn't need to be traced. > > > Then we're good, sorry for the noise. So it turns out X input method handling is somewhat complicated! I've tried installing fcitx, but it seems to be working the same here with and without MPS. It would help to establish the value of x-gtk-use-native-input, since that determines whether we use the GTK or X method for communicating with fcitx. I've attached a patch which logs some debugging info to stderr (because displaying messages using X while debugging X code is a bad idea, IME). If you could apply it and reproduce the output around a keypress that's handled incorrectly, that might help us track this down. Pip
[0002-fcitx.patch (text/x-patch, attachment)]
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Sun, 01 Dec 2024 06:06:02 GMT) Full text and rfc822 format available.Message #29 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Yikai Zhao <yikai <at> z1k.dev>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Sun, 01 Dec 2024 07:04:18 +0100
Pip Cet <pipcet <at> protonmail.com> writes:
> On Saturday, November 30th, 2024 at 10:55, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>> Helmut Eller eller.helmut <at> gmail.com writes:
>>
>> > On Fri, Nov 29 2024, Gerd Möllmann wrote:
>> >
>> > > > Not sure if that is used in your build, but in x_display_info (xterm.h)
>> > > > I see a number of struct frame pointers that are not fixed in fix_frame,
>> > > > starting with
>> > > >
>> > > > struct frame *x_focus_frame;
>> > > >
>> > > > And if it's not that display info that is being used, I'd bet a small
>> > > > amount that whatever is actually used (pgtk_display_info?) has a similar
>> > > > problems.
>> > > >
>> > > > (Can't fix this myself, sorry, I only have macOS.)
>> >
>> > I think the x_display_info struct (I guess usually only one exists) is
>> > allocated in x_term_init (or pgtk_term_init) with igc_xzalloc_ambig. So
>> > theoretically it doesn't need to be traced.
>>
>>
>> Then we're good, sorry for the noise.
>
> So it turns out X input method handling is somewhat complicated!
>
> I've tried installing fcitx, but it seems to be working the same here with and without MPS.
>
> It would help to establish the value of x-gtk-use-native-input, since that determines whether we use the GTK or X method for communicating with fcitx.
>
> I've attached a patch which logs some debugging info to stderr
> (because displaying messages using X while debugging X code is a bad
> idea, IME). If you could apply it and reproduce the output around a
> keypress that's handled incorrectly, that might help us track this
> down.
>
> Pip
Searching for "closure" and "user_data" turns up this in gtkutil.c:
static void
xg_im_context_commit (GtkIMContext *imc, gchar *str,
gpointer user_data)
{
struct frame *f = get_glib_user_data (user_data);
That's a Gtk signal handler, or whatever they are called, which
gets set, also in gtkutil.c
g_signal_connect_data (G_OBJECT (imc), "commit",
G_CALLBACK (xg_im_context_commit),
glib_user_data (f), free_glib_user_data,
G_CONNECT_DEFAULT);
Looks to me like a struct frame * might be "hidden" by this in some Gtk
data structure so that it can be passed to the handler at some point.
Don't know if that's relevant.
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Sun, 01 Dec 2024 07:35:01 GMT) Full text and rfc822 format available.Message #32 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Yikai Zhao <yikai <at> z1k.dev>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Sun, 01 Dec 2024 08:33:21 +0100
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> On Saturday, November 30th, 2024 at 10:55, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>>> Helmut Eller eller.helmut <at> gmail.com writes:
>>>
>>> > On Fri, Nov 29 2024, Gerd Möllmann wrote:
>>> >
>>> > > > Not sure if that is used in your build, but in x_display_info (xterm.h)
>>> > > > I see a number of struct frame pointers that are not fixed in fix_frame,
>>> > > > starting with
>>> > > >
>>> > > > struct frame *x_focus_frame;
>>> > > >
>>> > > > And if it's not that display info that is being used, I'd bet a small
>>> > > > amount that whatever is actually used (pgtk_display_info?) has a similar
>>> > > > problems.
>>> > > >
>>> > > > (Can't fix this myself, sorry, I only have macOS.)
>>> >
>>> > I think the x_display_info struct (I guess usually only one exists) is
>>> > allocated in x_term_init (or pgtk_term_init) with igc_xzalloc_ambig. So
>>> > theoretically it doesn't need to be traced.
>>>
>>>
>>> Then we're good, sorry for the noise.
>>
>> So it turns out X input method handling is somewhat complicated!
>>
>> I've tried installing fcitx, but it seems to be working the same here with and without MPS.
>>
>> It would help to establish the value of x-gtk-use-native-input, since that determines whether we use the GTK or X method for communicating with fcitx.
>>
>> I've attached a patch which logs some debugging info to stderr
>> (because displaying messages using X while debugging X code is a bad
>> idea, IME). If you could apply it and reproduce the output around a
>> keypress that's handled incorrectly, that might help us track this
>> down.
>>
>> Pip
>
> Searching for "closure" and "user_data" turns up this in gtkutil.c:
>
> static void
> xg_im_context_commit (GtkIMContext *imc, gchar *str,
> gpointer user_data)
> {
> struct frame *f = get_glib_user_data (user_data);
>
> That's a Gtk signal handler, or whatever they are called, which
> gets set, also in gtkutil.c
>
> g_signal_connect_data (G_OBJECT (imc), "commit",
> G_CALLBACK (xg_im_context_commit),
> glib_user_data (f), free_glib_user_data,
> G_CONNECT_DEFAULT);
>
> Looks to me like a struct frame * might be "hidden" by this in some Gtk
> data structure so that it can be passed to the handler at some point.
>
> Don't know if that's relevant.
It probably isn't relevant because of this
#ifdef HAVE_MPS
void free_glib_user_data (gpointer data, GClosure *closure)
{
igc_xfree (data);
}
#else
void free_glib_user_data (gpointer data, GClosure *closure)
{
return;
}
#endif
Don't know where the allocation takes place.
I should shut up, I guess :-).
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Sun, 01 Dec 2024 10:09:02 GMT) Full text and rfc822 format available.Message #35 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Yikai Zhao <yikai <at> z1k.dev>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Sun, 01 Dec 2024 10:08:04 +0000
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> It probably isn't relevant because of this
>
> #ifdef HAVE_MPS
> void free_glib_user_data (gpointer data, GClosure *closure)
> {
> igc_xfree (data);
> }
> #else
> void free_glib_user_data (gpointer data, GClosure *closure)
> {
> return;
> }
> #endif
>
> Don't know where the allocation takes place.
It's this code in gtkutil.h:
#ifdef HAVE_MPS
INLINE gpointer
glib_user_data (void *o)
{
gpointer p = igc_xzalloc_ambig (sizeof (o));
memcpy (p, &o, sizeof (o));
return p;
}
INLINE void *
get_glib_user_data (gpointer p)
{
return *(void **)p;
}
#else
INLINE gpointer
glib_user_data (void *o)
{
return (gpointer)o;
}
INLINE void *
get_glib_user_data (gpointer p)
{
return (void *)p;
}
#endif
Does that look correct to you?
My understanding is that the GTK input method code is only used if
x_gtk_use_native_input is true (which we'll have to wait for the OP to
confirm or deny), but xg_create_frame_widgets always calls
gtk_im_multicontext_new, so the problem might be in the GTK code...
Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Sun, 01 Dec 2024 11:32:02 GMT) Full text and rfc822 format available.Message #38 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Yikai Zhao <yikai <at> z1k.dev>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Sun, 01 Dec 2024 12:30:49 +0100
Pip Cet <pipcet <at> protonmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> It probably isn't relevant because of this
>>
>> #ifdef HAVE_MPS
>> void free_glib_user_data (gpointer data, GClosure *closure)
>> {
>> igc_xfree (data);
>> }
>> #else
>> void free_glib_user_data (gpointer data, GClosure *closure)
>> {
>> return;
>> }
>> #endif
>>
>> Don't know where the allocation takes place.
>
> It's this code in gtkutil.h:
>
> #ifdef HAVE_MPS
> INLINE gpointer
> glib_user_data (void *o)
> {
> gpointer p = igc_xzalloc_ambig (sizeof (o));
> memcpy (p, &o, sizeof (o));
> return p;
> }
>
> INLINE void *
> get_glib_user_data (gpointer p)
> {
> return *(void **)p;
> }
> #else
> INLINE gpointer
> glib_user_data (void *o)
> {
> return (gpointer)o;
> }
>
> INLINE void *
> get_glib_user_data (gpointer p)
> {
> return (void *)p;
> }
> #endif
>
> Does that look correct to you?
Yes, kt does.
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Mon, 02 Dec 2024 08:58:01 GMT) Full text and rfc822 format available.Message #41 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Mon, 2 Dec 2024 16:56:39 +0800
Hello Pip, I have reproduced the issue with your patch, here's the relevant log: (Lines starting with '#' are my comments) dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 # Pressed first character here. It goes to fcitx normally. result 1 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 result 0 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 # Pressed second character here. It goes to fcitx normally. result 1 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 # Pressed third character here. It goes to fcitx normally. result 1 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 # BUG REPRODUCED HERE: Pressed fourth character here. It does not go to fcitx. It goes to emacs instead. result 0 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 result 0 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 result 0 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 dpyinfo 0x55c17572d8c0 Please let me know if there's any other info I can provide. Thanks! On Sun, Dec 1, 2024 at 12:37 AM Pip Cet <pipcet <at> protonmail.com> wrote: > > On Saturday, November 30th, 2024 at 10:55, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > > Helmut Eller eller.helmut <at> gmail.com writes: > > > > > On Fri, Nov 29 2024, Gerd Möllmann wrote: > > > > > > > > Not sure if that is used in your build, but in x_display_info (xterm.h) > > > > > I see a number of struct frame pointers that are not fixed in fix_frame, > > > > > starting with > > > > > > > > > > struct frame *x_focus_frame; > > > > > > > > > > And if it's not that display info that is being used, I'd bet a small > > > > > amount that whatever is actually used (pgtk_display_info?) has a similar > > > > > problems. > > > > > > > > > > (Can't fix this myself, sorry, I only have macOS.) > > > > > > I think the x_display_info struct (I guess usually only one exists) is > > > allocated in x_term_init (or pgtk_term_init) with igc_xzalloc_ambig. So > > > theoretically it doesn't need to be traced. > > > > > > Then we're good, sorry for the noise. > > So it turns out X input method handling is somewhat complicated! > > I've tried installing fcitx, but it seems to be working the same here with and without MPS. > > It would help to establish the value of x-gtk-use-native-input, since that determines whether we use the GTK or X method for communicating with fcitx. > > I've attached a patch which logs some debugging info to stderr (because displaying messages using X while debugging X code is a bad idea, IME). If you could apply it and reproduce the output around a keypress that's handled incorrectly, that might help us track this down. > > Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Mon, 02 Dec 2024 09:00:02 GMT) Full text and rfc822 format available.Message #44 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Mon, 2 Dec 2024 16:58:01 +0800
On Sun, Dec 1, 2024 at 6:08 PM Pip Cet <pipcet <at> protonmail.com> wrote:
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> > It probably isn't relevant because of this
> >
> > #ifdef HAVE_MPS
> > void free_glib_user_data (gpointer data, GClosure *closure)
> > {
> > igc_xfree (data);
> > }
> > #else
> > void free_glib_user_data (gpointer data, GClosure *closure)
> > {
> > return;
> > }
> > #endif
> >
> > Don't know where the allocation takes place.
>
> It's this code in gtkutil.h:
>
> #ifdef HAVE_MPS
> INLINE gpointer
> glib_user_data (void *o)
> {
> gpointer p = igc_xzalloc_ambig (sizeof (o));
> memcpy (p, &o, sizeof (o));
> return p;
> }
>
> INLINE void *
> get_glib_user_data (gpointer p)
> {
> return *(void **)p;
> }
> #else
> INLINE gpointer
> glib_user_data (void *o)
> {
> return (gpointer)o;
> }
>
> INLINE void *
> get_glib_user_data (gpointer p)
> {
> return (void *)p;
> }
> #endif
>
> Does that look correct to you?
>
> My understanding is that the GTK input method code is only used if
> x_gtk_use_native_input is true (which we'll have to wait for the OP to
> confirm or deny),
`x-gtk-use-native-input` is nil here, if that's what you are asking.
> but xg_create_frame_widgets always calls
> gtk_im_multicontext_new, so the problem might be in the GTK code...
>
> Pip
>
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Mon, 02 Dec 2024 10:09:02 GMT) Full text and rfc822 format available.Message #47 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Mon, 2 Dec 2024 18:06:45 +0800
Setting `x-gtk-use-native-input` to `t` seems to fix the issue for me!
On Mon, Dec 2, 2024 at 4:58 PM Yikai Zhao <yikai <at> z1k.dev> wrote:
>
> On Sun, Dec 1, 2024 at 6:08 PM Pip Cet <pipcet <at> protonmail.com> wrote:
> >
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> > > It probably isn't relevant because of this
> > >
> > > #ifdef HAVE_MPS
> > > void free_glib_user_data (gpointer data, GClosure *closure)
> > > {
> > > igc_xfree (data);
> > > }
> > > #else
> > > void free_glib_user_data (gpointer data, GClosure *closure)
> > > {
> > > return;
> > > }
> > > #endif
> > >
> > > Don't know where the allocation takes place.
> >
> > It's this code in gtkutil.h:
> >
> > #ifdef HAVE_MPS
> > INLINE gpointer
> > glib_user_data (void *o)
> > {
> > gpointer p = igc_xzalloc_ambig (sizeof (o));
> > memcpy (p, &o, sizeof (o));
> > return p;
> > }
> >
> > INLINE void *
> > get_glib_user_data (gpointer p)
> > {
> > return *(void **)p;
> > }
> > #else
> > INLINE gpointer
> > glib_user_data (void *o)
> > {
> > return (gpointer)o;
> > }
> >
> > INLINE void *
> > get_glib_user_data (gpointer p)
> > {
> > return (void *)p;
> > }
> > #endif
> >
> > Does that look correct to you?
> >
> > My understanding is that the GTK input method code is only used if
> > x_gtk_use_native_input is true (which we'll have to wait for the OP to
> > confirm or deny),
>
> `x-gtk-use-native-input` is nil here, if that's what you are asking.
>
> > but xg_create_frame_widgets always calls
> > gtk_im_multicontext_new, so the problem might be in the GTK code...
> >
> > Pip
> >
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Mon, 02 Dec 2024 16:28:02 GMT) Full text and rfc822 format available.Message #50 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Yikai Zhao <yikai <at> z1k.dev> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Mon, 02 Dec 2024 16:26:50 +0000
"Yikai Zhao" <yikai <at> z1k.dev> writes: > I have reproduced the issue with your patch, here's the relevant log: Thank you! So it seems we call XFilterEvent correctly but it incorrectly indicates that the keypress (event 2) should be handled by Emacs rather than the input method. That's rather puzzling, particularly since subsequent calls to XFilterEvent return 1, indicating that the key release is handled by the input method. I'm pretty much stumped at this point. It might be a timing difference between the MPS and non-MPS builds, but I think it's more likely to be a bug in our MPS code. > Please let me know if there's any other info I can provide. Well, you already tried setting x-gtk-use-native-input to t :-) One thing you could try is to run a full x11trace of the Emacs session and see whether anything unusual is in there. But that's not guaranteed to yield any results. Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Mon, 02 Dec 2024 16:52:02 GMT) Full text and rfc822 format available.Message #53 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com>, Po Lu <luangruo <at> yahoo.com> Cc: gerd.moellmann <at> gmail.com, yikai <at> z1k.dev, eller.helmut <at> gmail.com, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Mon, 02 Dec 2024 18:51:26 +0200
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, > Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org > Date: Mon, 02 Dec 2024 16:26:50 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> > > "Yikai Zhao" <yikai <at> z1k.dev> writes: > > > I have reproduced the issue with your patch, here's the relevant log: > > Thank you! So it seems we call XFilterEvent correctly but it incorrectly > indicates that the keypress (event 2) should be handled by Emacs rather > than the input method. That's rather puzzling, particularly since > subsequent calls to XFilterEvent return 1, indicating that the key > release is handled by the input method. > > I'm pretty much stumped at this point. It might be a timing difference > between the MPS and non-MPS builds, but I think it's more likely to be > a bug in our MPS code. > > > Please let me know if there's any other info I can provide. > > Well, you already tried setting x-gtk-use-native-input to t :-) > > One thing you could try is to run a full x11trace of the Emacs session > and see whether anything unusual is in there. But that's not guaranteed > to yield any results. Maybe Po Lu (CC'ed) could have some additional ideas or comments.
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Wed, 04 Dec 2024 04:57:01 GMT) Full text and rfc822 format available.Message #56 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Wed, 4 Dec 2024 12:55:04 +0800
Here attached the relevant output of "xscope".
t=116.64 is approximately the timestamp of a correct keypress (that
goes to fcitx);
t=116.83 is approximately the timestamp of an incorrect keypress (that
goes to emacs).
I just realized that you mentioned the x11trace tool. I will also try
to reproduce with x11trace later.
---
116.64: 120 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: GenericEvent
extension: XInputExtension
event type: 0002
data: (27)
116.64: Client 3 --> 140 bytes
............REQUEST: ChangeProperty
mode: Replace
window: WIN 06e000b4
property: <_NET_WM_USER_TIME>
type: <CARDINAL>
format: 20
data: 4b367e4c
............REQUEST: ChangeProperty
mode: Append
window: WIN 0020015a
property: <_client10>
type: <STRING>
format: 08
data:
"<^@^J^@`^@{^@^@^@^@^@^B6]\254L~6K\373^A^@^@\265^@\340^F^@^@^@^@\200^F^H^B,^Bb^A^@^@^A^@"
............REQUEST: SendEvent
propagate: False
destination: WIN 0020015a
event-mask: 0
event: ..............EVENT:
ClientMessage
format: 20
window: WIN 0020015a
type: <_XIM_PROTOCOL>
data: 2c 00 00 00 ec 02
116.64: 32 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: PropertyNotify
window: WIN 06e000b4
atom: <_NET_WM_USER_TIME>
time: TIM 4b367e51
state: NewValue
116.70: 120 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: GenericEvent
extension: XInputExtension
event type: 0003
data: (27)
116.71: Client 3 --> 20 bytes
............REQUEST: InternAtom
only-if-exists: False
name: "_client11"
116.71: 32 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............REPLY: InternAtom
atom: <_client11>
116.71: Client 3 --> 112 bytes
............REQUEST: ChangeProperty
mode: Append
window: WIN 0020015a
property: <_client11>
type: <STRING>
format: 08
data:
"<^@^J^@`^@{^@^@^@^@^@^C6`\254\221~6K\373^A^@^@\265^@\340^F^@^@^@^@\200^F^H^B,^Bb^A^@^@^A^@"
............REQUEST: SendEvent
propagate: False
destination: WIN 0020015a
event-mask: 0
event: ..............EVENT:
ClientMessage
format: 20
window: WIN 0020015a
type: <_XIM_PROTOCOL>
data: 2c 00 00 00 ed 02
116.71: 32 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: ClientMessage
source: SendEvent
format: 20
window: WIN 06e0001c
type: <_XIM_PROTOCOL>
data: 2c 00 00 00 ed fb
116.71: Client 3 --> 24 bytes
............REQUEST: GetProperty
delete: True
window: WIN 06e0001c
property: ATM 0000fbed
type: AnyPropertyType
long-offset: 00000000
116.71: 76 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............REPLY: GetProperty
format: 08
type: <STRING>
bytes-after: 00000000
value:
"<^@^J^@`^@{^@^A^@^@^@^C6`\254\221~6K\373^A^@^@\265^@\340^F^@^@^@^@^@^@^@^@,^Bb^A^@^@^@^@"
116.83: 120 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: GenericEvent
extension: XInputExtension
event type: 0002
data: (27)
116.83: Client 3 --> 164 bytes
............REQUEST: ChangeProperty
mode: Replace
window: WIN 06e000b4
property: <_NET_WM_USER_TIME>
type: <CARDINAL>
format: 20
data: 4b367f10
............REQUEST: SendEvent
propagate: False
destination: WIN 0020015a
event-mask: 0
event: ..............EVENT:
ClientMessage
format: 08
window: WIN 0020015a
type: <_XIM_PROTOCOL>
data: 3e 00 01 00 60 00
............REQUEST: ChangeProperty
mode: Append
window: WIN 0020015a
property: <_client12>
type: <STRING>
format: 08
data: "6^@^E^@`^@{^@^L^@^@^@^F^@^H^@^P^@^D^@,^@\256^A"
............REQUEST: SendEvent
propagate: False
destination: WIN 0020015a
event-mask: 0
event: ..............EVENT:
ClientMessage
format: 20
window: WIN 0020015a
type: <_XIM_PROTOCOL>
data: 18 00 00 00 ee 02
116.83: 32 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: PropertyNotify
window: WIN 06e000b4
atom: <_NET_WM_USER_TIME>
time: TIM 4b367f10
state: NewValue
116.83: 32 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: ClientMessage
source: SendEvent
format: 08
window: WIN 06e0001c
type: <_XIM_PROTOCOL>
data: 37 00 01 00 60 00
116.83: Client 3 --> 92 bytes
............REQUEST: ChangeProperty
mode: Append
window: WIN 0020015a
property: <_client13>
type: <STRING>
format: 08
data: "6^@^E^@`^@{^@^L^@^@^@^F^@^H^@^P^@^D^@,^@\256^A"
............REQUEST: SendEvent
propagate: False
destination: WIN 0020015a
event-mask: 0
event: ..............EVENT:
ClientMessage
format: 20
window: WIN 0020015a
type: <_XIM_PROTOCOL>
data: 18 00 00 00 ef 02
116.83: 32 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: ClientMessage
source: SendEvent
format: 08
window: WIN 06e0001c
type: <_XIM_PROTOCOL>
data: 37 00 01 00 60 00
116.83: Client 3 --> 324 bytes
............REQUEST: SetClipRectangles
ordering: UnSorted
gc: GXC 06e006c5
clip-x-origin: 0
clip-y-origin: 0
rectangles: (1)
............REQUEST: RenderRequest
RENDERREQUEST: RenderFillRectangles
op: Src
dest: PICTURE 06e000fc
color: COLOR r:fdfd g:f6f6 b:e3e3 a:ffff
rectangles: (1)
............REQUEST: RenderRequest
RENDERREQUEST: RenderCompositeGlyphs8
op: Over
source: PICTURE 06e006cc
dest: PICTURE 06e000fc
mask format: None
glyphset: GLYPHSET 06e00104
x-src: 44
y-src: 424
items:
delta x: 44
delta y: 424
glyph item 8 string: "I"
............REQUEST: ChangeGC
gc: GXC 06e006c5
value-mask: clip-mask
value-list:
clip-mask: None
............REQUEST: SetClipRectangles
ordering: UnSorted
gc: GXC 06e006c5
clip-x-origin: 0
clip-y-origin: 0
rectangles: (1)
............REQUEST: RenderRequest
RENDERREQUEST: RenderFillRectangles
op: Src
dest: PICTURE 06e000fc
color: COLOR r:fdfd g:f6f6 b:e3e3 a:ffff
rectangles: (1)
............REQUEST: ChangeGC
gc: GXC 06e006c5
value-mask: clip-mask
value-list:
clip-mask: None
............REQUEST: SetClipRectangles
ordering: UnSorted
gc: GXC 06e0012f
clip-x-origin: 0
clip-y-origin: 0
rectangles: (1)
............REQUEST: RenderRequest
RENDERREQUEST: RenderFillRectangles
op: Src
dest: PICTURE 06e000fc
color: COLOR r:6565 g:7b7b b:8383 a:ffff
rectangles: (1)
............REQUEST: ChangeGC
gc: GXC 06e0012f
value-mask: clip-mask
value-list:
clip-mask: None
............REQUEST: ChangeProperty
mode: Append
window: WIN 0020015a
property: <_client14>
type: <STRING>
format: 08
data: "6^@^E^@`^@{^@^L^@^@^@^F^@^H^@^P^@^D^@5^@\256^A"
............REQUEST: SendEvent
propagate: False
destination: WIN 0020015a
event-mask: 0
event: ..............EVENT:
ClientMessage
format: 20
window: WIN 0020015a
type: <_XIM_PROTOCOL>
data: 18 00 00 00 f3 02
116.84: 32 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: ClientMessage
source: SendEvent
format: 08
window: WIN 06e0001c
type: <_XIM_PROTOCOL>
data: 37 00 01 00 60 00
116.84: Client 3 --> 16 bytes
............REQUEST: DOUBLE-BUFFER-Request
minor opcode: 03
data: (3)
116.90: 120 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: GenericEvent
extension: XInputExtension
event type: 0003
data: (27)
116.90: Client 3 --> 112 bytes
............REQUEST: ChangeProperty
mode: Append
window: WIN 0020015a
property: <_client15>
type: <STRING>
format: 08
data:
"<^@^J^@`^@{^@^@^@^@^@^C^Zw\254Q<del>6K\373^A^@^@\265^@\340^F^@^@^@^@\200^F^H^B,^Bb^A^@^@^A^@"
............REQUEST: SendEvent
propagate: False
destination: WIN 0020015a
event-mask: 0
event: ..............EVENT:
ClientMessage
format: 20
window: WIN 0020015a
type: <_XIM_PROTOCOL>
data: 2c 00 00 00 f5 02
116.90: 32 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: ClientMessage
source: SendEvent
format: 20
window: WIN 06e0001c
type: <_XIM_PROTOCOL>
data: 2c 00 00 00 ee fb
116.90: Client 3 --> 24 bytes
............REQUEST: GetProperty
delete: True
window: WIN 06e0001c
property: ATM 0000fbee
type: AnyPropertyType
long-offset: 00000000
116.90: 76 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............REPLY: GetProperty
format: 08
type: <STRING>
bytes-after: 00000000
value:
"<^@^J^@`^@{^@^A^@^@^@^C^Zw\254Q<del>6K\373^A^@^@\265^@\340^F^@^@^@^@^@^@^@^@,^Bb^A^@^@^@^@"
116.90: Client 3 --> 44 bytes
............REQUEST: SendEvent
propagate: False
destination: WIN 0020015a
event-mask: 0
event: ..............EVENT:
ClientMessage
format: 08
window: WIN 0020015a
type: <_XIM_PROTOCOL>
data: 3e 00 01 00 60 00
116.93: 120 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: GenericEvent
extension: XInputExtension
event type: 0002
data: (27)
116.93: Client 3 --> 140 bytes
............REQUEST: ChangeProperty
mode: Replace
window: WIN 06e000b4
property: <_NET_WM_USER_TIME>
type: <CARDINAL>
format: 20
data: 4b367f73
............REQUEST: ChangeProperty
mode: Append
window: WIN 0020015a
property: <_client16>
type: <STRING>
format: 08
data:
"<^@^J^@`^@{^@^@^@^@^@^B^^{\254s<del>6K\373^A^@^@\265^@\340^F^@^@^@^@\200^F^H^B,^Bb^A^@^@^A^@"
............REQUEST: SendEvent
propagate: False
destination: WIN 0020015a
event-mask: 0
event: ..............EVENT:
ClientMessage
format: 20
window: WIN 0020015a
type: <_XIM_PROTOCOL>
data: 2c 00 00 00 f6 02
116.93: 32 bytes <-- X11 Server 3 (pid 3359 Xorg)
..............EVENT: PropertyNotify
window: WIN 06e000b4
atom: <_NET_WM_USER_TIME>
time: TIM 4b367f73
state: NewValue
On Tue, Dec 3, 2024 at 12:26 AM Pip Cet <pipcet <at> protonmail.com> wrote:
>
> "Yikai Zhao" <yikai <at> z1k.dev> writes:
>
> > I have reproduced the issue with your patch, here's the relevant log:
>
> Thank you! So it seems we call XFilterEvent correctly but it incorrectly
> indicates that the keypress (event 2) should be handled by Emacs rather
> than the input method. That's rather puzzling, particularly since
> subsequent calls to XFilterEvent return 1, indicating that the key
> release is handled by the input method.
>
> I'm pretty much stumped at this point. It might be a timing difference
> between the MPS and non-MPS builds, but I think it's more likely to be
> a bug in our MPS code.
>
> > Please let me know if there's any other info I can provide.
>
> Well, you already tried setting x-gtk-use-native-input to t :-)
>
> One thing you could try is to run a full x11trace of the Emacs session
> and see whether anything unusual is in there. But that's not guaranteed
> to yield any results.
>
> Pip
>
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Thu, 06 Feb 2025 00:20:02 GMT) Full text and rfc822 format available.Message #59 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Yikai Zhao <yikai <at> z1k.dev> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Thu, 06 Feb 2025 00:18:53 +0000
"Yikai Zhao" <yikai <at> z1k.dev> writes: > Here attached the relevant output of "xscope". I know this must be inconvenient, but can you try to check whether the bug has resolved itself in the meantime? I'm not a hundred percent certain that the recent X changes might have had an effect, but there was an issue with X popup menus, so maybe... Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Mon, 10 Feb 2025 04:29:03 GMT) Full text and rfc822 format available.Message #62 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Mon, 10 Feb 2025 12:28:40 +0800
Hi, On Thu, Feb 6, 2025 at 8:18 AM Pip Cet <pipcet <at> protonmail.com> wrote: > > "Yikai Zhao" <yikai <at> z1k.dev> writes: > > > Here attached the relevant output of "xscope". > > I know this must be inconvenient, No problem at all. > but can you try to check whether the > bug has resolved itself in the meantime? I'm not a hundred percent > certain that the recent X changes might have had an effect, but there > was an issue with X popup menus, so maybe... I just quickly tested with the newest version of feature/igc and it does seem to have resolved the issue! I will now try to use this mps version as my daily driver and see if it's completely resolved or just reduced the probability. (Previously I switched back to master from the mps version because of this bug. Now I can continue to daily test the mps version. yeah) I will let you know the result in a day or two. Thanks for your help! Yikai
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Tue, 11 Feb 2025 11:46:02 GMT) Full text and rfc822 format available.Message #65 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Tue, 11 Feb 2025 19:45:14 +0800
Well, bad news, it still happens :( Although I might say that it seems to happen less frequently. But my memory is not reliable and there may be other factors in play... On Mon, Feb 10, 2025 at 12:28 PM Yikai Zhao <yikai <at> z1k.dev> wrote: > > Hi, > > On Thu, Feb 6, 2025 at 8:18 AM Pip Cet <pipcet <at> protonmail.com> wrote: > > > > "Yikai Zhao" <yikai <at> z1k.dev> writes: > > > > > Here attached the relevant output of "xscope". > > > > I know this must be inconvenient, > > No problem at all. > > > but can you try to check whether the > > bug has resolved itself in the meantime? I'm not a hundred percent > > certain that the recent X changes might have had an effect, but there > > was an issue with X popup menus, so maybe... > > I just quickly tested with the newest version of feature/igc and it > does seem to have resolved the issue! I will now try to use this mps > version as my daily driver and see if it's completely resolved or just > reduced the probability. (Previously I switched back to master from > the mps version because of this bug. Now I can continue to daily test > the mps version. yeah) I will let you know the result in a day or > two. > > Thanks for your help! > > Yikai
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Tue, 11 Feb 2025 18:22:02 GMT) Full text and rfc822 format available.Message #68 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Yikai Zhao <yikai <at> z1k.dev>, Po Lu <luangruo <at> yahoo.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Tue, 11 Feb 2025 18:21:24 +0000
"Yikai Zhao" <yikai <at> z1k.dev> writes:
> Well, bad news, it still happens :(
Oh no! I spent a bit too much time on this weird bug. First, can we
agree that this reproduces it, even though things aren't working quite
the way I'd expect them to?
0. install fcitx
1. launch Xnest :1
2. DISPLAY=:1 fcitx5 &
3. MODIFIERS=@im=fcitx DISPLAY=:1 emacs -Q
4. keep hitting "a" and clicking on the text cursor (not the
black-on-black popup window)
5. after a while, a latin "a" will appear, once in a while, even though
it was never selected in the popup window.
6. with the master branch, that doesn't happen.
Does this describe the bug you're seeing?
I downloaded and rebuilt Xlib to investigate this, and discovered this
code in imDefLkup.c, which deals with "fabricated serials":
Bool
_XimIsFabricatedSerial(
Xim im,
XKeyEvent *event)
{
/* GTK2 XIM module sets serial=0. */
if (!event->serial || !im->private.proto.enable_fabricated_order)
return IS_FABRICATED(im) ? True : False;
if (event->serial == im->private.proto.fabricated_serial)
return True;
if (!im->private.proto.fabricated_serial)
return False;
/* Rotate time */
if (event->time < im->private.proto.fabricated_time) {
if (event->time >= 1000)
im->private.proto.fabricated_time = 0;
} else if (event->time - im->private.proto.fabricated_time > 1000 ) {
fprintf(stderr,
"%s,%d: The application disposed a key event with %ld serial.\n",
__FILE__, __LINE__,
im->private.proto.fabricated_serial);
im->private.proto.enable_fabricated_order = False;
if (IS_FABRICATED(im)) {
if (event->serial)
im->private.proto.fabricated_serial = event->serial;
return True;
}
}
return False;
}
As you can see, if this function is ever called for an event which
happened *before* fabricated_time, fabricated_time is reset to 0
(because the code assumes a 32-bit wraparound occurred), and then the
next event triggers the warning message and, if IS_FABRICATED(im) is
true, will be reported as fabricated, which means it will not be
filtered, which means it will show up as an ASCII keystroke.
But Emacs calls XFilterEvent in conjunction with GDK in a weird way,
sometimes out of order (and sometimes twice for the same event? I'm not
sure I understand this), and once in a while such reordering will result
in the fake time wraparound happening and key presses not being
filtered.
IOW, Emacs treats XFilterEvent as a pure function, but it has side
effects which can cause a second return value, or one generated out of
order, to differ when input methods are in use.
I assume the reason this happens with feature/igc but not with master is
that handle_one_xevent can have significant (not user-noticeable, but
enough for the time between keypress and keyrelease, maybe) and
unexpected latency when GC is happening, but not with the old GC.
I don't have a proper fix, but can you try this patch and see what
behavior is like with it?
diff --git a/src/xterm.c b/src/xterm.c
index 80108190590..59d1d7fdaa6 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -24131,7 +24131,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
copy.xkey.window = xev->event;
copy.xkey.root = xev->root;
copy.xkey.subwindow = xev->child;
- copy.xkey.time = xev->time;
+ fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
+ copy.xkey.time = CurrentTime;
copy.xkey.state = state;
xi_convert_button_state (&xev->buttons, ©.xkey.state);
@@ -24189,7 +24190,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
xkey.window = xev->event;
xkey.root = xev->root;
xkey.subwindow = xev->child;
- xkey.time = xev->time;
+ fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
+ xkey.time = CurrentTime;
xkey.state = state;
xkey.x = lrint (xev->event_x);
xkey.y = lrint (xev->event_y);
@@ -24631,7 +24633,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
xkey.window = xev->event;
xkey.root = xev->root;
xkey.subwindow = xev->child;
- xkey.time = xev->time;
+ fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
+ xkey.time = CurrentTime;
xkey.state = xi_convert_event_keyboard_state (xev);
xkey.x = lrint (xev->event_x);
xkey.y = lrint (xev->event_y);
At least over here (with the imperfect setup described above), I haven't
been able to reproduce the falsely-unfiltered key issue.
> Although I might say that it seems to happen less frequently. But my
> memory is not reliable and there may be other factors in play...
If I'm right, this is a subtle timing issue which was latent for a while
but became an acute problem when the somewhat unpredictable GC timing of
MPS happened.
Please let me know whether the patch changes anything!
Thanks!
Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Wed, 12 Feb 2025 01:25:02 GMT) Full text and rfc822 format available.Message #71 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Yikai Zhao <yikai <at> z1k.dev>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Wed, 12 Feb 2025 09:24:01 +0800
Pip Cet <pipcet <at> protonmail.com> writes: > But Emacs calls XFilterEvent in conjunction with GDK in a weird way, > sometimes out of order (and sometimes twice for the same event? I'm not > sure I understand this), and once in a while such reordering will result > in the fake time wraparound happening and key presses not being > filtered. > > IOW, Emacs treats XFilterEvent as a pure function, but it has side > effects which can cause a second return value, or one generated out of > order, to differ when input methods are in use. > > I assume the reason this happens with feature/igc but not with master is > that handle_one_xevent can have significant (not user-noticeable, but > enough for the time between keypress and keyrelease, maybe) and > unexpected latency when GC is happening, but not with the old GC. > > I don't have a proper fix, but can you try this patch and see what > behavior is like with it? > > > diff --git a/src/xterm.c b/src/xterm.c > index 80108190590..59d1d7fdaa6 100644 > --- a/src/xterm.c > +++ b/src/xterm.c > @@ -24131,7 +24131,8 @@ handle_one_xevent (struct x_display_info *dpyinfo, > copy.xkey.window = xev->event; > copy.xkey.root = xev->root; > copy.xkey.subwindow = xev->child; > - copy.xkey.time = xev->time; > + fprintf (stderr, "ignoring time %ld\n", (long) xev->time); > + copy.xkey.time = CurrentTime; > copy.xkey.state = state; > xi_convert_button_state (&xev->buttons, ©.xkey.state); > > @@ -24189,7 +24190,8 @@ handle_one_xevent (struct x_display_info *dpyinfo, > xkey.window = xev->event; > xkey.root = xev->root; > xkey.subwindow = xev->child; > - xkey.time = xev->time; > + fprintf (stderr, "ignoring time %ld\n", (long) xev->time); > + xkey.time = CurrentTime; > xkey.state = state; > xkey.x = lrint (xev->event_x); > xkey.y = lrint (xev->event_y); > @@ -24631,7 +24633,8 @@ handle_one_xevent (struct x_display_info *dpyinfo, > xkey.window = xev->event; > xkey.root = xev->root; > xkey.subwindow = xev->child; > - xkey.time = xev->time; > + fprintf (stderr, "ignoring time %ld\n", (long) xev->time); > + xkey.time = CurrentTime; > xkey.state = xi_convert_event_keyboard_state (xev); > xkey.x = lrint (xev->event_x); > xkey.y = lrint (xev->event_y); > > At least over here (with the imperfect setup described above), I haven't > been able to reproduce the falsely-unfiltered key issue. I don't think this is correct, but Emacs is not supposed to hand events for which XFilterEvent has already been involved over to GDK. It is for this reason that all key press events which are registered by Emacs's input window and filtered are withheld from GDK, as it generates GDK events in a separate event queue that is polled long after handle_one_xevent returns (and the time at which GTK's input method conversion transpires is further away still). But this is only material if GTK's XIM input module is enabled, for otherwise only non-key events are filtered by GTK, as XFilterEvent is not input extension-aware. Yikai, what is your GTK_IM_MODULE? You can ascertain this by enabling the GTK Inspector (I think a web search should provide ample instructions), starting `gtk3-demo', typing Ctrl+Shift+d, and displaying the General tab in the inspector window.
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Wed, 12 Feb 2025 12:37:02 GMT) Full text and rfc822 format available.Message #74 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Po Lu <luangruo <at> yahoo.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Wed, 12 Feb 2025 20:36:00 +0800
On Wed, Feb 12, 2025 at 2:21 AM Pip Cet <pipcet <at> protonmail.com> wrote:
>
> "Yikai Zhao" <yikai <at> z1k.dev> writes:
>
> > Well, bad news, it still happens :(
>
> Oh no! I spent a bit too much time on this weird bug. First, can we
> agree that this reproduces it, even though things aren't working quite
> the way I'd expect them to?
>
> 0. install fcitx
> 1. launch Xnest :1
> 2. DISPLAY=:1 fcitx5 &
> 3. MODIFIERS=@im=fcitx DISPLAY=:1 emacs -Q
> 4. keep hitting "a" and clicking on the text cursor (not the
> black-on-black popup window)
> 5. after a while, a latin "a" will appear, once in a while, even though
> it was never selected in the popup window.
> 6. with the master branch, that doesn't happen.
>
> Does this describe the bug you're seeing?
In step 4, by "clicking on the text cursor", you mean clicking on the
text cursor in the emacs buffer by mouse, right? I'm not sure what
this action does here, my initial bug report does not include this
step. Does this increase the probability of reproducing?
The result (step 5 and 6) does match what I'm describing.
I guess what really matters is 1. fcitx popup window is present, and
2. some keypress that should go to the fcitx goes to the emacs buffer.
As long as you see these results, I think it should be the same issue?
>
> I downloaded and rebuilt Xlib to investigate this, and discovered this
> code in imDefLkup.c, which deals with "fabricated serials":
>
> Bool
> _XimIsFabricatedSerial(
> Xim im,
> XKeyEvent *event)
> {
> /* GTK2 XIM module sets serial=0. */
> if (!event->serial || !im->private.proto.enable_fabricated_order)
> return IS_FABRICATED(im) ? True : False;
> if (event->serial == im->private.proto.fabricated_serial)
> return True;
> if (!im->private.proto.fabricated_serial)
> return False;
> /* Rotate time */
> if (event->time < im->private.proto.fabricated_time) {
> if (event->time >= 1000)
> im->private.proto.fabricated_time = 0;
> } else if (event->time - im->private.proto.fabricated_time > 1000 ) {
> fprintf(stderr,
> "%s,%d: The application disposed a key event with %ld serial.\n",
> __FILE__, __LINE__,
> im->private.proto.fabricated_serial);
> im->private.proto.enable_fabricated_order = False;
> if (IS_FABRICATED(im)) {
> if (event->serial)
> im->private.proto.fabricated_serial = event->serial;
> return True;
> }
> }
> return False;
> }
>
> As you can see, if this function is ever called for an event which
> happened *before* fabricated_time, fabricated_time is reset to 0
> (because the code assumes a 32-bit wraparound occurred), and then the
> next event triggers the warning message and, if IS_FABRICATED(im) is
> true, will be reported as fabricated, which means it will not be
> filtered, which means it will show up as an ASCII keystroke.
>
> But Emacs calls XFilterEvent in conjunction with GDK in a weird way,
> sometimes out of order (and sometimes twice for the same event? I'm not
> sure I understand this), and once in a while such reordering will result
> in the fake time wraparound happening and key presses not being
> filtered.
>
> IOW, Emacs treats XFilterEvent as a pure function, but it has side
> effects which can cause a second return value, or one generated out of
> order, to differ when input methods are in use.
>
> I assume the reason this happens with feature/igc but not with master is
> that handle_one_xevent can have significant (not user-noticeable, but
> enough for the time between keypress and keyrelease, maybe) and
> unexpected latency when GC is happening, but not with the old GC.
>
> I don't have a proper fix, but can you try this patch and see what
> behavior is like with it?
I tried this patch but I haven't reproduced the bug with this patch
yet. I will keep using it, because it also took me more time to
reproduce the issue yesterday.
In the meantime, now I feel strange that it took me a day to reproduce
the bug previously (On Feb 10, I initially reported that it seems ok,
but then I said it still happens after a longer time of usage on Feb
11). So I redid some of my testing:
- scratch/igc at 2024/11/24 (the version I used in my initial bug
report): can reproduce the issue with high probability (usually within
a few words. but less likely in the scratch buffer, more likely in a
buffer with complex content)
- feature/igc at 2025/02/10 (the version I tested days ago): cannot
reproduce within minutes of trying. (matches my report on Feb 10)
So I'm confident that the newest feature/igc version is different (at
least better) from the version at 2024/11/24. (But now I started to
worry if anything went wrong in my earlier testing... is it possible
that it's indeed fixed but I got something mixed..? I will also try to
test more and re-verify that conclusion )
Yikai
>
>
> diff --git a/src/xterm.c b/src/xterm.c
> index 80108190590..59d1d7fdaa6 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -24131,7 +24131,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> copy.xkey.window = xev->event;
> copy.xkey.root = xev->root;
> copy.xkey.subwindow = xev->child;
> - copy.xkey.time = xev->time;
> + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> + copy.xkey.time = CurrentTime;
> copy.xkey.state = state;
> xi_convert_button_state (&xev->buttons, ©.xkey.state);
>
> @@ -24189,7 +24190,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> xkey.window = xev->event;
> xkey.root = xev->root;
> xkey.subwindow = xev->child;
> - xkey.time = xev->time;
> + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> + xkey.time = CurrentTime;
> xkey.state = state;
> xkey.x = lrint (xev->event_x);
> xkey.y = lrint (xev->event_y);
> @@ -24631,7 +24633,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> xkey.window = xev->event;
> xkey.root = xev->root;
> xkey.subwindow = xev->child;
> - xkey.time = xev->time;
> + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> + xkey.time = CurrentTime;
> xkey.state = xi_convert_event_keyboard_state (xev);
> xkey.x = lrint (xev->event_x);
> xkey.y = lrint (xev->event_y);
>
> At least over here (with the imperfect setup described above), I haven't
> been able to reproduce the falsely-unfiltered key issue.
>
> > Although I might say that it seems to happen less frequently. But my
> > memory is not reliable and there may be other factors in play...
>
> If I'm right, this is a subtle timing issue which was latent for a while
> but became an acute problem when the somewhat unpredictable GC timing of
> MPS happened.
>
> Please let me know whether the patch changes anything!
>
> Thanks!
>
> Pip
>
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Wed, 12 Feb 2025 12:40:02 GMT) Full text and rfc822 format available.Message #77 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Po Lu <luangruo <at> yahoo.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Pip Cet <pipcet <at> protonmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Wed, 12 Feb 2025 20:39:23 +0800
[Message part 1 (text/plain, inline)]
On Wed, Feb 12, 2025 at 9:24 AM Po Lu <luangruo <at> yahoo.com> wrote: > Yikai, what is your GTK_IM_MODULE? You can ascertain this by enabling > the GTK Inspector (I think a web search should provide ample > instructions), starting `gtk3-demo', typing Ctrl+Shift+d, and displaying > the General tab in the inspector window. I opened GTK Inspector (either with gtk3-demo or emacs), but I cannot find IM_MODULE related info in General tab. See screenshots below. Is this expected? If it helps, the GTK_IM_MODULE environment variable is set to "fcitx".
[2025-02-12_20-38.png (image/png, attachment)]
[2025-02-12_20-37.png (image/png, attachment)]
[2025-02-12_20-37_1.png (image/png, attachment)]
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Wed, 12 Feb 2025 12:46:02 GMT) Full text and rfc822 format available.Message #80 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Po Lu <luangruo <at> yahoo.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Yikai Zhao <yikai <at> z1k.dev>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Wed, 12 Feb 2025 12:44:47 +0000
"Po Lu" <luangruo <at> yahoo.com> writes: > Pip Cet <pipcet <at> protonmail.com> writes: > >> But Emacs calls XFilterEvent in conjunction with GDK in a weird way, >> sometimes out of order (and sometimes twice for the same event? I'm not >> sure I understand this), and once in a while such reordering will result >> in the fake time wraparound happening and key presses not being >> filtered. >> >> IOW, Emacs treats XFilterEvent as a pure function, but it has side >> effects which can cause a second return value, or one generated out of >> order, to differ when input methods are in use. >> >> I assume the reason this happens with feature/igc but not with master is >> that handle_one_xevent can have significant (not user-noticeable, but >> enough for the time between keypress and keyrelease, maybe) and >> unexpected latency when GC is happening, but not with the old GC. >> >> I don't have a proper fix, but can you try this patch and see what >> behavior is like with it? >> >> >> diff --git a/src/xterm.c b/src/xterm.c >> index 80108190590..59d1d7fdaa6 100644 >> --- a/src/xterm.c >> +++ b/src/xterm.c >> @@ -24131,7 +24131,8 @@ handle_one_xevent (struct x_display_info *dpyinfo, >> copy.xkey.window = xev->event; >> copy.xkey.root = xev->root; >> copy.xkey.subwindow = xev->child; >> - copy.xkey.time = xev->time; >> + fprintf (stderr, "ignoring time %ld\n", (long) xev->time); >> + copy.xkey.time = CurrentTime; >> copy.xkey.state = state; >> xi_convert_button_state (&xev->buttons, ©.xkey.state); >> >> @@ -24189,7 +24190,8 @@ handle_one_xevent (struct x_display_info *dpyinfo, >> xkey.window = xev->event; >> xkey.root = xev->root; >> xkey.subwindow = xev->child; >> - xkey.time = xev->time; >> + fprintf (stderr, "ignoring time %ld\n", (long) xev->time); >> + xkey.time = CurrentTime; >> xkey.state = state; >> xkey.x = lrint (xev->event_x); >> xkey.y = lrint (xev->event_y); >> @@ -24631,7 +24633,8 @@ handle_one_xevent (struct x_display_info *dpyinfo, >> xkey.window = xev->event; >> xkey.root = xev->root; >> xkey.subwindow = xev->child; >> - xkey.time = xev->time; >> + fprintf (stderr, "ignoring time %ld\n", (long) xev->time); >> + xkey.time = CurrentTime; >> xkey.state = xi_convert_event_keyboard_state (xev); >> xkey.x = lrint (xev->event_x); >> xkey.y = lrint (xev->event_y); >> >> At least over here (with the imperfect setup described above), I haven't >> been able to reproduce the falsely-unfiltered key issue. > > I don't think this is correct I'm not sure I understand which part you think is incorrect. Passing CurrentTime as the time in the fake event we call XFilterEvent on is certainly a hack, not a proper fix (unless it works and nothing better can be found), but I said that. I've since confirmed that introducing a random delay before we call XFilterEvent makes the bug, if that's what I'm observing, appear on the master branch as well, so this is a timing issue in the XIM (not GTK IM) code. > , but Emacs is not supposed to hand events for which XFilterEvent has > already been involved over to GDK. It is for this reason that all key > press events which are registered by Emacs's input window and filtered > are withheld from GDK, as it generates GDK events in a separate event > queue that is polled long after handle_one_xevent returns (and the > time at which GTK's input method conversion transpires is further away > still). But this is only material if GTK's XIM input module is > enabled, for otherwise only non-key events are filtered by GTK, as > XFilterEvent is not input extension-aware. x_gtk_use_native_input is false. Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Mon, 17 Feb 2025 16:14:02 GMT) Full text and rfc822 format available.Message #83 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Po Lu <luangruo <at> yahoo.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Tue, 18 Feb 2025 00:13:02 +0800
I'm sorry to tell you that the issue still happens with your patch. I
don't see anything abnormal about the printed timestamps when the
issue happens (no unordered timestamps found).
Now I think maybe what you described is not the same issue that I
encountered. :(
To summarize: for feature/igc at 2025/02/10 with or without the patch,
the issue happens but at a much lower probability (compared to
scratch/igc at 2024/11/24)
I think I will try bisecting between the two versions and see what affects this.
On Wed, Feb 12, 2025 at 8:36 PM Yikai Zhao <yikai <at> z1k.dev> wrote:
>
> On Wed, Feb 12, 2025 at 2:21 AM Pip Cet <pipcet <at> protonmail.com> wrote:
> >
> > "Yikai Zhao" <yikai <at> z1k.dev> writes:
> >
> > > Well, bad news, it still happens :(
> >
> > Oh no! I spent a bit too much time on this weird bug. First, can we
> > agree that this reproduces it, even though things aren't working quite
> > the way I'd expect them to?
> >
> > 0. install fcitx
> > 1. launch Xnest :1
> > 2. DISPLAY=:1 fcitx5 &
> > 3. MODIFIERS=@im=fcitx DISPLAY=:1 emacs -Q
> > 4. keep hitting "a" and clicking on the text cursor (not the
> > black-on-black popup window)
> > 5. after a while, a latin "a" will appear, once in a while, even though
> > it was never selected in the popup window.
> > 6. with the master branch, that doesn't happen.
> >
> > Does this describe the bug you're seeing?
>
> In step 4, by "clicking on the text cursor", you mean clicking on the
> text cursor in the emacs buffer by mouse, right? I'm not sure what
> this action does here, my initial bug report does not include this
> step. Does this increase the probability of reproducing?
>
> The result (step 5 and 6) does match what I'm describing.
>
> I guess what really matters is 1. fcitx popup window is present, and
> 2. some keypress that should go to the fcitx goes to the emacs buffer.
> As long as you see these results, I think it should be the same issue?
>
> >
> > I downloaded and rebuilt Xlib to investigate this, and discovered this
> > code in imDefLkup.c, which deals with "fabricated serials":
> >
> > Bool
> > _XimIsFabricatedSerial(
> > Xim im,
> > XKeyEvent *event)
> > {
> > /* GTK2 XIM module sets serial=0. */
> > if (!event->serial || !im->private.proto.enable_fabricated_order)
> > return IS_FABRICATED(im) ? True : False;
> > if (event->serial == im->private.proto.fabricated_serial)
> > return True;
> > if (!im->private.proto.fabricated_serial)
> > return False;
> > /* Rotate time */
> > if (event->time < im->private.proto.fabricated_time) {
> > if (event->time >= 1000)
> > im->private.proto.fabricated_time = 0;
> > } else if (event->time - im->private.proto.fabricated_time > 1000 ) {
> > fprintf(stderr,
> > "%s,%d: The application disposed a key event with %ld serial.\n",
> > __FILE__, __LINE__,
> > im->private.proto.fabricated_serial);
> > im->private.proto.enable_fabricated_order = False;
> > if (IS_FABRICATED(im)) {
> > if (event->serial)
> > im->private.proto.fabricated_serial = event->serial;
> > return True;
> > }
> > }
> > return False;
> > }
> >
> > As you can see, if this function is ever called for an event which
> > happened *before* fabricated_time, fabricated_time is reset to 0
> > (because the code assumes a 32-bit wraparound occurred), and then the
> > next event triggers the warning message and, if IS_FABRICATED(im) is
> > true, will be reported as fabricated, which means it will not be
> > filtered, which means it will show up as an ASCII keystroke.
> >
> > But Emacs calls XFilterEvent in conjunction with GDK in a weird way,
> > sometimes out of order (and sometimes twice for the same event? I'm not
> > sure I understand this), and once in a while such reordering will result
> > in the fake time wraparound happening and key presses not being
> > filtered.
> >
> > IOW, Emacs treats XFilterEvent as a pure function, but it has side
> > effects which can cause a second return value, or one generated out of
> > order, to differ when input methods are in use.
> >
> > I assume the reason this happens with feature/igc but not with master is
> > that handle_one_xevent can have significant (not user-noticeable, but
> > enough for the time between keypress and keyrelease, maybe) and
> > unexpected latency when GC is happening, but not with the old GC.
> >
> > I don't have a proper fix, but can you try this patch and see what
> > behavior is like with it?
>
> I tried this patch but I haven't reproduced the bug with this patch
> yet. I will keep using it, because it also took me more time to
> reproduce the issue yesterday.
>
>
> In the meantime, now I feel strange that it took me a day to reproduce
> the bug previously (On Feb 10, I initially reported that it seems ok,
> but then I said it still happens after a longer time of usage on Feb
> 11). So I redid some of my testing:
>
> - scratch/igc at 2024/11/24 (the version I used in my initial bug
> report): can reproduce the issue with high probability (usually within
> a few words. but less likely in the scratch buffer, more likely in a
> buffer with complex content)
> - feature/igc at 2025/02/10 (the version I tested days ago): cannot
> reproduce within minutes of trying. (matches my report on Feb 10)
>
> So I'm confident that the newest feature/igc version is different (at
> least better) from the version at 2024/11/24. (But now I started to
> worry if anything went wrong in my earlier testing... is it possible
> that it's indeed fixed but I got something mixed..? I will also try to
> test more and re-verify that conclusion )
>
> Yikai
>
>
> >
> >
> > diff --git a/src/xterm.c b/src/xterm.c
> > index 80108190590..59d1d7fdaa6 100644
> > --- a/src/xterm.c
> > +++ b/src/xterm.c
> > @@ -24131,7 +24131,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> > copy.xkey.window = xev->event;
> > copy.xkey.root = xev->root;
> > copy.xkey.subwindow = xev->child;
> > - copy.xkey.time = xev->time;
> > + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> > + copy.xkey.time = CurrentTime;
> > copy.xkey.state = state;
> > xi_convert_button_state (&xev->buttons, ©.xkey.state);
> >
> > @@ -24189,7 +24190,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> > xkey.window = xev->event;
> > xkey.root = xev->root;
> > xkey.subwindow = xev->child;
> > - xkey.time = xev->time;
> > + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> > + xkey.time = CurrentTime;
> > xkey.state = state;
> > xkey.x = lrint (xev->event_x);
> > xkey.y = lrint (xev->event_y);
> > @@ -24631,7 +24633,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> > xkey.window = xev->event;
> > xkey.root = xev->root;
> > xkey.subwindow = xev->child;
> > - xkey.time = xev->time;
> > + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> > + xkey.time = CurrentTime;
> > xkey.state = xi_convert_event_keyboard_state (xev);
> > xkey.x = lrint (xev->event_x);
> > xkey.y = lrint (xev->event_y);
> >
> > At least over here (with the imperfect setup described above), I haven't
> > been able to reproduce the falsely-unfiltered key issue.
> >
> > > Although I might say that it seems to happen less frequently. But my
> > > memory is not reliable and there may be other factors in play...
> >
> > If I'm right, this is a subtle timing issue which was latent for a while
> > but became an acute problem when the somewhat unpredictable GC timing of
> > MPS happened.
> >
> > Please let me know whether the patch changes anything!
> >
> > Thanks!
> >
> > Pip
> >
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Mon, 17 Feb 2025 19:03:02 GMT) Full text and rfc822 format available.Message #86 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Yikai Zhao <yikai <at> z1k.dev> Cc: Po Lu <luangruo <at> yahoo.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Mon, 17 Feb 2025 19:02:03 +0000
"Yikai Zhao" <yikai <at> z1k.dev> writes:
> I'm sorry to tell you that the issue still happens with your patch. I
> don't see anything abnormal about the printed timestamps when the
> issue happens (no unordered timestamps found).
Oh no! It seems I missed some cases, which might explain it, but it's
also possible it's an entirely separate issue. Did it become less
frequent, at least?
> Now I think maybe what you described is not the same issue that I
> encountered. :(
Maybe. If you still have the time, can you try this extended patch
instead?
diff --git a/src/xterm.c b/src/xterm.c
index c3137945ac5..52052fcc9c3 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -13040,7 +13040,10 @@ x_dnd_begin_drag_and_drop (struct frame *f, Time time, Atom xaction,
!= event_display->xi2_opcode))
{
#endif
- if (!x_filter_event (event_display, &next_event))
+ XEvent event_copy = next_event;
+ if (event_copy.type == KeyPress || event_copy.type == KeyRelease)
+ event_copy.xkey.time = CurrentTime;
+ if (!x_filter_event (event_display, &event_copy))
handle_one_xevent (event_display,
&next_event, &finish, &hold_quit);
#ifdef HAVE_XINPUT2
@@ -17892,8 +17895,12 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
XFilterEvent because that's the one for which the IC
was created. */
+ //usleep (10000);
struct frame *f1;
+ if (event->type == KeyPress || event->type == KeyRelease)
+ if (event->xkey.time > 1)
+ emacs_abort();
#if defined HAVE_XINPUT2 && defined USE_GTK
bool xinput_event = false;
if (dpyinfo->supports_xi2
@@ -17976,9 +17983,13 @@ event_handler_gdk (GdkXEvent *gxev, GdkEvent *ev, gpointer data)
/* Filter events for the current X input method.
GTK calls XFilterEvent but not for key press and release,
so we do it here. */
+ XEvent xev_copy;
+ xev_copy = *xev;
+ fprintf (stderr, "ignoring time %ld\n", (long) xev_copy.xkey.time);
+ xev_copy.xkey.time = CurrentTime;
if ((xev->type == KeyPress || xev->type == KeyRelease)
&& dpyinfo
- && x_filter_event (dpyinfo, xev))
+ && x_filter_event (dpyinfo, &xev_copy))
{
unblock_input ();
return GDK_FILTER_REMOVE;
@@ -24131,7 +24142,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
copy.xkey.window = xev->event;
copy.xkey.root = xev->root;
copy.xkey.subwindow = xev->child;
- copy.xkey.time = xev->time;
+ fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
+ copy.xkey.time = CurrentTime;
copy.xkey.state = state;
xi_convert_button_state (&xev->buttons, ©.xkey.state);
@@ -24189,7 +24201,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
xkey.window = xev->event;
xkey.root = xev->root;
xkey.subwindow = xev->child;
- xkey.time = xev->time;
+ fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
+ xkey.time = CurrentTime;
xkey.state = state;
xkey.x = lrint (xev->event_x);
xkey.y = lrint (xev->event_y);
@@ -24631,7 +24644,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
xkey.window = xev->event;
xkey.root = xev->root;
xkey.subwindow = xev->child;
- xkey.time = xev->time;
+ fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
+ xkey.time = CurrentTime;
xkey.state = xi_convert_event_keyboard_state (xev);
xkey.x = lrint (xev->event_x);
xkey.y = lrint (xev->event_y);
@@ -25765,7 +25779,14 @@ XTread_socket (struct terminal *terminal, struct input_event *hold_quit)
/* Input extension key events are filtered inside
handle_one_xevent. */
#endif
- if (x_filter_event (dpyinfo, &event))
+ XEvent event_copy = event;
+ if (event_copy.type == KeyPress || event_copy.type == KeyRelease)
+ {
+ fprintf (stderr, "ignoring time %ld\n", (long) event.xkey.time);
+ event_copy.xkey.time = CurrentTime;
+ }
+
+ if (x_filter_event (dpyinfo, &event_copy))
continue;
#ifdef HAVE_XINPUT2
}
> To summarize: for feature/igc at 2025/02/10 with or without the patch,
> the issue happens but at a much lower probability (compared to
> scratch/igc at 2024/11/24)
Did you ever see this message?
fprintf(stderr,
"%s,%d: The application disposed a key event with %ld serial.\n",
__FILE__, __LINE__,
im->private.proto.fabricated_serial);
It should be printed on stderr when an out-of-order event arrives in
XFilterEvent.
> I think I will try bisecting between the two versions and see what affects this.
That sounds like a lot of work! Sorry I couldn't come up with anything
but the patch above, and I understand if you don't want to try it, but
if you do, please let me know how it goes!
And if you can find a better recipe for reproducing this, please let us
know, too.
Thanks again for the report.
Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Tue, 18 Feb 2025 01:47:02 GMT) Full text and rfc822 format available.Message #89 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Po Lu <luangruo <at> yahoo.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Tue, 18 Feb 2025 09:45:49 +0800
On Tue, Feb 18, 2025 at 3:02 AM Pip Cet <pipcet <at> protonmail.com> wrote:
>
> "Yikai Zhao" <yikai <at> z1k.dev> writes:
>
> > I'm sorry to tell you that the issue still happens with your patch. I
> > don't see anything abnormal about the printed timestamps when the
> > issue happens (no unordered timestamps found).
>
> Oh no! It seems I missed some cases, which might explain it, but it's
> also possible it's an entirely separate issue. Did it become less
> frequent, at least?
I'm not sure. As I said, the frequency in the new version without the
patch is already much lower, so I really cannot say about the
difference with or without the patch.
> > Now I think maybe what you described is not the same issue that I
> > encountered. :(
>
> Maybe. If you still have the time, can you try this extended patch
> instead?
Sure, I will. It will just take some time.
>
> diff --git a/src/xterm.c b/src/xterm.c
> index c3137945ac5..52052fcc9c3 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -13040,7 +13040,10 @@ x_dnd_begin_drag_and_drop (struct frame *f, Time time, Atom xaction,
> != event_display->xi2_opcode))
> {
> #endif
> - if (!x_filter_event (event_display, &next_event))
> + XEvent event_copy = next_event;
> + if (event_copy.type == KeyPress || event_copy.type == KeyRelease)
> + event_copy.xkey.time = CurrentTime;
> + if (!x_filter_event (event_display, &event_copy))
> handle_one_xevent (event_display,
> &next_event, &finish, &hold_quit);
> #ifdef HAVE_XINPUT2
> @@ -17892,8 +17895,12 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
> XFilterEvent because that's the one for which the IC
> was created. */
>
> + //usleep (10000);
> struct frame *f1;
>
> + if (event->type == KeyPress || event->type == KeyRelease)
> + if (event->xkey.time > 1)
> + emacs_abort();
> #if defined HAVE_XINPUT2 && defined USE_GTK
> bool xinput_event = false;
> if (dpyinfo->supports_xi2
> @@ -17976,9 +17983,13 @@ event_handler_gdk (GdkXEvent *gxev, GdkEvent *ev, gpointer data)
> /* Filter events for the current X input method.
> GTK calls XFilterEvent but not for key press and release,
> so we do it here. */
> + XEvent xev_copy;
> + xev_copy = *xev;
> + fprintf (stderr, "ignoring time %ld\n", (long) xev_copy.xkey.time);
> + xev_copy.xkey.time = CurrentTime;
> if ((xev->type == KeyPress || xev->type == KeyRelease)
> && dpyinfo
> - && x_filter_event (dpyinfo, xev))
> + && x_filter_event (dpyinfo, &xev_copy))
> {
> unblock_input ();
> return GDK_FILTER_REMOVE;
> @@ -24131,7 +24142,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> copy.xkey.window = xev->event;
> copy.xkey.root = xev->root;
> copy.xkey.subwindow = xev->child;
> - copy.xkey.time = xev->time;
> + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> + copy.xkey.time = CurrentTime;
> copy.xkey.state = state;
> xi_convert_button_state (&xev->buttons, ©.xkey.state);
>
> @@ -24189,7 +24201,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> xkey.window = xev->event;
> xkey.root = xev->root;
> xkey.subwindow = xev->child;
> - xkey.time = xev->time;
> + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> + xkey.time = CurrentTime;
> xkey.state = state;
> xkey.x = lrint (xev->event_x);
> xkey.y = lrint (xev->event_y);
> @@ -24631,7 +24644,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> xkey.window = xev->event;
> xkey.root = xev->root;
> xkey.subwindow = xev->child;
> - xkey.time = xev->time;
> + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> + xkey.time = CurrentTime;
> xkey.state = xi_convert_event_keyboard_state (xev);
> xkey.x = lrint (xev->event_x);
> xkey.y = lrint (xev->event_y);
> @@ -25765,7 +25779,14 @@ XTread_socket (struct terminal *terminal, struct input_event *hold_quit)
> /* Input extension key events are filtered inside
> handle_one_xevent. */
> #endif
> - if (x_filter_event (dpyinfo, &event))
> + XEvent event_copy = event;
> + if (event_copy.type == KeyPress || event_copy.type == KeyRelease)
> + {
> + fprintf (stderr, "ignoring time %ld\n", (long) event.xkey.time);
> + event_copy.xkey.time = CurrentTime;
> + }
> +
> + if (x_filter_event (dpyinfo, &event_copy))
> continue;
> #ifdef HAVE_XINPUT2
> }
>
> > To summarize: for feature/igc at 2025/02/10 with or without the patch,
> > the issue happens but at a much lower probability (compared to
> > scratch/igc at 2024/11/24)
>
> Did you ever see this message?
>
> fprintf(stderr,
> "%s,%d: The application disposed a key event with %ld serial.\n",
> __FILE__, __LINE__,
> im->private.proto.fabricated_serial);
>
> It should be printed on stderr when an out-of-order event arrives in
> XFilterEvent.
No, I didn't see this message.
>
> > I think I will try bisecting between the two versions and see what affects this.
>
> That sounds like a lot of work! Sorry I couldn't come up with anything
> but the patch above, and I understand if you don't want to try it, but
> if you do, please let me know how it goes!
>
> And if you can find a better recipe for reproducing this, please let us
> know, too.
>
> Thanks again for the report.
No problem at all, I will let you know if I find anything. Thank you
for your help.
Yikai
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Tue, 18 Feb 2025 13:07:02 GMT) Full text and rfc822 format available.Message #92 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Po Lu <luangruo <at> yahoo.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Tue, 18 Feb 2025 21:05:52 +0800
[Message part 1 (text/plain, inline)]
Hi,
I have finished bisecting between the two versions, I have identified
that it's this commit that lowers the frequency of the issue:
commit c425f10a30c96f45fe1ccce423851bf32b8cb8df: Make balancing
buffer intervals optional
Based on the change of this commit, I can also verify that, with the
newest version of feature/igc, when setting igc--balance-intervals to
t, the issue can be reproduced with similar high probability as
before.
I also tried your newest patch, but the issue still happens... I
modified your patch for a little bit to add some more debug info
(timestamps etc.) and recorded a video reproducing the issue. I hope
it helps. See attachments for the modified patch, the screencast video
and the log.
In the video, I typed: c e u i <space> c e u i <space> . Each "c e u
i" should translates to "测试" by fcitx and "<space>" should confirm it.
But note that the second "c" went straight to the emacs buffer. The
video also shows the live log on the left side, maybe it will be
helpful.
Yikai
On Tue, Feb 18, 2025 at 9:45 AM Yikai Zhao <yikai <at> z1k.dev> wrote:
>
> On Tue, Feb 18, 2025 at 3:02 AM Pip Cet <pipcet <at> protonmail.com> wrote:
> >
> > "Yikai Zhao" <yikai <at> z1k.dev> writes:
> >
> > > I'm sorry to tell you that the issue still happens with your patch. I
> > > don't see anything abnormal about the printed timestamps when the
> > > issue happens (no unordered timestamps found).
> >
> > Oh no! It seems I missed some cases, which might explain it, but it's
> > also possible it's an entirely separate issue. Did it become less
> > frequent, at least?
>
> I'm not sure. As I said, the frequency in the new version without the
> patch is already much lower, so I really cannot say about the
> difference with or without the patch.
>
> > > Now I think maybe what you described is not the same issue that I
> > > encountered. :(
> >
> > Maybe. If you still have the time, can you try this extended patch
> > instead?
>
> Sure, I will. It will just take some time.
>
> >
> > diff --git a/src/xterm.c b/src/xterm.c
> > index c3137945ac5..52052fcc9c3 100644
> > --- a/src/xterm.c
> > +++ b/src/xterm.c
> > @@ -13040,7 +13040,10 @@ x_dnd_begin_drag_and_drop (struct frame *f, Time time, Atom xaction,
> > != event_display->xi2_opcode))
> > {
> > #endif
> > - if (!x_filter_event (event_display, &next_event))
> > + XEvent event_copy = next_event;
> > + if (event_copy.type == KeyPress || event_copy.type == KeyRelease)
> > + event_copy.xkey.time = CurrentTime;
> > + if (!x_filter_event (event_display, &event_copy))
> > handle_one_xevent (event_display,
> > &next_event, &finish, &hold_quit);
> > #ifdef HAVE_XINPUT2
> > @@ -17892,8 +17895,12 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
> > XFilterEvent because that's the one for which the IC
> > was created. */
> >
> > + //usleep (10000);
> > struct frame *f1;
> >
> > + if (event->type == KeyPress || event->type == KeyRelease)
> > + if (event->xkey.time > 1)
> > + emacs_abort();
> > #if defined HAVE_XINPUT2 && defined USE_GTK
> > bool xinput_event = false;
> > if (dpyinfo->supports_xi2
> > @@ -17976,9 +17983,13 @@ event_handler_gdk (GdkXEvent *gxev, GdkEvent *ev, gpointer data)
> > /* Filter events for the current X input method.
> > GTK calls XFilterEvent but not for key press and release,
> > so we do it here. */
> > + XEvent xev_copy;
> > + xev_copy = *xev;
> > + fprintf (stderr, "ignoring time %ld\n", (long) xev_copy.xkey.time);
> > + xev_copy.xkey.time = CurrentTime;
> > if ((xev->type == KeyPress || xev->type == KeyRelease)
> > && dpyinfo
> > - && x_filter_event (dpyinfo, xev))
> > + && x_filter_event (dpyinfo, &xev_copy))
> > {
> > unblock_input ();
> > return GDK_FILTER_REMOVE;
> > @@ -24131,7 +24142,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> > copy.xkey.window = xev->event;
> > copy.xkey.root = xev->root;
> > copy.xkey.subwindow = xev->child;
> > - copy.xkey.time = xev->time;
> > + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> > + copy.xkey.time = CurrentTime;
> > copy.xkey.state = state;
> > xi_convert_button_state (&xev->buttons, ©.xkey.state);
> >
> > @@ -24189,7 +24201,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> > xkey.window = xev->event;
> > xkey.root = xev->root;
> > xkey.subwindow = xev->child;
> > - xkey.time = xev->time;
> > + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> > + xkey.time = CurrentTime;
> > xkey.state = state;
> > xkey.x = lrint (xev->event_x);
> > xkey.y = lrint (xev->event_y);
> > @@ -24631,7 +24644,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
> > xkey.window = xev->event;
> > xkey.root = xev->root;
> > xkey.subwindow = xev->child;
> > - xkey.time = xev->time;
> > + fprintf (stderr, "ignoring time %ld\n", (long) xev->time);
> > + xkey.time = CurrentTime;
> > xkey.state = xi_convert_event_keyboard_state (xev);
> > xkey.x = lrint (xev->event_x);
> > xkey.y = lrint (xev->event_y);
> > @@ -25765,7 +25779,14 @@ XTread_socket (struct terminal *terminal, struct input_event *hold_quit)
> > /* Input extension key events are filtered inside
> > handle_one_xevent. */
> > #endif
> > - if (x_filter_event (dpyinfo, &event))
> > + XEvent event_copy = event;
> > + if (event_copy.type == KeyPress || event_copy.type == KeyRelease)
> > + {
> > + fprintf (stderr, "ignoring time %ld\n", (long) event.xkey.time);
> > + event_copy.xkey.time = CurrentTime;
> > + }
> > +
> > + if (x_filter_event (dpyinfo, &event_copy))
> > continue;
> > #ifdef HAVE_XINPUT2
> > }
> >
> > > To summarize: for feature/igc at 2025/02/10 with or without the patch,
> > > the issue happens but at a much lower probability (compared to
> > > scratch/igc at 2024/11/24)
> >
> > Did you ever see this message?
> >
> > fprintf(stderr,
> > "%s,%d: The application disposed a key event with %ld serial.\n",
> > __FILE__, __LINE__,
> > im->private.proto.fabricated_serial);
> >
> > It should be printed on stderr when an out-of-order event arrives in
> > XFilterEvent.
>
> No, I didn't see this message.
>
> >
> > > I think I will try bisecting between the two versions and see what affects this.
> >
> > That sounds like a lot of work! Sorry I couldn't come up with anything
> > but the patch above, and I understand if you don't want to try it, but
> > if you do, please let me know how it goes!
> >
> > And if you can find a better recipe for reproducing this, please let us
> > know, too.
> >
> > Thanks again for the report.
>
> No problem at all, I will let you know if I find anything. Thank you
> for your help.
>
> Yikai
[log.txt (text/plain, attachment)]
[emacs.patch (text/x-patch, attachment)]
[issue.mp4 (video/mp4, attachment)]
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Tue, 18 Feb 2025 18:28:02 GMT) Full text and rfc822 format available.Message #95 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Yikai Zhao <yikai <at> z1k.dev> Cc: Po Lu <luangruo <at> yahoo.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Tue, 18 Feb 2025 18:27:25 +0000
"Yikai Zhao" <yikai <at> z1k.dev> writes: > Hi, > > I have finished bisecting between the two versions, I have identified > that it's this commit that lowers the frequency of the issue: > > commit c425f10a30c96f45fe1ccce423851bf32b8cb8df: Make balancing > buffer intervals optional> > Based on the change of this commit, I can also verify that, with the > newest version of feature/igc, when setting igc--balance-intervals to > t, the issue can be reproduced with similar high probability as > before. So it is a timing issue, most likely, we just don't know what changed precisely. My next suggestion would be to add random delays near the buffer_step function, in order to make the bug more likely, but it's hard to do and I still cannot reproduce the issue you are seeing here... > I also tried your newest patch, but the issue still happens... I > modified your patch for a little bit to add some more debug info > (timestamps etc.) and recorded a video reproducing the issue. I hope > it helps. See attachments for the modified patch, the screencast video > and the log. Thank you! That points to this commit by Po Lu in 2022: 8d0a2e4dce41fd811319e94e5f01e5fcf8b3c62a Fix build without X11 I18N * src/xterm.c (event_handler_gdk): (handle_one_xevent): (x_draw_window_cursor): (x_term_init): Fix build without HAVE_X_I18N. That commit adds a call to xg_filter_key to event_handler_gdk, but only if "current_count" is >= 0. I have tried to read the code, but I don't know what "current_count" is, why it's sometimes negative, and why in the case that it is negative, we call handle_one_xevent without ever calling xg_filter_key (x_filter_key now). That would lead to the key being handled, right? From my reading of the libx11 code, input methods won't work unless XFilterKey is called once for each event, not just some of them. > In the video, I typed: c e u i <space> c e u i <space> . Each "c e u > i" should translates to "测试" by fcitx and "<space>" should confirm it. > But note that the second "c" went straight to the emacs buffer. The > video also shows the live log on the left side, maybe it will be > helpful. Thanks! The other thing I notice is that you're using GenericEvent events, while my setup (where I haven't been able to reproduce the bug after my changes) doesn't seem to produce those. That might also be part of the issue. No patch for now, it seems I was reproducing a different bug from the one you were seeing :-( Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Fri, 21 Feb 2025 21:26:02 GMT) Full text and rfc822 format available.Message #98 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Yikai Zhao <yikai <at> z1k.dev> Cc: Po Lu <luangruo <at> yahoo.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Fri, 21 Feb 2025 21:25:33 +0000
Pip Cet <pipcet <at> protonmail.com> writes:
> "Yikai Zhao" <yikai <at> z1k.dev> writes:
>
>> Hi,
>>
>> I have finished bisecting between the two versions, I have identified
>> that it's this commit that lowers the frequency of the issue:
>>
>> commit c425f10a30c96f45fe1ccce423851bf32b8cb8df: Make balancing
>> buffer intervals optional>
>
>> Based on the change of this commit, I can also verify that, with the
>> newest version of feature/igc, when setting igc--balance-intervals to
>> t, the issue can be reproduced with similar high probability as
>> before.
>
> So it is a timing issue, most likely, we just don't know what changed
> precisely. My next suggestion would be to add random delays near the
> buffer_step function, in order to make the bug more likely, but it's
> hard to do and I still cannot reproduce the issue you are seeing here...
>
>> I also tried your newest patch, but the issue still happens... I
>> modified your patch for a little bit to add some more debug info
>> (timestamps etc.) and recorded a video reproducing the issue. I hope
>> it helps. See attachments for the modified patch, the screencast video
>> and the log.
>
> Thank you! That points to this commit by Po Lu in 2022:
>
> 8d0a2e4dce41fd811319e94e5f01e5fcf8b3c62a Fix build without X11 I18N
>
> * src/xterm.c (event_handler_gdk):
> (handle_one_xevent):
> (x_draw_window_cursor):
> (x_term_init): Fix build without HAVE_X_I18N.
>
> That commit adds a call to xg_filter_key to event_handler_gdk, but only
> if "current_count" is >= 0. I have tried to read the code, but I don't
> know what "current_count" is, why it's sometimes negative, and why in
> the case that it is negative, we call handle_one_xevent without ever
> calling xg_filter_key (x_filter_key now). That would lead to the key
> being handled, right?
I've stared at that code for a while, and I don't think it's intentional
that we're occasionally failing to call x_filter_event on key release
events.
I understand you've tried a lot of things, and you're probably running
out of patience, but if you could try this patch, in *addition* to the
one you already have, that might provide further valuable input. Again,
I understand if you don't want to do that right now :-)
diff --git a/src/xterm.c b/src/xterm.c
index 72b681dfaaa..3a9ec542cde 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -18053,7 +18053,69 @@ event_handler_gdk (GdkXEvent *gxev, GdkEvent *ev, gpointer data)
current_hold_quit);
}
else
- current_finish = x_dispatch_event (xev, xev->xany.display);
+ {
+ struct x_display_info *dpyinfo;
+
+ dpyinfo = x_display_info_for_display (xev->xany.display);
+
+#ifdef HAVE_X_I18N
+ /* Filter events for the current X input method.
+ GTK calls XFilterEvent but not for key press and release,
+ so we do it here. */
+ XEvent xev_copy;
+ xev_copy = *xev;
+ DEBUG_PRINTF( "event_handler_gdk: ignoring time %ld\n",
+ (long) xev_copy.xkey.time);
+ xev_copy.xkey.time = CurrentTime;
+ if ((xev->type == KeyPress || xev->type == KeyRelease)
+ && dpyinfo
+ && x_filter_event (dpyinfo, &xev_copy))
+ {
+ DEBUG_PRINTF("filtered!");
+ unblock_input ();
+ return GDK_FILTER_REMOVE;
+ }
+#elif USE_GTK
+ if (dpyinfo && (dpyinfo->prefer_native_input
+ || x_gtk_use_native_input)
+ && (xev->type == KeyPress
+#ifdef HAVE_XINPUT2
+ /* GTK claims cookies for us, so we don't have to claim
+ them here. */
+ || (dpyinfo->supports_xi2
+ && xev->type == GenericEvent
+ && (xev->xgeneric.extension
+ == dpyinfo->xi2_opcode)
+ && ((xev->xgeneric.evtype
+ == XI_KeyPress)
+ || (xev->xgeneric.evtype
+ == XI_KeyRelease)))
+#endif
+ ))
+ {
+ struct frame *f;
+
+#ifdef HAVE_XINPUT2
+ if (xev->type == GenericEvent)
+ f = x_any_window_to_frame (dpyinfo,
+ ((XIDeviceEvent *) xev->xcookie.data)->event);
+ else
+#endif
+ f = x_any_window_to_frame (dpyinfo, xev->xany.window);
+
+ if (f && xg_filter_key (f, xev))
+ {
+ unblock_input ();
+ return GDK_FILTER_REMOVE;
+ }
+ }
+#endif
+
+ if (! dpyinfo)
+ current_finish = X_EVENT_NORMAL;
+ else
+ current_finish = x_dispatch_event (xev, xev->xany.display);
+ }
unblock_input ();
>> In the video, I typed: c e u i <space> c e u i <space> . Each "c e u
>> i" should translates to "测试" by fcitx and "<space>" should confirm it.
>> But note that the second "c" went straight to the emacs buffer. The
The second 'c' was received by event_handler_gdk while current_count was
-1, so we never called x_filter_event for it. I think that confuses
fcitx, which assumes all key presses and releases get filtered through
XFilterEvent.
So the patch above might fix that issue, but it doesn't explain (to me)
what current_count == -1 might mean and why it appears to happen more
often with MPS.
>> video also shows the live log on the left side, maybe it will be
>> helpful.
>
> Thanks! The other thing I notice is that you're using GenericEvent
> events, while my setup (where I haven't been able to reproduce the bug
> after my changes) doesn't seem to produce those. That might also be
> part of the issue.
FWIW, I've set up a qemu virtual machine to reproduce the bug, but I
haven't been successful so far.
Thanks for your patience so far, I'll continue trying to trigger this on
a virtual machine.
Pip
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Tue, 25 Feb 2025 15:21:02 GMT) Full text and rfc822 format available.Message #101 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Po Lu <luangruo <at> yahoo.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Tue, 25 Feb 2025 23:19:45 +0800
Hi,
On Sat, Feb 22, 2025 at 5:25 AM Pip Cet <pipcet <at> protonmail.com> wrote:
>
> Pip Cet <pipcet <at> protonmail.com> writes:
>
> > "Yikai Zhao" <yikai <at> z1k.dev> writes:
> >
> >> Hi,
> >>
> >> I have finished bisecting between the two versions, I have identified
> >> that it's this commit that lowers the frequency of the issue:
> >>
> >> commit c425f10a30c96f45fe1ccce423851bf32b8cb8df: Make balancing
> >> buffer intervals optional>
> >
> >> Based on the change of this commit, I can also verify that, with the
> >> newest version of feature/igc, when setting igc--balance-intervals to
> >> t, the issue can be reproduced with similar high probability as
> >> before.
> >
> > So it is a timing issue, most likely, we just don't know what changed
> > precisely. My next suggestion would be to add random delays near the
> > buffer_step function, in order to make the bug more likely, but it's
> > hard to do and I still cannot reproduce the issue you are seeing here...
> >
> >> I also tried your newest patch, but the issue still happens... I
> >> modified your patch for a little bit to add some more debug info
> >> (timestamps etc.) and recorded a video reproducing the issue. I hope
> >> it helps. See attachments for the modified patch, the screencast video
> >> and the log.
> >
> > Thank you! That points to this commit by Po Lu in 2022:
> >
> > 8d0a2e4dce41fd811319e94e5f01e5fcf8b3c62a Fix build without X11 I18N
> >
> > * src/xterm.c (event_handler_gdk):
> > (handle_one_xevent):
> > (x_draw_window_cursor):
> > (x_term_init): Fix build without HAVE_X_I18N.
> >
> > That commit adds a call to xg_filter_key to event_handler_gdk, but only
> > if "current_count" is >= 0. I have tried to read the code, but I don't
> > know what "current_count" is, why it's sometimes negative, and why in
> > the case that it is negative, we call handle_one_xevent without ever
> > calling xg_filter_key (x_filter_key now). That would lead to the key
> > being handled, right?
>
> I've stared at that code for a while, and I don't think it's intentional
> that we're occasionally failing to call x_filter_event on key release
> events.
>
> I understand you've tried a lot of things, and you're probably running
> out of patience, but if you could try this patch, in *addition* to the
> one you already have, that might provide further valuable input. Again,
> I understand if you don't want to do that right now :-)
No problem at all :) I should thank *you* all for trying to help.
I just tried this patch, it seems to fix the issue for me!
I also tried the version without the original "xev" and "CurrentTime"
hack (aka the patch below) and it still seems to work.
Just to be sure, I will keep using it for some time and let you know the result.
diff --git a/src/xterm.c b/src/xterm.c
index c3137945ac5..f34e84c52e4 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -18027,7 +18027,63 @@ event_handler_gdk (GdkXEvent *gxev, GdkEvent
*ev, gpointer data)
current_hold_quit);
}
else
- current_finish = x_dispatch_event (xev, xev->xany.display);
+ {
+ struct x_display_info *dpyinfo;
+
+ dpyinfo = x_display_info_for_display (xev->xany.display);
+
+#ifdef HAVE_X_I18N
+ /* Filter events for the current X input method.
+ GTK calls XFilterEvent but not for key press and release,
+ so we do it here. */
+ if ((xev->type == KeyPress || xev->type == KeyRelease)
+ && dpyinfo
+ && x_filter_event (dpyinfo, xev))
+ {
+ unblock_input ();
+ return GDK_FILTER_REMOVE;
+ }
+#elif USE_GTK
+ if (dpyinfo && (dpyinfo->prefer_native_input
+ || x_gtk_use_native_input)
+ && (xev->type == KeyPress
+#ifdef HAVE_XINPUT2
+ /* GTK claims cookies for us, so we don't have to claim
+ them here. */
+ || (dpyinfo->supports_xi2
+ && xev->type == GenericEvent
+ && (xev->xgeneric.extension
+ == dpyinfo->xi2_opcode)
+ && ((xev->xgeneric.evtype
+ == XI_KeyPress)
+ || (xev->xgeneric.evtype
+ == XI_KeyRelease)))
+#endif
+ ))
+ {
+ struct frame *f;
+
+#ifdef HAVE_XINPUT2
+ if (xev->type == GenericEvent)
+ f = x_any_window_to_frame (dpyinfo,
+ ((XIDeviceEvent *)
xev->xcookie.data)->event);
+ else
+#endif
+ f = x_any_window_to_frame (dpyinfo, xev->xany.window);
+
+ if (f && xg_filter_key (f, xev))
+ {
+ unblock_input ();
+ return GDK_FILTER_REMOVE;
+ }
+ }
+#endif
+
+ if (! dpyinfo)
+ current_finish = X_EVENT_NORMAL;
+ else
+ current_finish = x_dispatch_event (xev, xev->xany.display);
+ }
unblock_input ();
> >> In the video, I typed: c e u i <space> c e u i <space> . Each "c e u
> >> i" should translates to "测试" by fcitx and "<space>" should confirm it.
> >> But note that the second "c" went straight to the emacs buffer. The
>
> The second 'c' was received by event_handler_gdk while current_count was
> -1, so we never called x_filter_event for it. I think that confuses
> fcitx, which assumes all key presses and releases get filtered through
> XFilterEvent.
>
> So the patch above might fix that issue, but it doesn't explain (to me)
> what current_count == -1 might mean and why it appears to happen more
> often with MPS.
>
> >> video also shows the live log on the left side, maybe it will be
> >> helpful.
> >
> > Thanks! The other thing I notice is that you're using GenericEvent
> > events, while my setup (where I haven't been able to reproduce the bug
> > after my changes) doesn't seem to produce those. That might also be
> > part of the issue.
>
>
> FWIW, I've set up a qemu virtual machine to reproduce the bug, but I
> haven't been successful so far.
Regarding the test environment, there's one thing I maybe should have
mentioned earlier:
During all my testing, I'm running emacs packaged as AppImage
(https://github.com/blahgeek/emacs-appimage) because it's easier for
me to build libraries like MPS in the docker environment.
I didn't think that's relevant because AppImage is just plain emacs
executable with some extra dependencies. There's no namespaces or
other magic stuff like flatpak. Among the packaged dynamic libraries,
there's no X11 or gtk related ones either (the list is here:
https://github.com/blahgeek/emacs-appimage/blob/7d357757d90a23e42d0b5976c8ace33721915e04/scripts/postprocess.py#L60),
so there should not be some library version mismatch issue. Although,
the build environment is different from the execution environment, so
the x11 or gtk related libraries used during building are different
from the ones used during execution. But to my understanding that's
common and ok.
I'm not sure if it will help you reproduce or analyze the issue. If
so, I apologize for not mentioning it sooner.
>
> Thanks for your patience so far, I'll continue trying to trigger this on
> a virtual machine.
>
> Pip
>
Thanks
Yikai
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Fri, 28 Feb 2025 15:56:02 GMT) Full text and rfc822 format available.Message #104 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Yikai Zhao <yikai <at> z1k.dev> To: Pip Cet <pipcet <at> protonmail.com> Cc: Po Lu <luangruo <at> yahoo.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Fri, 28 Feb 2025 23:55:36 +0800
On Tue, Feb 25, 2025 at 11:19 PM Yikai Zhao <yikai <at> z1k.dev> wrote:
>
> Hi,
>
> On Sat, Feb 22, 2025 at 5:25 AM Pip Cet <pipcet <at> protonmail.com> wrote:
> >
> > Pip Cet <pipcet <at> protonmail.com> writes:
> >
> > > "Yikai Zhao" <yikai <at> z1k.dev> writes:
> > >
> > >> Hi,
> > >>
> > >> I have finished bisecting between the two versions, I have identified
> > >> that it's this commit that lowers the frequency of the issue:
> > >>
> > >> commit c425f10a30c96f45fe1ccce423851bf32b8cb8df: Make balancing
> > >> buffer intervals optional>
> > >
> > >> Based on the change of this commit, I can also verify that, with the
> > >> newest version of feature/igc, when setting igc--balance-intervals to
> > >> t, the issue can be reproduced with similar high probability as
> > >> before.
> > >
> > > So it is a timing issue, most likely, we just don't know what changed
> > > precisely. My next suggestion would be to add random delays near the
> > > buffer_step function, in order to make the bug more likely, but it's
> > > hard to do and I still cannot reproduce the issue you are seeing here...
> > >
> > >> I also tried your newest patch, but the issue still happens... I
> > >> modified your patch for a little bit to add some more debug info
> > >> (timestamps etc.) and recorded a video reproducing the issue. I hope
> > >> it helps. See attachments for the modified patch, the screencast video
> > >> and the log.
> > >
> > > Thank you! That points to this commit by Po Lu in 2022:
> > >
> > > 8d0a2e4dce41fd811319e94e5f01e5fcf8b3c62a Fix build without X11 I18N
> > >
> > > * src/xterm.c (event_handler_gdk):
> > > (handle_one_xevent):
> > > (x_draw_window_cursor):
> > > (x_term_init): Fix build without HAVE_X_I18N.
> > >
> > > That commit adds a call to xg_filter_key to event_handler_gdk, but only
> > > if "current_count" is >= 0. I have tried to read the code, but I don't
> > > know what "current_count" is, why it's sometimes negative, and why in
> > > the case that it is negative, we call handle_one_xevent without ever
> > > calling xg_filter_key (x_filter_key now). That would lead to the key
> > > being handled, right?
> >
> > I've stared at that code for a while, and I don't think it's intentional
> > that we're occasionally failing to call x_filter_event on key release
> > events.
> >
> > I understand you've tried a lot of things, and you're probably running
> > out of patience, but if you could try this patch, in *addition* to the
> > one you already have, that might provide further valuable input. Again,
> > I understand if you don't want to do that right now :-)
>
> No problem at all :) I should thank *you* all for trying to help.
>
> I just tried this patch, it seems to fix the issue for me!
> I also tried the version without the original "xev" and "CurrentTime"
> hack (aka the patch below) and it still seems to work.
> Just to be sure, I will keep using it for some time and let you know the result.
Update: after some days of use, I can confirm that this patch fixes
the issue for me.
>
> diff --git a/src/xterm.c b/src/xterm.c
> index c3137945ac5..f34e84c52e4 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -18027,7 +18027,63 @@ event_handler_gdk (GdkXEvent *gxev, GdkEvent
> *ev, gpointer data)
> current_hold_quit);
> }
> else
> - current_finish = x_dispatch_event (xev, xev->xany.display);
> + {
> + struct x_display_info *dpyinfo;
> +
> + dpyinfo = x_display_info_for_display (xev->xany.display);
> +
> +#ifdef HAVE_X_I18N
> + /* Filter events for the current X input method.
> + GTK calls XFilterEvent but not for key press and release,
> + so we do it here. */
> + if ((xev->type == KeyPress || xev->type == KeyRelease)
> + && dpyinfo
> + && x_filter_event (dpyinfo, xev))
> + {
> + unblock_input ();
> + return GDK_FILTER_REMOVE;
> + }
> +#elif USE_GTK
> + if (dpyinfo && (dpyinfo->prefer_native_input
> + || x_gtk_use_native_input)
> + && (xev->type == KeyPress
> +#ifdef HAVE_XINPUT2
> + /* GTK claims cookies for us, so we don't have to claim
> + them here. */
> + || (dpyinfo->supports_xi2
> + && xev->type == GenericEvent
> + && (xev->xgeneric.extension
> + == dpyinfo->xi2_opcode)
> + && ((xev->xgeneric.evtype
> + == XI_KeyPress)
> + || (xev->xgeneric.evtype
> + == XI_KeyRelease)))
> +#endif
> + ))
> + {
> + struct frame *f;
> +
> +#ifdef HAVE_XINPUT2
> + if (xev->type == GenericEvent)
> + f = x_any_window_to_frame (dpyinfo,
> + ((XIDeviceEvent *)
> xev->xcookie.data)->event);
> + else
> +#endif
> + f = x_any_window_to_frame (dpyinfo, xev->xany.window);
> +
> + if (f && xg_filter_key (f, xev))
> + {
> + unblock_input ();
> + return GDK_FILTER_REMOVE;
> + }
> + }
> +#endif
> +
> + if (! dpyinfo)
> + current_finish = X_EVENT_NORMAL;
> + else
> + current_finish = x_dispatch_event (xev, xev->xany.display);
> + }
>
> unblock_input ();
>
>
> > >> In the video, I typed: c e u i <space> c e u i <space> . Each "c e u
> > >> i" should translates to "测试" by fcitx and "<space>" should confirm it.
> > >> But note that the second "c" went straight to the emacs buffer. The
> >
> > The second 'c' was received by event_handler_gdk while current_count was
> > -1, so we never called x_filter_event for it. I think that confuses
> > fcitx, which assumes all key presses and releases get filtered through
> > XFilterEvent.
> >
> > So the patch above might fix that issue, but it doesn't explain (to me)
> > what current_count == -1 might mean and why it appears to happen more
> > often with MPS.
> >
> > >> video also shows the live log on the left side, maybe it will be
> > >> helpful.
> > >
> > > Thanks! The other thing I notice is that you're using GenericEvent
> > > events, while my setup (where I haven't been able to reproduce the bug
> > > after my changes) doesn't seem to produce those. That might also be
> > > part of the issue.
> >
> >
> > FWIW, I've set up a qemu virtual machine to reproduce the bug, but I
> > haven't been successful so far.
>
> Regarding the test environment, there's one thing I maybe should have
> mentioned earlier:
>
> During all my testing, I'm running emacs packaged as AppImage
> (https://github.com/blahgeek/emacs-appimage) because it's easier for
> me to build libraries like MPS in the docker environment.
>
> I didn't think that's relevant because AppImage is just plain emacs
> executable with some extra dependencies. There's no namespaces or
> other magic stuff like flatpak. Among the packaged dynamic libraries,
> there's no X11 or gtk related ones either (the list is here:
> https://github.com/blahgeek/emacs-appimage/blob/7d357757d90a23e42d0b5976c8ace33721915e04/scripts/postprocess.py#L60),
> so there should not be some library version mismatch issue. Although,
> the build environment is different from the execution environment, so
> the x11 or gtk related libraries used during building are different
> from the ones used during execution. But to my understanding that's
> common and ok.
>
> I'm not sure if it will help you reproduce or analyze the issue. If
> so, I apologize for not mentioning it sooner.
>
> >
> > Thanks for your patience so far, I'll continue trying to trigger this on
> > a virtual machine.
> >
> > Pip
> >
>
> Thanks
> Yikai
bug-gnu-emacs <at> gnu.org:bug#74590; Package emacs.
(Fri, 28 Feb 2025 16:55:02 GMT) Full text and rfc822 format available.Message #107 received at 74590 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Po Lu <luangruo <at> yahoo.com>, Yikai Zhao <yikai <at> z1k.dev> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Helmut Eller <eller.helmut <at> gmail.com>, 74590 <at> debbugs.gnu.org Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Date: Fri, 28 Feb 2025 16:54:20 +0000
"Yikai Zhao" <yikai <at> z1k.dev> writes:
> On Tue, Feb 25, 2025 at 11:19 PM Yikai Zhao <yikai <at> z1k.dev> wrote:
> Update: after some days of use, I can confirm that this patch fixes
> the issue for me.
Thank you, that is good news!
Po Lu, could you have a look at this patch? The rationale is we should
always call XFilterEvent for keyboard events, even if they arrive while
current_count is -1 (whatever that means), because they might be
intended for the input method.
From eaba03a308dce4ed66fb5c3260e90c4f4dc47aa4 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet <at> protonmail.com>
Subject: [PATCH] Always call XFilterEvent for X11 keyboard events (bug#74590)
* src/xterm.c (event_handler_gdk): Call 'x_filter_event' or
'xg_filter_key' even when 'current_count' is negative.
---
src/xterm.c | 84 ++++++++++++++++++++++++++---------------------------
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/src/xterm.c b/src/xterm.c
index c3137945ac5..54d8cb0f865 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -17966,59 +17966,59 @@ event_handler_gdk (GdkXEvent *gxev, GdkEvent *ev, gpointer data)
XEvent *xev = (XEvent *) gxev;
block_input ();
- if (current_count >= 0)
- {
- struct x_display_info *dpyinfo;
+ struct x_display_info *dpyinfo;
- dpyinfo = x_display_info_for_display (xev->xany.display);
+ dpyinfo = x_display_info_for_display (xev->xany.display);
#ifdef HAVE_X_I18N
- /* Filter events for the current X input method.
- GTK calls XFilterEvent but not for key press and release,
- so we do it here. */
- if ((xev->type == KeyPress || xev->type == KeyRelease)
- && dpyinfo
- && x_filter_event (dpyinfo, xev))
- {
- unblock_input ();
- return GDK_FILTER_REMOVE;
- }
+ /* Filter events for the current X input method.
+ GTK calls XFilterEvent but not for key press and release,
+ so we do it here. */
+ if ((xev->type == KeyPress || xev->type == KeyRelease)
+ && dpyinfo
+ && x_filter_event (dpyinfo, xev))
+ {
+ unblock_input ();
+ return GDK_FILTER_REMOVE;
+ }
#elif USE_GTK
- if (dpyinfo && (dpyinfo->prefer_native_input
- || x_gtk_use_native_input)
- && (xev->type == KeyPress
-#ifdef HAVE_XINPUT2
- /* GTK claims cookies for us, so we don't have to claim
- them here. */
- || (dpyinfo->supports_xi2
- && xev->type == GenericEvent
- && (xev->xgeneric.extension
- == dpyinfo->xi2_opcode)
- && ((xev->xgeneric.evtype
- == XI_KeyPress)
- || (xev->xgeneric.evtype
- == XI_KeyRelease)))
-#endif
- ))
- {
- struct frame *f;
+ if (dpyinfo && (dpyinfo->prefer_native_input
+ || x_gtk_use_native_input)
+ && (xev->type == KeyPress
+ #ifdef HAVE_XINPUT2
+ /* GTK claims cookies for us, so we don't have to claim
+ them here. */
+ || (dpyinfo->supports_xi2
+ && xev->type == GenericEvent
+ && (xev->xgeneric.extension
+ == dpyinfo->xi2_opcode)
+ && ((xev->xgeneric.evtype
+ == XI_KeyPress)
+ || (xev->xgeneric.evtype
+ == XI_KeyRelease)))
+ #endif
+ ))
+ {
+ struct frame *f;
#ifdef HAVE_XINPUT2
- if (xev->type == GenericEvent)
- f = x_any_window_to_frame (dpyinfo,
- ((XIDeviceEvent *) xev->xcookie.data)->event);
- else
+ if (xev->type == GenericEvent)
+ f = x_any_window_to_frame (dpyinfo,
+ ((XIDeviceEvent *) xev->xcookie.data)->event);
+ else
#endif
- f = x_any_window_to_frame (dpyinfo, xev->xany.window);
+ f = x_any_window_to_frame (dpyinfo, xev->xany.window);
- if (f && xg_filter_key (f, xev))
- {
- unblock_input ();
- return GDK_FILTER_REMOVE;
- }
+ if (f && xg_filter_key (f, xev))
+ {
+ unblock_input ();
+ return GDK_FILTER_REMOVE;
}
+ }
#endif
+ if (current_count >= 0)
+ {
if (! dpyinfo)
current_finish = X_EVENT_NORMAL;
else
--
2.48.1
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.