X Window 시스템 핵심 프로토콜

X Window System core protocol
X Window 시스템 로고

X 윈도 시스템 코어 프로토콜은[1][2][3] X 윈도 시스템의 기본 프로토콜로, 유닉스 유사 및 기타 운영 체제에서 그래픽 사용자 인터페이스를 구축하는 데 사용되는 비트맵 디스플레이용 네트워크 윈도잉 시스템이다.X 윈도 시스템은 클라이언트-서버 모델을 기반으로 한다. 즉, 화면, 키보드, 마우스와 같은 입출력 하드웨어를 단일 서버가 제어하며, 모든 응용 프로그램은 서버를 통해 사용자와 다른 클라이언트와 상호 작용하면서 클라이언트 역할을 한다.이 상호작용은 X 윈도우 시스템 핵심 프로토콜에 의해 규제된다.X 윈도 시스템과 관련된 다른 프로토콜들이 존재하는데, 둘 다 X 윈도 시스템 코어 프로토콜의 상단에 구축되거나 별도의 프로토콜로 구축된다.

X Window System 핵심 프로토콜에서, 네트워크를 통해 비동기적으로 전송되는 패킷은 요청, 응답, 이벤트, 오류 등 4종류뿐이다.클라이언트가 서버로 요청을 보내 일부 작업을 수행하도록 요청(예: 새 창 작성)하고 보유하고 있는 데이터를 다시 전송하도록 한다.회신은 서버에 의해 전송되어 그러한 데이터를 제공한다.이벤트는 서버에 의해 전송되어 클라이언트에게 사용자 활동이나 관심 있는 기타 발생을 통지한다.오류란 서버가 의뢰 처리 중 발생한 오류를 클라이언트에 알리기 위해 발송한 패킷이다.요청은 회신, 이벤트 및 오류를 발생시킬 수 있다. 이것 외에 프로토콜은 패킷이 네트워크를 통해 전송되는 특정 순서를 의무화하지 않는다.코어 프로토콜에 대한 일부 확장이 존재하며, 각 확장자는 고유의 요청, 응답, 이벤트 및 오류를 가지고 있다.

X는 1984년 MIT에서 유래되었다(현재 발매된 X11은 1987년 9월에 나타났다).그것의 디자이너인 밥 셰이플러와 짐 게티스는 그것의 핵심 프로토콜이 "정책이 아닌 메커니즘을 만드는 것"이라는 초기 원리로 설정했다.결과적으로, 핵심 프로토콜은 클라이언트와 사용자 사이의 상호작용을 명시하지 않는다.이러한 상호작용은 ICCCM 및 freedesktop.org 규격과 [4]같은 별도의 규격의 대상이며, 일반적으로 주어진 위젯 세트를 사용하여 자동으로 시행된다.

개요

이 예에서 X 서버는 키보드와 마우스로부터 입력을 받아 화면에 표시한다.웹 브라우저와 터미널 에뮬레이터가 사용자의 워크스테이션에서 실행되고, 터미널 에뮬레이터는 원격 서버에서 실행되지만 사용자의 기계에 의해 제어된다.원격 응용 프로그램은 로컬과 동일하게 실행된다는 점에 유의하십시오.

서버와 클라이언트 간의 통신은 채널을 통해 패킷 교환으로 이루어진다.연결이 클라이언트에 의해 설정된다(클라이언트 시작 방법은 프로토콜에 지정되지 않음).클라이언트는 또한 사용할 바이트 순서와 프로토콜 버전에 대한 정보, 그리고 클라이언트가 서버가 사용할 것으로 기대하는 인증의 종류를 포함하는 첫 번째 패킷을 보낸다.서버는 접속의 수락 또는 거부를 기재한 패킷을 다시 보내거나, 추가 인증 요청으로 응답한다.연결이 허용되면, 허용 패킷은 클라이언트와 서버와의 후속 상호 작용에 사용할 데이터를 포함한다.

클라이언트와 서버 간의 상호 작용 예.

연결이 설정된 후, 다음 네 가지 유형의 패킷이 채널을 통해 클라이언트와 서버 간에 교환된다.

  1. 요청:클라이언트는 서버로부터 정보를 요청하거나 작업을 수행하도록 요청한다.
  2. 응답: 서버가 요청에 응답함모든 요청이 응답을 생성하는 것은 아니다.
  3. 이벤트: 서버는 클라이언트에게 키보드나 마우스 입력, 이동 중인 창, 크기 조정 또는 노출 등의 이벤트를 알려준다.
  4. 오류: 요청이 잘못된 경우 서버가 오류 패킷을 전송함요청이 대기 중이기 때문에 요청에 의해 생성된 오류 패킷이 즉시 전송되지 않을 수 있다.

요청 및 응답 패킷의 길이는 다양한 반면, 이벤트 및 오류 패킷의 길이는 32바이트로 고정되어 있다.

요청 패킷은 수신되는 즉시 서버에 의해 순차적으로 번호가 매겨진다: 클라이언트의 첫 번째 요청은 1, 두 번째 요청은 번호가 매겨진다.요청의 순차적 번호 중 최소 16비트는 요청에 의해 생성된 응답 및 오류 패킷(있는 경우)에 포함된다.서버가 현재 처리 중이거나 방금 처리를 완료한 요청의 순차적인 번호를 나타내는 이벤트 패킷에도 포함된다.

창문들

대부분의 그래픽 사용자 인터페이스에서 보통 윈도우라고 불리는 것을 X 윈도우 시스템에서는 최상위 윈도우라고 부른다.창이라는 용어는 다른 창, 즉 부모 창의 하위 창을 나타내는 데에도 사용된다.버튼, 메뉴, 아이콘 등과 같은 그래픽 요소는 하위 창을 사용하여 실현할 수 있다.

일부 창 배치 가능: 1은 전체 화면을 덮는 루트 창, 2와 3은 최상위 창, 4와 5는 2의 하위 창이다.부모 외부에 있는 창 부분은 보이지 않는다.

클라이언트는 창 생성을 요청할 수 있다.좀 더 정확히 말하면, 그것은 기존 창의 하위 창문의 창조의 생성을 요청할 수 있다.그 결과 클라이언트가 만든 창은 트리(서열)로 배열된다.이 트리의 루트는 루트 창으로, 시작할 때 서버가 자동으로 생성되는 특수 창입니다.다른 모든 창은 루트 창의 직접 또는 간접 하위 창입니다.최상위 창은 루트 창의 직접 하위 창입니다.눈에 띄게 루트 창은 가상 데스크톱만큼 크며 다른 모든 창 뒤에 있다.

창문의 내용이 시간이 지남에 따라 항상 보존된다고 보장되는 것은 아니다.특히 창을 이동, 크기 조정, 다른 창으로 덮을 때, 그리고 일반적으로 완전히 또는 부분적으로 보이지 않게 될 때 윈도우 내용이 파괴될 수 있다.특히 X 서버가 창 내용의 백업 저장소를 유지하고 있지 않으면 콘텐츠가 손실된다.클라이언트는 창이 유지되도록 백업 저장소를 요청할 수 있지만, 서버가 그렇게 할 의무는 없다.따라서 고객은 백업 저장소가 유지된다고 가정할 수 없다.창의 보이는 부분에 지정되지 않은 콘텐츠가 있는 경우, 클라이언트에게 윈도우 콘텐츠를 다시 그려야 한다는 것을 알리는 이벤트가 전송된다.

모든 창에는 창의 기하학(크기 및 위치), 배경 이미지, 백업 저장소가 요청되었는지 여부 등과 같은 관련 속성 집합이 있다.프로토콜은 클라이언트가 창의 속성을 검사하고 변경하도록 요청하는 것을 포함한다.

Windows는 다음과 같을 수 있다.InputOutput또는InputOnly.InputOutput창은 화면에 보여질 수 있고 그리는데 사용된다. InputOnly창은 절대 화면에 나타나지 않고 오직 입력만을 받기 위해 사용된다.

FVWM 창의 구조흰색 영역은 클라이언트 응용프로그램에 의해 생성되고 표시되는 창입니다.

보통 창문 주변에서 볼 수 있는 장식용 프레임과 제목바(버튼을 포함한 것)는 창을 만드는 클라이언트가 아니라 창관리자에 의해 만들어진다.윈도우 관리자는 또한 사용자가 윈도우 프레임을 클릭하거나 끌 때 윈도우 크기를 조정하는 등 이러한 요소와 관련된 입력을 처리한다.고객들은 대개 창구 관리자가 운영하는 변경사항을 무시하고 자신이 만든 창구에서 운영한다.거의 모든 현대적인 윈도우 매니저인 윈도우 매니저를 재육성하는 것은 최상위 윈도우의 부모를 루트가 아닌 윈도우로 바꾼다는 점을 고려해야 한다.코어 프로토콜의 관점에서 윈도 매니저는 클라이언트로, 다른 애플리케이션과 다르지 않다.

윈도우에 대한 데이터는 다음을 실행하여 얻을 수 있다.xwininfo프로그램을 짜다패스 더-tree 명령줄 인수, 이 프로그램은 식별자 및 형상 데이터와 함께 창의 하위 창 트리를 보여준다.

픽스맵스 및 그리기 용품

픽스맵은 그림 그리기에 사용될 수 있는 메모리 영역이다.창과 달리 픽스맵은 화면에 자동으로 표시되지 않는다.그러나 픽스맵(또는 그것의 일부)의 내용은 창으로 전송될 수 있고 그 반대의 경우도 가능하다.이것은 이중 버퍼링과 같은 기술을 허용한다.창문에서 할 수 있는 그래픽 조작의 대부분은 픽스맵에서도 할 수 있다.

Windows와 pixmaps는 집합적으로 그리기라고 명명되며, 그들의 컨텐츠 데이터는 서버에 저장된다.그러나 클라이언트는 추첨 가능한 내용을 서버에서 클라이언트로 전송하거나 그 반대로 전송하도록 요청할 수 있다.

그래픽 컨텍스트 및 글꼴

고객은 영역 정리, 영역 복사, 도면점, 선, 직사각형 및 텍스트와 같은 많은 그래픽 작업을 요청할 수 있다.모든 작업은 클리어 외에도 창문과 픽스맵 등 모든 도면에서도 가능하다.

그래픽 연산에 대한 대부분의 요청은 그래픽 연산의 파라미터를 포함하는 구조인 그래픽 컨텍스트를 포함한다.그래픽 컨텍스트에는 전경색, 배경색, 텍스트 글꼴 및 기타 그래픽 매개변수가 포함된다.그래픽 작업을 요청할 때 클라이언트는 그래픽 컨텍스트를 포함한다.그래픽 컨텍스트의 모든 매개변수가 작업에 영향을 미치는 것은 아니다. 예를 들어 글꼴은 선 그리기에 영향을 미치지 않는다.

핵심 프로토콜은 서버측 글꼴의 사용을 명시한다.[5]이러한 글꼴은 파일로 저장되며, 서버는 로컬 파일 시스템이나 폰트 서버라는 다른 프로그램에서 네트워크를 통해 직접 글꼴에 액세스한다.클라이언트는 서버에서 사용할 수 있는 글꼴 목록을 요청할 수 있으며, 서버가 글꼴을 로드(이미 로드되지 않은 경우)하거나 언로드(다른 클라이언트에서 사용하지 않는 경우)하도록 요청할 수 있다.클라이언트는 특정 글꼴로 그릴 때 특정 문자열이 차지하는 공간(예: 글꼴 등)과 글꼴에 대한 일반적인 정보를 요청할 수 있다.

그xfontsel프로그램을 통해 사용자는 글꼴의 글리프를 볼 수 있다.

글꼴 이름은 X Window 코어 프로토콜 수준의 임의 문자열이다.X 논리 글꼴 설명 규칙은[6] 속성에 따라 글꼴 이름을 지정하는 방법을 지정한다.이러한 규약은 글꼴에 부착할 수 있는 선택적 속성 값도 지정한다.

그xlsfonts프로그램은 서버에 저장된 글꼴 목록을 인쇄한다.그xfontsel프로그램은 글꼴의 글리프를 표시하며, 사용자가 다른 창에 글꼴을 붙여넣을 글꼴 이름을 선택할 수 있도록 한다.

서버측 글꼴의 사용은 현재 클라이언트측 글꼴에 대해 더 이상 사용되지 않는 것으로 간주되고 있다.[7]이러한 글꼴은 Xft 또는 카이로 라이브러리 및 XRender 확장의 지원을 받아 서버가 아닌 클라이언트가 렌더링한다.코어 프로토콜에는 클라이언트측 글꼴에 대한 사양이 제공되지 않는다.

리소스 및 식별자

윈도우, 픽스맵, 폰트 등에 관한 모든 데이터가 서버에 저장되어 있다.클라이언트는 이러한 개체의 식별자(서버와 상호 작용할 때 클라이언트가 해당 개체의 이름으로 사용하는 지정자)를 알고 있다.예를 들어, 클라이언트가 창 만들기를 원하는 경우, 지정된 식별자가 있는 창 만들기를 서버에 요청한다.식별자는 나중에 클라이언트가 창문에 그릴 문자열과 같이 요청하기 위해 사용할 수 있다.다음 개체는 서버에 존재하며 클라이언트가 숫자 식별자를 통해 알 수 있다.

  • Window
  • Pixmap
  • Font
  • Colormap(색상표, 아래 설명)
  • Graphic context

이러한 개체를 자원이라고 한다.클라이언트가 이러한 리소스 중 하나를 생성하도록 요청할 때, 클라이언트의 식별자도 지정한다.예를 들어, 새 창을 만들기 위해 클라이언트는 창의 속성(상위, 너비, 높이 등)과 창과 연결할 식별자를 모두 지정한다.

식별자는 가장 중요한 3개의 비트가 0인 32비트 정수다.모든 클라이언트는 새로운 리소스를 생성하는 데 사용할 수 있는 고유한 식별자 집합을 가지고 있다.이 세트는 서버에 의해 허용 패킷(연결이 허용됨을 알리기 위해 클라이언트에 보내는 패킷)에 포함된 두 개의 정수로 지정된다.클라이언트는 이 집합에 있는 식별자를 서로 충돌하지 않는 방식으로 선택한다. 즉, 창 사이의 두 개체, 픽스맵, 글꼴, 대괄호 및 그래픽 컨텍스트에는 동일한 식별자를 가질 수 없다.

일단 자원이 생성되면, 클라이언트는 자원에 대한 작업을 서버에 요청하기 위해 자원의 식별자를 사용한다.일부 작업은 지정된 리소스(예: 창 이동 요청)에 영향을 미치며, 다른 작업에서는 서버에서 저장된 리소스 데이터(예: 창 속성 요청)를 요청하기도 한다.

식별자는 클라이언트뿐만 아니라 서버에 고유하다. 예를 들어, 두 개의 다른 클라이언트에 의해 생성되더라도 동일한 식별자를 가진 두 개의 창은 없다.클라이언트는 식별자가 지정된 모든 개체에 액세스할 수 있다.특히 자신의 식별자가 자신이 만들 수 있는 식별자 집합 외부에 있더라도 다른 클라이언트가 생성한 자원에 접근할 수도 있다.

결과적으로, 동일한 서버에 연결된 두 클라이언트는 동일한 식별자를 사용하여 동일한 자원을 참조할 수 있다.예를 들어 클라이언트가 식별자 창을 만드는 경우0x1e00021그리고 이 번호를 통과한다.0x1e00021다른 애플리케이션(예: 다른 애플리케이션에서도 액세스할 수 있는 파일에 이 번호를 저장함으로써)으로 이 다른 애플리케이션은 동일한 창에서 작동할 수 있다.이 가능성은 예를 들어 X Window 버전의 Ghostview에 의해 악용된다. 이 프로그램은 하위 창을 만들어 환경 변수에 식별자를 저장하고 Ghostscript를 호출한다. 이 프로그램은 이 창에 표시할 PostScript 파일의 내용을 그린다.[8]

리소스는 일반적으로 생성된 클라이언트가 서버와의 연결을 닫을 때 파괴된다.그러나 연결을 닫기 전에 클라이언트는 서버에게 연결을 파괴하지 않도록 요청할 수 있다.

이벤트

이벤트는 클라이언트가 관심을 가질 만한 일이 발생했다는 것을 알리기 위해 서버가 클라이언트에 보내는 패킷이다.예를 들어 사용자가 키를 누르거나 마우스 버튼을 클릭할 때 이벤트가 전송된다.이벤트는 입력에만 사용되는 것이 아니다. 예를 들어, 이벤트는 주어진 창의 새 하위 창 작성을 나타내기 위해 전송된다.

모든 사건은 창문에 상대적이다.예를 들어 포인터가 창에 있을 때 사용자가 클릭하는 경우 이벤트는 해당 창에 상대적인 이벤트가 된다.이벤트 패킷은 해당 창의 식별자를 포함한다.

클라이언트는 다른 클라이언트로 이벤트 전송을 서버에 요청할 수 있다. 이것은 클라이언트 간의 통신에 사용된다.이러한 이벤트는 예를 들어 클라이언트가 현재 선택된 텍스트를 요청할 때 생성된다. 이 이벤트는 현재 선택 항목을 보관하는 창을 처리 중인 클라이언트로 전송된다.

그Expose이벤트는 파괴된 창의 영역이 보이고 내용이 보이면 전송된다.예를 들어, 창이 가려져 있고 서버가 백업 저장소를 유지하지 않는 경우, 창 내용이 일부 조건에서 파괴될 수 있다.서버가 다음을 생성함Expose창의 일부를 그려야 함을 고객에게 알리는 이벤트

이벤트 예: 창에서 키를 누르면 클라이언트가 변경할 수 있는 윈도우 이벤트 마스크에 따라 이벤트가 생성되어 클라이언트로 전송된다.

대부분의 종류의 이벤트는 고객이 이전에 관심을 표명한 경우에만 전송된다.고객들이 어떤 이벤트에만 관심을 가질 수 있기 때문이다.예를 들어, 클라이언트는 키보드 관련 이벤트에 관심이 있을 수 있지만 마우스 관련 이벤트에는 관심이 없을 수 있다.그러나 어떤 종류의 이벤트는 고객이 특별히 요청하지 않았더라도 고객에게 전송된다.

클라이언트는 창의 속성을 설정하여 보낼 이벤트 종류를 지정한다.예를 들어, 콘텐츠가 파괴되었을 때 창을 다시 그리기 위해, 클라이언트는 반드시Expose창을 다시 그릴 필요가 있음을 알려주는 이벤트그러나 클라이언트는 전송됨Expose이벤트는 클라이언트가 이전에 이러한 이벤트에 대한 관심을 표명한 경우에만 해당되며, 이는 창의 이벤트 마스크 속성을 적절하게 설정하여 수행된다.

서로 다른 클라이언트가 같은 창에서 이벤트를 요청할 수 있다.그들은 심지어 같은 창에 다른 이벤트 마스크를 설정할 수도 있다.예를 들어, 다른 클라이언트가 동일한 창에서 마우스 이벤트만 요청하는 동안 클라이언트는 창에서만 키보드 이벤트만 요청할 수 있다.이는 각 창마다 서버가 각 클라이언트에 대해 별도의 이벤트 마스크를 유지 관리하기 때문에 가능하다.그러나 각 창마다 한 번에 한 클라이언트만 선택할 수 있는 이벤트도 있다.특히 이러한 이벤트는 마우스 버튼 클릭 및 창 관리와 관련된 일부 변경 사항을 보고한다.

그xev프로그램은 창과 관련된 이벤트를 보여준다.특히.xev -id WID식별자 창과 관련된 가능한 모든 이벤트 요청WID인쇄를 할 수 있을 거야

예

다음은 블랙박스가 들어 있는 창을 만들고 키프레스에서 나가는 서버와 프로그램 간의 상호 작용의 가능한 예다.이 예에서, 서버는 클라이언트 요청이 회신을 생성하지 않기 때문에 회신을 보내지 않는다.이러한 요청은 오류를 발생시킬 수 있다.

  1. 클라이언트는 서버와의 연결을 열고 사용 중인 바이트 순서를 지정하는 초기 패킷을 전송한다.
  2. 서버는 루트 창의 식별자(예를 들어, 루트 창의 식별자)와 같은 다른 정보를 포함하는 적절한 패킷을 전송하여 연결을 승인한다(이 예에는 인증이 포함되지 않음).0x0000002b) 및 클라이언트가 생성할 수 있는 식별자.
  3. 클라이언트가 식별자를 사용하여 기본 그래픽 컨텍스트 생성을 요청함0x00200000(이 요청은 이 예제의 다른 요청과 마찬가지로 서버에서 응답을 생성하지 않음)
  4. 클라이언트가 서버에 최상위 창(즉, 루트 창으로 상위 창 지정)을 생성하도록 요청0x0000002b식별자 포함0x00200001, 사이즈 200x200, 포지션(10,10) 등
  5. 클라이언트가 창의 속성 변경을 요청함0x00200001, 받는 것에 관심이 있음을 명시한다.Expose, 그리고KeyPress사건들
  6. 클라이언트가 창을 요청함0x00200001매핑(화면에 표시됨)
  7. 창이 보이게 하고 그 내용을 그려야 할 때, 서버는 클라이언트에게 a를 전송한다.Expose사건
  8. 이 이벤트에 대해 클라이언트는 다음 항목을 전송하여 상자를 그리도록 요청한다.PolyFillRectangle창으로 부탁하다0x00200001및 그래픽 컨텍스트0x00200000

창문이 다른 창으로 덮여 있다가 다시 덮인 경우, 백업 저장소가 유지되지 않는다고 가정할 때:

  1. 서버가 다른 서버를 전송함Expose고객에게 창을 다시 그려야 한다고 알리는 이벤트
  2. 클라이언트가 다음을 전송하여 창을 다시 그리십시오.PolyFillRectangle부탁한다

키를 누른 경우:

  1. 서버가 a를 전송하는 경우KeyPress클라이언트에 이벤트 - 사용자가 키를 눌렀음을 알림
  2. 고객이 적절하게 반응(이 경우 종료)

컬러스

프로토콜 수준에서 색상은 픽셀 값이라고 불리는 32비트 부호화되지 않은 정수로 표현된다.다음 요소는 색의 표현에 영향을 미친다.

  1. 색의 깊이
  2. 빨간색, 녹색 및 파란색 강도 값을 포함하는 표인 colormap.
  3. 테이블이 색상을 나타내기 위해 사용되는 방법을 지정하는 시각적 유형

가장 쉬운 경우, 콜로맵은 각 행에 RGB 3배가 들어 있는 테이블이다.픽셀 값x에 포함된 색을 나타내다x-테이블의 제3열.클라이언트가 colormap의 항목을 변경할 수 있는 경우, 이 표현은 다음 항목에 의해 식별된다.PseudoColor 시각 수업비주얼 클래스StaticColor비슷하지만, 고객은 colormap의 항목을 변경할 수 없다.

가능한 시각적 클래스는 총 6개로, 각 클래스는 픽셀 값으로 RGB 삼중수소를 나타내는 다른 방법을 식별한다. PseudoColor, 그리고StaticColor두 개 입니다.다른 두 명은.GrayScale, 그리고StaticGray다른 점은 회색 음영만 보인다는 것이다.

나머지 두 비주얼 클래스는 픽셀 값을 3부분으로 쪼개고 적색, 녹색, 청색 세 개의 테이블을 사용하기 때문에 위의 것과 차이가 있다.이 색상 표현에 따르면 픽셀 값은 다음과 같이 RGB 3배로 변환된다.

  1. 픽셀 값은 비트 시퀀스로 간주된다.
  2. 이 순서는 세 부분으로 나뉘어져 있다.
  3. 이 세 개의 비트 덩어리는 각각 정수로 보여지고 각각의 개별 테이블에서 값을 찾기 위한 인덱스로 사용된다.

이 메커니즘은 콜로맵을 각 원색마다 하나씩 세 개의 개별 테이블로 구성하도록 요구한다.변환 결과는 여전히 강도 값의 3배다.이 표현을 사용하는 시각적 클래스는DirectColor, 그리고TrueColor고객이 대포를 바꿀 수 있는지에 따라 달라지는 것.

픽셀 값으로 색상을 나타내는 이 6가지 메커니즘은 모두 작동하기 위해 몇 가지 추가 파라미터를 필요로 한다.이러한 파라미터는 시각적 유형으로 수집되며, 여기에는 시각적 클래스와 색 표현에 대한 다른 파라미터가 포함된다.각 서버에는 고정된 시각 유형 집합이 있으며, 각 유형은 숫자 식별자와 연관되어 있다.이러한 식별자는 32비트 부호화되지 않은 정수지만, 자원이나 원자의 식별자와 반드시 다른 것은 아니다.

클라이언트로부터의 접속이 받아들여지면, 서버가 송신하는 수신 패킷은 블록의 순서를 포함하는데, 각 패킷은 하나의 화면에 관한 정보를 포함하고 있다.각 화면에 대해 상대 블록은 다른 블록의 목록을 포함하며, 각 블록은 스크린에서 지원되는 특정 색 농도에 상대적이다.지원되는 각 깊이에 대해 이 목록에는 시각적 유형 목록이 포함되어 있다.결과적으로, 각 화면은 가능한 여러 깊이와 연관되며, 각 화면의 각 깊이는 가능한 많은 시각적 유형과 연관된다.주어진 시각적 유형은 더 많은 화면과 다른 깊이에 사용될 수 있다.

각 시각적 유형에 대해, 승인 패킷은 식별자와 그것이 포함하는 실제 매개변수를 모두 포함한다(시각적 클래스 등).고객은 이 정보를 저장하는데, 이는 나중에 요청할 수 없기 때문이다.더욱이 고객은 새로운 시각적 유형을 변경하거나 생성할 수 없다.새 창 작성 요청에는 이 창의 색상을 나타내는 데 사용할 시각적 유형의 깊이와 식별자가 포함된다.

Colormaps는 화면을 제어하는 하드웨어(예: 그래픽 카드)가 팔레트를 사용하는지 여부에 관계없이 사용되는데, 이는 색상을 나타내는 데도 사용되는 테이블이다.서버들은 하드웨어가 팔레트를 사용하지 않더라도 캡슐을 사용한다.하드웨어가 팔레트를 사용할 때마다 제한된 수의 대왕탑만 설치할 수 있다.특히 하드웨어가 그에 따라 색을 나타낼 때 콜로맵이 설치된다.클라이언트는 서버에 colormap 설치를 요청할 수 있다.그러나 이 경우 또 다른 콜론맵을 제거해야 할 수 있다. 즉, 제거된 콜론맵을 사용하는 창이 올바른 색상으로 표시되지 않는 효과, 즉 컬러 플래시 또는 테크니컬러라고 불리는 효과.이 문제는 픽셀 값과 색상의 연관성이 예측 가능한 대왕탑인 표준 대왕탑을 사용하여 해결할 수 있다.이 속성 덕분에, 표준 콜럼프는 다른 어플리케이션에 의해 사용될 수 있다.

콜로맵의 생성은 ICCCM 협약에 의해 규제된다.표준 콜럼프는 ICCCM과 Xlib 규격에 의해 규제된다.

X 색상 시스템의 한 부분은 X 색상 관리 시스템(xcms)이다.이 시스템은 1991년에 X11R6 릴리스 5와 함께 도입되었다.이 시스템은 Xcms* 기능 시리즈에서 찾을 수 있는 xlib의 몇 가지 추가 기능으로 구성된다.이 시스템은 장치 의존적 RGB 시스템으로 변환될 수 있는 장치 독립적인 색 구성표를 정의한다.이 시스템은 Xlib Xcms* 기능과 더불어 다양한 장치 독립적 색상 시스템을 장치 의존적 RGB 색상 시스템으로 변환하는 방법을 설명하는 XDCCC(X Device Color Personalization Convention)로 구성된다.이 시스템은 CIEXYZ, XYY, CIELUV 및 CIELAB와 Tek를 지원한다.HVC 색상 시스템.[1], [2]

원자

원자는 문자열을 나타내는 32비트 정수다.프로토콜 설계자들은 원자가 짧고 고정된 크기의 문자열을 나타내기 때문에 원자를 도입했다:[9] 문자열은 임의로 길 수도 있지만, 원자는 항상 32비트 정수다.원자단순성은 동일한 문자열로 여러 번 전송될 가능성이 높은 패킷의 종류에 사용을 의무화함으로써 이용되었다. 이것은 네트워크의 보다 효율적인 사용을 초래한다.원자의 고정 크기는 이벤트에 고정된 크기, 즉 32바이트: 고정 크기 패킷은 원자를 포함할 수 있지만 긴 문자열을 포함할 수는 없다.

정확히 말하면, 원자는 서버에 저장된 문자열의 식별자다.리소스의 식별자(Windows, Pixmaps 등)와 비슷하지만 두 가지 면에서 차이가 있다.첫째, 원자의 식별자는 클라이언트가 아닌 서버에 의해 선택된다.즉, 클라이언트가 새로운 원자의 생성을 요청할 때, 그것은 서버에게 그것의 식별자가 아닌 저장될 문자열만 보낸다. 이 식별자는 서버에 의해 선택되어 클라이언트에 대한 회신으로서 다시 전송된다.자원과 원자의 두 번째 중요한 차이점은 원자가 클라이언트와 연관되지 않는다는 것이다.일단 생성된 원자는 서버가 종료되거나 재설정될 때까지 살아남는다(이것은 자원의 기본 동작이 아니다).

원자는 식별자여서 독특하다.그러나 원자와 자원 식별자는 일치할 수 있다.원자와 관련된 끈을 원자 이름이라고 한다.원자의 이름은 생성 후 변경할 수 없으며, 두 원자가 같은 이름을 가질 수 없다.그 결과 원자의 이름은 일반적으로 원자를 다음과 같이 나타내기 위해 사용된다."원자"ABCD"는 더 정확히 말하자면, "관련된 문자열을 가진 원자"를 의미한다.ABCD" 또는 "이름을 가진 원자"ABCD" 클라이언트는 새로운 원자의 생성을 요청할 수 있으며 주어진 문자열의 원자(식별자)를 요청할 수 있다.일부 원자는 미리 정의되어 있다(서버가 지정된 식별자와 문자열로 생성).

원자는 여러 목적으로 사용되는데, 대부분 동일한 서버에 연결된 서로 다른 클라이언트 간의 통신과 관련이 있다.특히 아래와 같이 창문의 특성과 연계하여 사용한다.

서버에 있는 모든 원자의 목록은 프로그램을 사용하여 출력할 수 있다.xlsatoms. 특히 이 프로그램은 각 원자(식별자, 즉 숫자)를 그 이름(관련 문자열)과 함께 인쇄한다.

특성.

모든 창에는 미리 정의된 속성 집합과 속성 집합이 있으며, 모두 서버에 저장되고 적절한 요청을 통해 클라이언트가 액세스할 수 있다.속성은 창 크기, 위치, 배경색 등과 같은 창 관련 데이터다.속성은 창문에 부착된 임의의 데이터 조각이다.속성과는 달리 속성은 X 윈도 코어 프로토콜 수준에서는 의미가 없다.클라이언트는 임의 데이터를 창의 속성에 저장할 수 있다.

속성은 이름, 유형, 그리고 값으로 특징지어진다.속성은 클라이언트가 주어진 이름의 새로운 속성을 생성하고 그 안에 값을 입력하고 저장할 수 있다는 점에서 명령적 프로그래밍 언어의 변수와 유사하다.속성은 창과 연관된다: 동일한 이름을 가진 두 속성이 다른 두 개의 창문에 존재할 수 있지만 유형과 값은 다를 수 있다.

속성의 이름, 유형 및 값은 문자열이다. 더 정확히 말하자면, 문자열은 서버에 저장되고 식별자를 통해 클라이언트가 액세스할 수 있는 원자 문자열이다.클라이언트 애플리케이션은 속성의 이름을 포함하는 원자의 식별자를 사용하여 주어진 속성에 접근할 수 있다.

속성은 주로 클라이언트 간 통신에 사용된다.예를 들어, 이름이 지정된 속성WM_NAME(관련 문자열을 가진 원자에서 명명된 속성)"WM_NAME")는 창문의 이름을 저장하는 데 사용된다.일반적으로 창 관리자는 제목 표시줄에 창 이름을 표시하기 위해 이 속성을 읽는다.

일부 클라이언트 간 통신 유형은 루트 창의 속성을 사용한다.예를 들어 자유롭스크톱 윈도우 관리자 사양에 따라 윈도우 관리자는 현재 활성 윈도우의 식별자를 명명된 속성에 저장해야 한다.[10]_NET_ACTIVE_WINDOW루트 창의프로그램의 매개 변수를 포함하는 X 리소스도 루트 창의 속성에 저장되므로, 다른 컴퓨터에서 실행되더라도 모든 클라이언트가 액세스할 수 있다.

그xprop프로그램은 주어진 창의 속성을 인쇄한다.xprop -root루트 창의 각 속성의 이름, 유형 및 값을 인쇄하십시오.

매핑

이 키는 항상 같은 키코드를 생성하지만 기호는/,7, 그리고{세 개의 다른 키와 연관되어 있다.

X 창 시스템에서, 모든 개인, 물리적 키는 그것의 키코드라고 불리는 8-255 범위의 숫자와 연관되어 있다.키코드는 키에 인쇄될 수 있는 문자나 용어(예: "Page Up")가 아닌 키만 식별한다.이 문자나 용어의 각 문자는 키로 대신 식별된다.키코드는 누른 실제 키에만 의존하지만, 예를 들어 Shift 키나 다른 수식어가 눌렸는지에 따라 키심이 달라질 수 있다.

키를 누르거나 놓으면 서버는 유형의 이벤트를 전송한다.KeyPress또는KeyRelease적절한 고객에게.이러한 이벤트에는 다음이 포함된다.

  1. 누름 키의 키코드
  2. 수정자(Shift, Control 등) 및 마우스 버튼의 현재 상태
키코드에서 키로 변환.

따라서 서버는 특정 문자로 변환하려고 시도하지 않고 키코드 및 수정자 상태를 전송한다.이 변환을 하는 것은 고객의 책임이다.예를 들어, 클라이언트는 Shift 수식어가 중단된 동안 지정된 키를 눌렀다는 이벤트를 수신할 수 있다.이 키가 일반적으로 문자 "a"를 생성한다면, 클라이언트(서버 제외)는 이 이벤트를 문자 "A"에 연결한다.

키코드에서 키yms로의 변환은 클라이언트에 의해 수행되지만, 이 연결을 나타내는 테이블은 서버에 의해 유지된다.이 테이블을 중앙 집중식 위치에 저장하면 모든 클라이언트가 액세스할 수 있다.일반적인 클라이언트는 이 매핑만 요청하며 키 이벤트의 키 코드 및 수정자 필드를 키 밈으로 디코딩하는 데 사용한다.그러나 고객은 이 매핑도 마음대로 변경할 수 있다.

수식어는 누르면 다른 키의 해석이 바뀌는 키다.일반적인 수식어는 Shift 키로 보통 소문자 "a"를 생성하는 키를 Shift와 함께 누르면 대문자 "A"가 생성된다.다른 일반적인 수식어는 "제어", "알트", "메타"이다.

X 서버는 최대 8개의 수식어와 함께 작동한다.그러나 각 수식어는 둘 이상의 키와 연관될 수 있다.이것은 많은 키보드들이 일부 수식어를 위해 중복된 키를 가지고 있기 때문에 필요하다.예를 들어, 많은 키보드에는 두 개의 "Shift" 키(왼쪽과 오른쪽 키)가 있다.이 두 개의 키는 누를 때 서로 다른 두 개의 키코드를 생성하지만 X 서버는 두 개의 키코드를 모두 "Shift" 수식어와 연결한다.

8개의 수식어 각각에 대해 X 서버는 해당 수식어로 간주되는 키코드 목록을 유지 관리한다.예를 들어 첫 번째 수식어("Shift" 수식어)의 목록에 키코드가 포함되어 있는 경우0x37, 그리고 키코드를 생성하는 키0x37X 서버에 의해 시프트 키로 간주된다.

수정자 매핑 목록은 X 서버에 의해 유지되지만 모든 클라이언트가 변경할 수 있다.예를 들어 클라이언트는 "Shift" 수정자 목록에 "F1 키"를 추가하도록 요청할 수 있다.이때부터 이 키는 또 다른 시프트 수식어처럼 동작한다.그러나 이 키를 누를 때 F1에 해당하는 키코드는 여전히 생성된다.그 결과 F1은 이전과 같이 작동하지만(예를 들어, 도움말 창을 누를 때 열 수 있음) 시프트 키와 같이 작동한다(F1이 다운된 상태에서 텍스트 편집기에서 "a"를 누르는 것은 현재 텍스트에 "A"를 추가함).

X 서버는 마우스 버튼에 대한 수정자 매핑을 유지 관리하고 사용한다.그러나 단추는 순열만 할 수 있다.이것은 주로 왼손잡이 사용자들을 위해 가장 왼쪽과 오른쪽 버튼을 교환하는데 유용하다.

그xmodmap프로그램은 키, 수정자 및 마우스 단추 매핑을 표시하고 변경한다.

붙잡다

붙잡기는 모든 키보드 또는 마우스 이벤트가 단일 클라이언트로 전송되는 조건이다.클라이언트는 키보드, 마우스 또는 둘 다 붙잡기를 요청할 수 있다. 서버에 의해 요청이 수행된 경우 붙잡기가 해제될 때까지 모든 키보드/마우스 이벤트가 붙잡기 클라이언트로 전송된다.다른 고객들은 이러한 이벤트를 받지 못할 것이다.

붙잡기를 요청할 때 클라이언트는 붙잡기 창을 지정한다. 모든 이벤트는 붙잡기 창에 상대적인 것처럼 붙잡기 클라이언트로 전송된다.그러나 다른 클라이언트는 그랩 창에서 이벤트를 선택했더라도 이벤트를 수신하지 않는다.붙잡기는 두 종류가 있다.

  • 활성: 즉시 붙잡기
  • 수동: 이전에 지정한 키 또는 마우스 버튼을 눌렀을 때에만 붙잡기가 발생하며, 놓았을 때 붙잡기가 종료됨
포인터나 키보드가 고정되어 있으면, 그들이 생성하는 이벤트는 대기열에서 차단된다.만약 그들이 붙잡히면, 그들의 이벤트는 보통 그것들을 받는 창 대신 붙잡는 고객에게 다시 전달된다.포인터 이벤트는 이벤트 마스크에 따라 폐기될 수 있다.

클라이언트는 키보드, 포인터 또는 둘 다 잡을 수 있다.붙잡기 요청에는 키보드나 포인터를 동결하는 요청이 포함될 수 있다.움켜쥐는 것과 얼리는 것의 차이는 사건의 수신자를 붙잡는 것이 사건의 전달을 완전히 멈추게 한다는 것이다.장치가 동결되면 장치가 생성하는 이벤트는 동결 종료 시 평소처럼 전달될 대기열에 저장된다.

포인터 이벤트의 경우, 이벤트 전달에 영향을 주는 추가 매개 변수가 있는데, 이벤트 마스크는 전달할 이벤트 유형과 삭제할 이벤트 유형을 지정한다.

붙잡기 요청에는 붙잡기 클라이언트가 붙잡기를 설정하지 않았더라도 붙잡기 클라이언트에 보낼 이벤트에 대해 구체적으로 어떤 일이 발생하는지 지정하는 필드가 포함된다.특히 고객은 평소처럼 또는 붙잡기에 따라 보내달라고 요청할 수 있다.이 두 가지 조건은 나타날 수 있는 것과 같지 않다.예를 들어 일반적으로 첫 번째 창에서 키보드 이벤트를 수신하는 클라이언트는 두 번째 창에서 키보드를 잡도록 요청할 수 있다.일반적으로 첫 번째 창으로 전송되는 이벤트는 그랩 요청의 파라미터에 따라 그랩 창으로 리디렉션되거나 리디렉션되지 않을 수 있다.

클라이언트는 또한 전체 서버의 붙잡기를 요청할 수 있다.이 경우, 붙잡는 클라이언트에서 온 요청 외에는 서버에서 어떤 요청도 처리되지 않는다.

기타

핵심 프로토콜의 다른 요청과 이벤트가 존재한다.첫 번째 종류의 요청은 창 간의 부모 관계에 관련된다. 즉, 클라이언트는 창의 부모에 대한 변경을 요청할 수 있고, 창문의 부모에 대한 정보를 요청할 수 있다.그러나 다른 요청은 대부분 다른 프로토콜에 의해 지배되는 선택과 관련이 있다.다른 요청은 입력 포커스와 포인터 모양에 관한 것이다.클라이언트는 또한 자원(창, 픽스맵 등)의 소유자에게 죽임을 요청할 수 있으며, 이로 인해 서버와의 연결이 종료된다.마지막으로 클라이언트는 서버에 작업 불가 요청을 보낼 수 있다.

확장

모양 확장은 오클락이 둥근 창을 만들 수 있게 해준다.

X Window 핵심 프로토콜은 확장 가능하도록 설계되었다.코어 프로토콜은 사용 가능한 확장을 쿼리하고 확장 요청, 이벤트 및 오류 패킷이 만들어지는 방법을 쿼리하기 위한 메커니즘을 지정한다.

특히 클라이언트는 특정 확장과 관련된 데이터에 대해 사용 가능한 모든 확장자 목록을 요청할 수 있다.확장 패킷은 코어 프로토콜의 패킷과 유사하다.코어 프로토콜은 요청, 이벤트 및 오류 패킷에 그 유형을 나타내는 정수를 포함하도록 지정한다(예: 새 창 생성 요청은 1번으로 표시됨).이러한 정수들의 범위는 확장을 위해 예약되어 있다.

허가

주요 기사: X Window 인증

클라이언트가 처음에 서버와의 연결을 설정할 때, 서버는 연결을 승낙하거나 거부하거나 인증을 요청하는 방법으로 회신할 수 있다.인증 요청에는 사용할 인증 방법의 이름이 포함되어 있다.코어 프로토콜은 서버가 승인이나 거부 패킷을 보내는 것으로 끝나는 것 외에, 사용하는 인증의 종류에 따라 달라지는 인증 과정을 명시하지 않는다.

클라이언트와 서버 간의 정기적인 상호 작용 동안 인증과 관련된 유일한 요청은 호스트 기반 액세스 방법에 관한 것이다.특히 클라이언트는 이 방법을 사용하도록 요청할 수 있으며, 연결 권한이 있는 호스트(클라이언트)의 읽기 및 목록 변경을 요청할 수 있다.일반적인 애플리케이션은 이러한 요청을 사용하지 않으며, 이 요청은xhost사용자 또는 스크립트에게 호스트 액세스 목록에 대한 액세스 권한을 부여하는 프로그램.호스트 기반 액세스 방법은 안전하지 않은 것으로 간주된다.

Xlib 및 기타 클라이언트 라이브러리

주요기사: Xlib

대부분의 클라이언트 프로그램은 Xlib 클라이언트 라이브러리를 통해 서버와 통신한다.특히 대부분의 클라이언트는 Xaw, Motives, GTK+ 또는 Qt와 같은 라이브러리를 사용하며, 이 라이브러리는 Xlib를 사용하여 서버와 상호 작용한다.Xlib를 사용하면 다음과 같은 효과가 있다.

  1. Xlib는 응답 및 이벤트와 관련하여 클라이언트를 동기식으로 설정:
    1. Xlib를 사용하지 않는 X Window 클라이언트는 서버에 요청을 보낸 다음 응답을 기다리는 동안 다른 작업을 수행할 수 있지만 Xlib를 사용하는 클라이언트는 요청을 보내는 Xlib 함수를 호출하고 응답을 기다리는 Xlib 함수를 호출할 수 있다.따라서 회신을 기다리는 동안 클라이언트를 차단(클라이언트가 함수를 호출하기 전에 새 스레드를 시작하지 않는 경우)
    2. 서버가 비동기적으로 이벤트를 전송하는 동안, Xlib는 클라이언트가 수신한 이벤트를 큐에 저장한다; 클라이언트 프로그램은 X11 라이브러리의 기능을 명시적으로 호출해야만 접속할 수 있다. 즉, 클라이언트는 이벤트를 예상할 경우 강제로 차단하거나 바쁜 대기 시간을 기다린다.
  2. Xlib는 서버에 요청을 즉시 전송하지 않고 이를 출력 버퍼라고 하는 대기열에 저장하며, 출력 버퍼의 요청은 다음과 같은 경우에 실제로 전송된다.
    1. 프로그램은 다음과 같은 라이브러리 함수를 호출하여 명시적으로 요청한다.XFlush;
    2. 프로그램은 다음과 같은 서버로부터의 회신을 포함하는 것을 결과적으로 주는 기능을 호출한다.XGetWindowAttributes;
    3. 프로그램은 이벤트 대기열에서 이벤트를 요청한다(예: 전화 걸기).XNextEvent( ) 및 통화 블록(예:XNextEvent대기열이 비어 있는 경우 차단).

Xt와 같은 상위 수준의 라이브러리(Xaw와 Motivity에서 차례대로 사용됨)는 클라이언트 프로그램이 일부 이벤트와 관련된 콜백 기능을 지정할 수 있도록 허용하며, 라이브러리는 이벤트 대기열을 폴링하고 필요한 경우 적절한 기능을 호출하며, 창 다시 그리기의 필요성을 나타내는 이벤트와 같은 일부 이벤트는 상호 처리된다.nally by Xt.

XCB와 같은 하위 수준의 라이브러리는 프로토콜에 대한 비동기식 액세스를 제공하여 더 나은 지연 시간 숨기기 기능을 제공한다.

불특정 부품

X Window System 핵심 프로토콜은 클라이언트 간 통신에 대해 의무화하지 않으며 그래픽 사용자 인터페이스(버튼, 메뉴 등)에서 공통적인 시각적 요소를 형성하기 위해 윈도우를 사용하는 방법을 명시하지 않는다.그래픽 사용자 인터페이스 요소는 위젯 툴킷을 실현하는 클라이언트 라이브러리에 의해 정의된다.클라이언트 간 통신은 ICCCM 및 프리츠크톱 규격과 같은 다른 표준으로 다룬다.[10]

클라이언트 간 통신은 사용자가 창에서 다른 창으로 데이터를 전송하는 데 사용하는 방법인 선택, 절단 버퍼, 끌어서 놓기와 관련이 있다.창은 다른 프로그램에 의해 제어될 수 있기 때문에, 이 데이터를 교환하기 위한 프로토콜이 필요하다.클라이언트간 통신은 윈도우의 외관과 그래픽 사용자 인터페이스의 일반적인 외관을 제어하는 프로그램인 X 윈도우 매니저와도 관련이 있다.

세션 관리

그러나 클라이언트 간 통신이 어느 정도 관련이 있는 또 다른 문제는 세션 관리의 문제다.

사용자 세션이 어떻게 시작되는가는 핵심 프로토콜에서 다루지 않는 또 다른 문제다.보통 X 디스플레이 관리자가 자동으로 이 작업을 수행한다.그러나 사용자는 sinit 또는 startx 프로그램을 수동으로 실행하는 세션을 시작할 수도 있다.

참고 항목

참조

  1. ^ Robert W. Scheifler and James Gettys: X Window 시스템: 코어 및 확장 프로토콜, X 버전 11, 릴리스 6 및 6.1, Digital Press 1996, ISBN1-558-148-X
  2. ^ RFC 1013
  3. ^ 그랜트 에드워즈X11 사용자 인터페이스 소개
  4. ^ 짐 게티스2006년 1월 2일 웨이백 머신에 보관된 오픈 소스 데스크톱 기술 로드맵
  5. ^ "comp.fonts FAQ: X11 Info". www.faqs.org.
  6. ^ Jim Flowers; Stephen Gildea (1994). "X Logical Font Description Conventions" (PDF). Digital Equipment Corporation. X Consortium. Archived from the original (PDF) on March 28, 2005. Retrieved 2005-12-30.
  7. ^ 마티외 헤르브와 마티아스 홉프.X 창 시스템의 새로운 진화.
  8. ^ "Interface with ghostscript - GNU gv Manual". www.gnu.org.
  9. ^ 데이비드 로젠탈.클라이언트 간 통신 규약 매뉴얼.MIT X 컨소시엄 표준, 1989
  10. ^ a b "wm-spec". www.freedesktop.org.

외부 링크