ToDo:
packageで1.5.32から1.5.31_1へ巻き戻すと今まで通り、ktermも含め問題なくXIMが動作することを確認した
次に調べるべきは…
XIM + ktermの動作なんてニッチ環境の不具合レポートなんて、ibusのIssue Trackerにはあがってないに違いない… Orz
diff -dur /usr/ports/textproc/ibus/Makefile Makefile
--- /usr/ports/textproc/ibus/Makefile 2025-06-11 17:14:07.686474000 +0900
+++ Makefile 2025-07-01 09:59:02.972368000 +0900
@@ -1,5 +1,6 @@
PORTNAME= ibus
-DISTVERSION= 1.5.32
+DISTVERSION= 1.5.31
+PORTREVISION= 1
CATEGORIES= textproc
MASTER_SITES= https://github.com/${PORTNAME}/${PORTNAME}/releases/download/${DISTVERSION}/
@@ -31,6 +32,7 @@
CONFIGURE_ARGS= --disable-install-tests \
--disable-python2 \
--disable-systemd-services \
+ --disable-python-library --disable-systemd \
--with-html-dir=${PREFIX}/share/doc \
--with-ucd-dir=${LOCALBASE}/share/unicode/ucd
@@ -78,7 +80,6 @@
GTK3_IMPLIES= WAYLAND
GTK3_LIB_DEPENDS= libdbus-1.so:devel/dbus \
libnotify.so:devel/libnotify
-GTK3_USES= vala:build
GTK3_USE= GNOME=cairo,gtk30,pango
GTK3_CONFIGURE_ENABLE= gtk3 libnotify
GTK3_LIBS= -lX11
@@ -97,7 +98,6 @@
WAYLAND_LIB_DEPENDS= libwayland-client.so:graphics/wayland \
libxkbcommon.so:x11/libxkbcommon
WAYLAND_CONFIGURE_ENABLE= wayland
-XIM_IMPLIES= GTK3
XIM_CONFIGURE_ENABLE= xim
.include <bsd.port.pre.mk>
@@ -107,10 +107,6 @@
.else
PLIST_SUB+= COMPDIR="@comment "
.endif
-
-post-configure:
- # Clean pre-generated source code, which may not match the options selected.
- ${MAKE} -C ${WRKSRC}/ui/gtk3 maintainer-clean-generic
post-install:
${MKDIR} ${STAGEDIR}${PREFIX}/etc/xdg/autostart
clientソースの差分から怪しい変更を探してみた
--- ibus-1.5.31/client/x11/main.c 2024-11-08 19:35:46.000000000 +0900
+++ ibus-1.5.32/client/x11/main.c 2025-04-08 21:57:26.000000000 +0900
@@ -2,7 +2,7 @@
/* vim:set et sts=4: */
/* ibus
* Copyright (C) 2007-2015 Peng Huang <shawn.p.huang@gmail.com>
- * Copyright (C) 2015-2023 Takao Fujiwara <takao.fujiwara1@gmail.com>
+ * Copyright (C) 2015-2025 Takao Fujiwara <takao.fujiwara1@gmail.com>
* Copyright (C) 2007-2015 Red Hat, Inc.
*
* main.c:
@@ -1363,7 +1363,7 @@
gdk_set_allowed_backends ("x11");
#endif
- gtk_init (&argc, &argv);
+ gdk_init (&argc, &argv);
XSetErrorHandler (_xerror_handler);
XSetIOErrorHandler (_xerror_io_handler);
--- ibus-1.5.31/util/IMdkit/i18nOffsetCache.c 2024-11-08 19:35:46.000000000 +0900
+++ ibus-1.5.32/util/IMdkit/i18nOffsetCache.c 2025-04-08 21:57:26.000000000 +0900
@@ -1,6 +1,6 @@
/*
* Copyright (C) 2014 Peng Huang <shawn.p.huang@gmail.com>
- * Copyright (C) 2014 Red Hat, Inc.
+ * Copyright (C) 2014-2025 Red Hat, Inc.
*
* Permission to use, copy, modify, distribute, and sell this
* software and its documentation for any purpose is hereby granted
@@ -83,10 +83,12 @@
}
if (++offset_cache->size > offset_cache->capacity) {
- offset_cache->capacity *= OFFSET_CACHE_GROWTH_FACTOR;
- offset_cache->data = (Xi18nAtomOffsetPair *) realloc (data,
+ Xi18nAtomOffsetPair *pair = (Xi18nAtomOffsetPair *) realloc (data,
offset_cache->capacity * sizeof (Xi18nAtomOffsetPair));
- if (offset_cache->data == NULL) {
+ offset_cache->capacity *= OFFSET_CACHE_GROWTH_FACTOR;
+ if (pair) {
+ offset_cache->data = pair;
+ } else {
offset_cache->data = data;
--offset_cache->size;
}
i18n offset cacheの変更のみのロールバックでは挙動は変わらなかったが、gtk_initへロールバックしたら1.5.31同様にktermへEUC-JP経由のXIM入力が出来るようになった
おそらく、gtk_init -> gdk_initで省略される初期化項目にXIMのi18n関連の項目が含まれ、localeの初期化が不十分でXIMメッセージのUTF-8 -> ja_JP.eucJPの変換が機能しなくなったのではと思う…
ktermへのXIM入力が機能しなくなった Orz
現状まとめ
ほかにもwww/firefoxやgraphics/gimp-appも問題無さそう…
原因究明には、kterm側がXIMから受け取ってる符号列がどうなっているか確認する必要がある？ → input.cレベルだとXIM側からCJK文字が渡ってきていないぽぃ
xterm/ktermの違いとして、XIMでやりとりする符号列がUTF-8 vs EUC-JPな違いがあるが、X11側で適宜変換しているはずなのだが…
XIMレベルで有りそうなバグとしては、ibus側からEUC-JPへマップできないコードポイントが紛れ込んでおり、UTF-8 → EUC-JP変換時にCJK文字が欠落しているとか…
掲示板でも不安定報告がある組み合わせだが、手元でも安定しない環境が出る模様
SATA SSD時代もZFSだと安定しないSSDがあったのでファームに癖があるのか？ それとも、Cache抜きの廉価版なのがいかんのか？
流石に人知れずハングするのは遠隔運用に難有りなので、時間が出来たら予備のSN850Xに換装予定
現状の実装方針
やはり、Encodeオプションのような形で、String処理時のEncodeを指定できる方がスマートな気がする…
その場合、サポートするEncode名とバックエンドの関係を定義するframeworkを実装すべきか？
現在の状況では、実用的なコードポイント集合はUnicode(UCS-4)になるので、CSI実装をする必要は無いと思われる
基本的なPrimitiveは、multibyte bufferからコードポイントを拾う・multibyte bufferへコードポイントを書き出す辺りか？
ISO-2022系のような状態遷移を持つ系はどうするのが良いのだろう… (一旦、UCS-4列にパックしてからiconvだと一時領域を割り当てる必要がある)
使用頻度がそれなりにありSADScript上での実行コストが高そうなString Primitive
現行のUnicode運用ではUCS2を考慮する必要は薄いが、UTF16は必要になる可能性が有り得るので、関数名は ToUTF8(UCS4 → UTF8)・FromUTF8(UTF8 → UCS4)辺り
内部実装用に未初期化なStringオブジェクトを割り当てるhelper functionを用意した方が良さそう…
手持ちのMeteor Lake-P (vendor=0x8086 device=0x7d55 subvendor=0x10f7 subdevice=0x8338 on Let'snote FV5)での動作状況まとめ
テスト環境は、stable/14に pull requestに上がっていた linuxkpiパッチを個別に取り込んだ環境
今のところ、Ver 6.8に drm/i915: Disable DSB usage specifically for LUTs当てて、xdmで使う(VT consoleを使わない)が実用上の落としどころか？
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記