はじめに
自宅でProxmoxを使ったホームラボを作りながら、Linux、ネットワーク、Dockerなどを少しずつ勉強しています。
まだ勉強中なので、この記事は「XpraやFcitx5の仕組みを完全に理解した人による解説」というより、実際に自分の環境で試行錯誤して、動くところまで持っていった記録兼備忘録です。
設定の意味をすべて理解できているわけではありませんが、同じところで詰まった人の参考になればと思い、残しておきます。
今回は、
WindowsノートPCで動かしているFirefoxをDebian側へ逃がし、WindowsにはGUIだけを表示する
環境を作りました。
最終的には、
- WindowsからXpraでDebianへ接続
- Debian上でFirefox ESRを実行
- Windows側にはFirefoxのウィンドウを表示
- Fcitx5 + Mozcで日本語を直接入力
- Xpraを再起動しても設定を維持
というところまで動作確認できました。
なぜこんなことをしたのか
仕事用のWindowsノートPCで、
- Meet / Zoom
- Office
- ブラウザ
- ChatGPTなどのWebアプリ
を同時に使っていると、PCの負荷が気になることがありました。
そこで、会議やOfficeはWindows側に残し、ブラウザ側の処理を自宅のDebian環境へ逃がしてみることにしました。
イメージはこんな感じです。
Windows PC
├─ Meet / Zoom
├─ Office
└─ Xpra Client
│
│ SSH / Tailscale
▼
Debian 13
├─ Xpra :100
├─ Firefox ESR
└─ Fcitx5 + Mozc
ここで逃がしているのはAIの推論処理そのものではありません。
ChatGPTなどのAIモデルはクラウド側で動いているので、Debian側へ移しているのは主に、
- Firefoxのプロセス
- JavaScriptの実行
- Webアプリの描画
- タブ管理
- キャッシュ
- ブラウザが使用するメモリ
などのクライアント側の処理です。
環境
今回確認した環境です。
Server OS : Debian GNU/Linux 13 (trixie)
Xpra : 6.5.3-r0
Display : :100
Browser : Firefox ESR
IME : Fcitx5 + Mozc
Client : Windows + Xpra Client
ネットワークはLANのほか、外部からTailscale経由でも試しています。
※ IPアドレス、ユーザー名などは記事用に省略しています。
最初はX11 Forwardingを試した
最初はXpraではなく、PuTTY + VcXsrvを使った普通のX11 Forwardingを試しました。
Debian側ではX11 Forwardingを有効にし、
X11Forwarding yes
xauth、x11-apps、Firefox ESRなどを用意しました。
Windows側では、
PuTTY
VcXsrv / XLaunch
を使用しました。
xclock をWindowsへ表示するところまでは成功。
「これならFirefoxもいけるのでは？」
と思ってFirefoxを起動したのですが、ここで問題が発生しました。
文字を入力してから表示されるまで数秒ほど遅れる。
LAN内でも発生したため、自分の環境ではFirefoxを常用するには厳しいと判断しました。
X11 Forwarding
↓
xclockは動く
↓
Firefoxも表示できる
↓
でも入力遅延が大きい
↓
実運用は断念
そこで別の方法としてXpraを試すことにしました。
Xpraを使ってみる
Debian 13へXpraを導入し、Windows側にもXpra Clientを入れました。
今回確認したXpraのバージョンは、
xpra --version
xpra v6.5.3-r0
でした。
まずはFirefoxを起動するセッションを作ります。
xpra start :100 --start=firefox-esr
状態は、
xpra list
で確認できます。
正常に起動すると、
LIVE session at :100
のように表示されました。
WindowsのXpra ClientからSSH transportで接続します。
Mode : SSH
Port : 22
Session : 100
実際のユーザー名やIPアドレスは各環境のものを指定します。
自分の環境では、Xpra用のTCPポートを直接公開するのではなくSSH経由で接続しています。
X11 Forwardingよりかなり快適になった
XpraでFirefoxを操作してみると、自分の環境ではX11 Forwardingで感じていた数秒単位の入力遅延がなくなりました。
文字入力、スクロール、通常のWeb操作については、LAN内ではほとんど遅延を意識せず使えました。
Tailscale経由でも試しましたが、ChatGPTをブラウザから使う程度であれば実用できると感じました。
ただし、これはあくまで自分の環境での体感です。
帯域、遅延、サーバー性能などによって結果は変わると思います。
次の問題：日本語が入力できない
ここからが今回一番ハマったところです。
Xpra上のFirefoxは快適に動いたのですが、
日本語入力ができませんでした。
Fcitx5とMozcはインストールしてあり、Fcitx5のプロセスも動いています。
それでもFirefoxでは英数字しか入力できません。
最初は、
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
を付けてFirefoxを起動したり、D-Bus周辺を調べたりしました。
しかし、なかなか日本語入力には切り替わりませんでした。
原因その1：XpraがIBusを選んでいた
Xpraの設定を確認すると、
/etc/xpra/conf.d/55_server_x11.conf
に、
input-method=auto
がありました。
Xpraのログを確認すると、
ibus-daemon is running
という記録もありました。
さらにFcitx5プロセスの環境を確認したところ、当初は、
GTK_IM_MODULE=ibus
QT_IM_MODULE=ibus
XMODIFIERS=@im=ibus
となっていました。
つまり、
Fcitx5は起動している
↓
でも入力メソッドの環境はIBusを向いている
という状態でした。
Xpraの input-method=auto が、自分の環境ではIBusを選択していたようです。
原因その2：Fcitx5にMozcが登録されていなかった
もう一つありました。
Fcitx5の設定、
~/.config/fcitx5/profile
を確認すると、最初はこうなっていました。
[Groups/0]
Name=Default
Default Layout=us
DefaultIM=keyboard-us
[Groups/0/Items/0]
Name=keyboard-us
Layout=
[GroupOrder]
0=Default
Mozcがいません。
Fcitx5自体が動いていても、使用するInput MethodとしてMozcが登録されていなければ日本語には切り替えられません。
そこで fcitx5-configtool を起動し、
Current Input Method
Keyboard - English (US)
Mozc
となるようMozcを追加しました。
GUIでは Only Show Current Language にチェックが入っているとMozcが見つからなかったため、チェックを外してMozcを検索しました。
Xpra側をFcitx5向けに設定する
次に、XpraがIBusを自動選択しないようにしました。
まず、
xpra set input-method keep
を実行。
確認すると、
xpra showconfig | grep '^input-method'
input-method (used) = 'keep'
となりました。
今回の環境では、この操作によって、
~/.config/xpra/conf.d/90_configure_tool.conf
が作成されました。
最終的に、このファイルを次のようにしています。
# Xpra + Fcitx5 / Mozc
input-method = keep
start-env = ['GTK_IM_MODULE=fcitx', 'QT_IM_MODULE=fcitx', 'XMODIFIERS=@im=fcitx']
start = fcitx5
start = firefox-esr
確認します。
xpra showconfig | grep -E '^(input-method|start-env|start )'
自分の環境では、
input-method (used) = 'keep'
start (used) = 'fcitx5', 'firefox-esr'
start-env (used) = '['GTK_IM_MODULE=fcitx', 'QT_IM_MODULE=fcitx', 'XMODIFIERS=@im=fcitx']'
となりました。
ここでも少しハマった
最初は、
~/.config/xpra/fcitx.conf
というファイルを自分で作ってみました。
しかし、
xpra showconfig
で確認すると設定が反映されていませんでした。
今回のXpra 6.5.3環境では、xpra set input-method keep を実行したことで、
~/.config/xpra/conf.d/90_configure_tool.conf
が生成され、こちらの設定が使用されました。
もう一つハマったのが start-env です。
最初は、
xpra set start-env 'GTK_IM_MODULE=fcitx'
xpra set start-env 'QT_IM_MODULE=fcitx'
xpra set start-env 'XMODIFIERS=@im=fcitx'
と3回実行しました。
ところが確認すると、
start-env (used) = '['XMODIFIERS=@im=fcitx']'
最後の一つしか残っていませんでした。
自分の環境では、この操作は追記ではなく置き換えになりました。
そのため最終的には、
start-env = ['GTK_IM_MODULE=fcitx', 'QT_IM_MODULE=fcitx', 'XMODIFIERS=@im=fcitx']
とまとめて設定しています。
再起動して確認
最後に、Xpraを一度完全に止めます。
xpra stop :100
そして、今度はオプションを付けず、
xpra start :100
だけで起動します。
WindowsのXpra Clientから再接続。
Firefox ESRが自動起動しました。
Firefoxの入力欄で、
Ctrl + Space
を押すとMozcへ切り替わり、
日本語を直接入力できました。
最終的には、
Windows Xpra Client
│
▼
Xpra :100
│
├── Fcitx5
│ └── Mozc
│
└── Firefox ESR
└── 日本語入力
という構成になりました。
Fcitx5が動いているのに入力できないときに見るところ
今回の経験から、同じ症状になったら自分は次の順番で確認すると思います。
- Xpraの
input-methodが何になっているか -
GTK_IM_MODULE/QT_IM_MODULE/XMODIFIERSがIBusとFcitx5のどちらを向いているか - Fcitx5とFirefoxが同じXpra DISPLAY / session D-Busを使っているか
- Fcitx5のCurrent Input MethodにMozcが登録されているか
- 設定変更後にXpraを完全に再起動して再現するか
今回学んだのは、
「fcitx5のプロセスが動いている」＝「FirefoxからMozcが使える」ではない
ということでした。
途中ではかなり混乱しました。
使ってみた感想
そもそもの目的だったWindowsノートPCの負荷軽減については、Xpra上のFirefoxからChatGPTを使っている間、以前のようにWindowsノートPCのファンが高回転し続ける状態が見られなくなりました。
ただし、CPU使用率、メモリ使用量、消費電力などをきちんと測定したわけではありません。
そのため、
「定量的に何％軽くなった」
とはまだ言えません。
現時点では、
体感では軽くなった
Xpraの操作性も実用範囲だった
という段階です。
このあたりは今後測定してみたいと思っています。
まとめ
今回やったことをまとめると、
Windowsのブラウザ負荷を減らしたい
↓
X11 Forwardingを試す
↓
Firefoxの入力遅延が大きい
↓
Xpraへ変更
↓
操作性はかなり改善
↓
日本語入力できない
↓
XpraがIBusを選択していることを確認
＋
Fcitx5にMozcが未登録だった
↓
input-method=keep
Fcitx用start-envを設定
Mozcを追加
↓
日本語入力成功
↓
再起動後も動作確認
となりました。
まだLinuxやX11、D-Bus、Input Method周辺は勉強中で、今回の作業でも理解が追いついていない部分があります。
ただ、ログやプロセスの環境を一つずつ確認していくことで、少なくとも自分の環境では原因を切り分けて動作させるところまで到達できました。
今後自分で環境を作り直すときの備忘録として、また同じような構成で困っている人の参考として残しておきます。