☰

우회: 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.

이 해결 방법은 다음에서 권장됩니다.이 위키 페이지(독일어) 또는여기(영어), 하지만 왜 이것이 필요한지, 정확히 무엇을 하는지 이해하지 못하므로 주의하세요.

답변2

답변을 직접 찾으셨다니 다행입니다. 댓글에서 "이유"에 대한 답변을 얻을 수 있는 배경 정보가 더 있습니다.

이와 같은 설정에서 이 오류가 발생했습니다. 노트북 2대(업무용으로 하나는 Kubuntu를 사용하고 다른 하나는 개인적으로 Arch를 사용)로 작업 중입니다. 조금 게을러서 다른 노트북을 선택하지 않고 대신 사용했습니다.X11 전달일명 ssh -X.

우회: X11

개념적으로 X11 전달은 VNC, RDP와 같은 "원격 데스크톱" 기술이지만 몇 가지 차이점이 있습니다. 원격 데스크톱 비디오 스트리밍을 수행하지 않고 대신 X11 프로토콜 네트워크 아키텍처를 사용합니다.

X11이 구상되던 시절(1980년대!),모든 화면과 키보드"원격": 거대한 메인프레임이 많은 사용자를 위한 GUI 애플리케이션을 지원하는 운영 체제 프로세스를 실행하고 있습니다(보통모두메인프레임을 소유한 조직의 컴퓨팅 사용자). 따라서 X11에서는 픽셀 그리기 부분이 클라이언트 측에서 수행됩니다.

  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 기반 웹 브라우저)를 "원격"으로 실행할 수 ssh -CX pasocon.local brave있으며 WiFi를 통해 거의 작동합니다.

우회: Linux 데스크탑에서의 접근성

말할 것도 없고, 저는 전문가도 아니고 전혀 익숙하지도 않습니다. 하지만 저는 두 가지만 말씀드리겠습니다.

첫째, 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를 통해 통신하는 애플리케이션을 작성하는 것은 상대적으로 쉽습니다. 데스크탑 알림(이메일, 인스턴트 메신저, 브라우저 애플리케이션 등의 팝업)은 널리 통합된 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에 연결되어 있지 않은 한 두 개의 데스크톱 D-Bus 인스턴스가 마술처럼 연결될 것이라고 기대하는 것은 어리석은 일입니다. 그래서 나는 GTK의 "AT_BRIDGE"(AccessibilityToolkit Bridge?)에서 모호한 코너 케이스를 만났습니다... 그게 뭐든 간에요. 그것을 비활성화하면 내 문제가 해결되었습니다.

물론 이것이 원래 질문의 문제에 어느 정도 적용되는지는 확실하지 않습니다. 그러나 그것은 분명히 관련된 움직이는 부분에 대한 약간의 배경입니다. 화타이

관련 정보