☰

バイパス：X11

tag-icon • tag-icon d-bus accessibility
バイパス：X11

コマンドラインからXアプリケーション（例：leafpad、ほとんどのアプリケーション）を実行すると、コンソールに次の警告が表示されます。

 ... dbind-WARNING **: ... Couldn't register with accessibility bus: Did
not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the 
reply timeout expired, or the network connection was broken.

（列の幅に合わせて切ります。）

このメッセージを受け取るのはなぜですか？私は何をすべきですか？公開したアプリは正常に動作しているようです。

これはUbuntu 18.04とDevuan 3.0 Beowulf（〜= Debian Buster）に表示されます。

答え1

これを取る：

export NO_AT_BRIDGE=1

/etc/environmentまたは~/.bashrc/などのどこかで実行されます~/.bash_profile。

この回避策は以下で推奨されます。このWikiページ（ドイツ語）またはここ（英語）、しかしなぜこれが必要なのか、正確に何をするのか理解できないので注意してください。

答え2

答えを直接見つけたのは幸いです。コメントで「理由」に対する回答を得るための背景情報があります。

このような設定でこのエラーが発生しました。 2台のラップトップ（仕事用に1つはKubuntuを使用し、もう1つは個人的にArchを使用）で作業しています。少し怠けて、他のラップトップを選ばずに代わりに使用しました。X11配信別名ssh -X。

バイパス：X11

概念的には、X11配信はVNC、RDPなどの「リモートデスクトップ」技術ですが、いくつかの違いがあります。リモートデスクトップビデオストリーミングを実行せずに、代わりにX11プロトコルネットワークアーキテクチャを使用します。

X11が想像された時代（1980年代！）、すべての画面とキーボード「リモート」：巨大なメイン​​フレームを持つユーザーのためのGUIアプリケーションをサポートするオペレーティングシステムプロセスを実行しています（通常みんなメインフレームを所有する組織のコンピューティングユーザー）。したがって、Ｘ１１では、ピクセル描画部分がクライアント側で行われる。

  VNC-style remote desktop                              X11 forwarding
  ────────────────────────                              ──────────────

┌─────[Client machine]──────┐        ┌──────[Client machine]────────────────────────────────┐
│                           │        │                                                      │
│  Runs VNC viewer app      │◄──┐    │ - Runs X server                                      │
│                           │   │    │ - Runs local GUI apps, i.e. those using DISPLAY=:0   │
│  • remote GUI embedded in │   │    │ - Renders remote GUI apps which X11-connect to it,   │
│    VNC viewer window      │   │    │   to network address like  client.local.lan:0        │
│                           │   │    │   Usually nowadays, ssh -X secures the X11 traffic   │
└───────────────────────────┘   │    │   by tunnelling it; so e.g. DISPLAY=localhost:10.0   │
                                │    │   This localhost is interpreted by app running on    │
                         network│    │   the server machine!                                │
                                │    │   Because SSH tunnel.             ┌─────┐   ┌─────┐  │
┌─────[Server machine]──────┐   │    │                           ┌──────►│ GUI │ … │ GUI │  │
│                           │   │    ├───────────────────┐◄──────┘       └─────┘   └─────┘  │
│  Runs VNC server app      │◄──┘ ┌─►│ SSH tunnel egress │                local X11 server  │
│                           │     │  └───────────────────┴──────────────────────────────────┘
│  • streams pixels of the  │     │
│    entire screen          │     │  ┌──────[Server machine]────────────────────────────────┐
│  • receives client input, │     │  │                                                      │
│    forwards it to GUIs    │     │  │ - May lack any screens, input devices, GPUs          │
│                           │     │  │ - May not run any X server                           │
│ ┌─────────┐   ┌─────────┐ │     │  │ - Yet, runs remote GUI apps, as OS processes         │
│ │ GUI app │ … │ GUI app │ │     │  │ - GUI stuff lives on client machine's X server       │
│ └─────────┘   └─────────┘ │     │  │ - Painting commands and input events                 │
│                           │     │  │   travel within the X11 connection.                  │
└───────────────────────────┘     │  │                                                      │
                                  │  │                                   ┌─────┐   ┌─────┐  │
                                  │  │                           ┌──────►│ app │ … │ app │  │
                                  │  ├────────────────────┐◄─────┘       └─────┘   └─────┘  │
                                  └─►│ SSH tunnel ingress │                 OS processes    │
                                     └────────────────────┴─────────────────────────────────┘

パーソナルコンピュータの一般的なユースケースでは、XサーバーとクライアントGUIは同じコンピュータで実行されるため、この興味深いX11プロトコルはローカルホストで実行されているとほとんど見えません。

しかし、実際のネットワークでも動作し、驚くほどうまく機能します！特にSSHに組み込まれている圧縮機能が補完されている場合は、-CBrave（ChromiumベースのWebブラウザ）を「リモート」で実行でき、ssh -CX pasocon.local braveWiFi経由でほぼ動作します。

バイパス：Linuxデスクトップからのアクセス

言うまでもなく、私は専門家でもなく、まったく慣れていません。しかし、私は2つのことを言います。

まず、X11転送アーキテクチャは、原則として支援技術に適していることを観察してください。たとえば、リモートデスクトップのネイティブビデオストリームを画面に読み込むことは（AIテクノロジがいつかこの問題を解決する可能性がありますが）、Xサーバーの状態やイベント/コマンドストリームを画面に読み込むよりも困難です。 X11プロトコルでは、アプリケーションは次のように言います。Xサーバー、この座標にこのフォントで「Lorem ipsum」テキストを描いてください。このボタンの色を変更してください。、等。

第二に、組み込みデスクトップ入力のVNC / RDPスタイル処理（フォーカスキャッチ、Ctrl-Alt-Delなどの特別なキーの組み合わせのエスケープ、キーボードレイアウト、クリップボードなどの適切な再マッピングなど）を取り巻くほとんどのうなずきは、単に休暇を実行しますすることです。 X11配信。クライアントコンピュータでは、リモートGUIは実際には可能な限り「ローカル」です。私のKDEプラズマはX11送達を区別しません。シナモンAlt-Tab インターフェイスのローカル KDE ウィンドウ。

バイパス: Freedesktop D-Bus

簡単に言えば、D-Busはオブジェクト指向スタイルのRPC（Remote Procedure Call）フレームワークです。これはLinuxデスクトップで広く使用されています（それに加えて）。たとえば、NetworkManager は dbus サービスを提供します。これらのネットワーク接続を表示および操作したり、システム接続が変更されたときにコールバックを受信するためにdbusを介して通信するアプリケーションを作成するのは比較的簡単です。デスクトップ通知（Eメール、インスタントメッセンジャー、ブラウザアプリケーションなどのポップアップ）は、広く統合されたorg.freedesktop.NotificationsD-Busサービスです。 Ayatanaインジケータ（トレイアイコン）もD-Busを介して機能します。もっとあります。

D-Busでアクセス可能な補助技術の拡張ポイントを提供することも意味があります。

D-Busで動作するコードを書くことで、このエラーメッセージがD-Busメソッド呼び出しの失敗に関連していることを100％確信できます。

...リモートアプリケーションが応答を送信していない、メッセージバスセキュリティポリシーが応答をブロックした、応答のタイムアウトが期限切れになった、またはネットワーク接続が失われました。

上記を組み合わせてください。、私が推測できるなぜ export NO_AT_BRIDGE=1私の状況に役立ちます。私はX11でCinnamon（GNOME派生）アプリケーションをKDEデスクトップに渡しています。 X.OrgがD-Busに接続されていない限り、2つのデスクトップD-Busインスタンスが魔法のように接続されると期待するのは愚かです。だから私はGTKの「AT_BRIDGE」（AccessibilityToolkit Bridge？）であいまいなコーナーケースに出会いました...それは何でも行きます。それを無効にすると、私の問題は解決しました。

もちろん、これが元の質問の問題にどの程度適用されるかはわかりません。しかし、それは明らかに関連する可動部分のいくつかの背景です。ファタイ

関連情報