X 윈도 시스템 프로토콜 및 아키텍처

X 윈도 시스템 로고 컴퓨팅에서 X 윈도 시스템(일반적으로 X11 또는 X)은 비트맵 디스플레이를 위한 네트워크 투명 윈도 시스템이다. 이 문서는 X11의 프로토콜 및 기술 구조를 자세히 설명한다.
# 클라이언트-서버 모델 및 네트워크 투명성
이 예시에서 X 서버는 키보드와 마우스로부터 입력을 받아 화면에 표시한다. 웹 브라우저와 [[단말 에뮬레이터는 사용자 워크스테이션에서 실행되며, 단말 에뮬레이터는 원격 서버에서 실행되지만 사용자 컴퓨터의 제어를 받는다. 원격 애플리케이션이 로컬에서와 똑같이 실행된다는 점에 유의하라.]] X는 클라이언트-서버 모델을 사용한다. X 서버 프로그램은 그래픽 디스플레이가 있는 컴퓨터에서 실행되며 다양한 클라이언트 프로그램과 통신한다. X 서버는 사용자와 클라이언트 프로그램 간의 중개자 역할을 하며, 클라이언트 프로그램으로부터 그래픽 출력(창)에 대한 TCP 포트 6000과 디스플레이 번호language=English에 대한 요청을 받아 사용자에게 표시하고(디스플레이), 사용자 입력(키보드, 마우스)을 수신하여 클라이언트 프로그램에 전송한다. X에서 서버는 사용자 컴퓨터에서 실행되는 반면, 클라이언트는 원격 컴퓨터에서 실행될 수 있다. 이 용어는 클라이언트가 일반적으로 사용자 로컬 컴퓨터에서 실행되고 서버가 원격 컴퓨터에서 실행되는 클라이언트-서버 시스템의 일반적인 개념을 뒤집는다. X 윈도 용어는 X 윈도 프로그램이 모든 활동의 중심에 있다는 관점을 취한다. 즉, X 윈도 프로그램은 애플리케이션과 사용자의 마우스 및 키보드 입력으로부터 요청을 수락하고 응답한다. 따라서 (원격 컴퓨터의) 애플리케이션은 X 윈도 서버 프로그램의 클라이언트로 간주된다. 서버와 클라이언트 간의 통신 프로토콜은 네트워크 투명하게 실행된다. 클라이언트와 서버는 동일한 컴퓨터에서 실행될 수도 있고 다른 컴퓨터에서 실행될 수도 있으며, 경우에 따라 다른 컴퓨터 구조와 운영체제를 가질 수도 있다. 클라이언트와 서버는 암호화된 연결을 통해 연결을 터널링하여 인터넷을 통해 안전하게 통신할 수 있다.Client–server model * IBM 1994, pp.2-11 * Maguolo 2005 * Manrique 2001 * Stevens 1994, pp.430-433 * Quercia & O'Reilly 1993, pp.13-17
# 설계 원칙
밥 샤이플러와 짐 게티스는 X의 초기 원칙을 다음과 같이 제시했다 (Scheifler/Gettys 1996에 나열됨): * 구현자가 실제 애플리케이션을 완성할 수 없다면 새로운 기능을 추가하지 마라. * 시스템이 무엇이 아닌지를 결정하는 것이 무엇인지를 결정하는 것만큼 중요하다. 세상의 모든 요구를 충족시키려 하지 마라. 대신 시스템을 확장 가능하게 만들어 추가적인 요구를 상위 호환 방식으로 충족시킬 수 있도록 하라. * 하나의 예시로부터 일반화하는 것보다 더 나쁜 것은 예시가 전혀 없는 상태에서 일반화하는 것이다. * 문제가 완전히 이해되지 않았다면, 해결책을 전혀 제공하지 않는 것이 아마도 최선일 것이다. * 작업량의 10%로 원하는 효과의 90%를 얻을 수 있다면, 더 간단한 해결책을 사용하라. (또한 Worse is better 참조.) * 복잡성을 가능한 한 많이 격리하라. * 정책보다는 메커니즘을 제공하라. 특히 사용자 인터페이스 정책은 클라이언트의 손에 맡겨라. 첫 번째 원칙은 X11 설계 과정에서 "실제 애플리케이션에서 필요로 하는 새로운 기능이 아니면 추가하지 마라"로 수정되었다. X는 이후로 이러한 원칙을 대체로 지켜왔다. X.Org 재단은 구현의 확장 및 개선을 목표로 참조 구현을 개발하며, 1987년 원본 프로토콜과 거의 완벽하게 호환되도록 유지한다.
# 코어 프로토콜
X 윈도 시스템 코어 프로토콜 서버와 클라이언트 간의 통신은 네트워크 채널을 통해 패킷을 교환함으로써 이루어진다. 클라이언트가 연결을 설정하고 첫 번째 패킷을 보낸다. 서버는 연결 수락 또는 거부를 알리거나 추가 인증 요청을 포함한 패킷을 다시 보내 응답한다. 연결이 수락되면 수락 패킷에는 클라이언트가 서버와의 후속 상호 작용에 사용할 데이터가 포함된다. 연결이 설정된 후, 클라이언트와 서버는 채널을 통해 다음 네 가지 유형의 패킷을 교환한다: # **요청:** 클라이언트가 서버로부터 정보를 요청하거나 특정 작업을 수행하도록 요청한다. # **응답:** 서버가 요청에 응답한다. 모든 요청이 응답을 생성하는 것은 아니다. # **이벤트:** 서버가 클라이언트에게 이벤트를 보낸다. 예를 들어 키보드 또는 마우스 입력, 창 이동, 크기 조정 또는 노출 등이 있다. # **오류:** 요청이 유효하지 않으면 서버가 오류 패킷을 보낸다. 요청은 대기열에 들어가므로, 요청에 의해 생성된 오류 패킷이 즉시 전송되지 않을 수 있다. X 서버는 기본 서비스 세트를 제공한다. 클라이언트 프로그램은 서버와 상호 작용하여 더 복잡한 기능을 구현한다.
## 창
일부 창의 가능한 배치: 1은 전체 화면을 덮는 루트 창이고, 2와 3은 최상위 창이며, 4와 5는 2의 하위 창이다. 부모 창 밖에 있는 창 부분은 보이지 않는다. 다른 그래픽 사용자 인터페이스에서 일반적으로 창이라고 부르는 것은 X 윈도 시스템에서는 최상위 창이다. 창이라는 용어는 다른 창 안에 있는 창, 즉 부모 창의 하위 창에도 사용된다. 버튼, 메뉴, 아이콘 등과 같은 그래픽 요소는 모두 창을 사용하여 구현된다. 창은 부모 창의 하위 창으로만 생성될 수 있다. 이로 인해 창은 계층적으로 트리 형태로 배열된다. X 서버는 자동으로 트리의 루트인 루트 창을 생성한다. 최상위 창은 루트 창의 직접적인 하위 창이다. 시각적으로 루트 창은 화면만큼 크며, 다른 모든 창 뒤에 위치한다.
## 식별자
X 서버는 창, 글꼴 등 모든 데이터에 대한 정보를 저장한다. 클라이언트는 이러한 객체의 식별자(서버와 상호 작용할 때 객체의 이름으로 사용할 수 있는 정수)를 알고 있다. 예를 들어, 클라이언트가 창을 생성하기를 원하면 서버에 창 생성을 요청하고 (성공할 경우) 새로 생성된 창과 연결된 식별자를 반환받는다. 이 식별자는 나중에 클라이언트가 예를 들어 창에 문자열을 그리도록 요청하는 데 사용될 수 있다. 식별자는 클라이언트에 대해서뿐만 아니라 서버에 대해서도 고유하다. 예를 들어, 두 개의 다른 클라이언트가 생성했더라도 두 개의 창이 동일한 식별자를 가질 수 없다. 클라이언트는 객체를 다른 클라이언트가 생성했더라도 식별자가 주어지면 어떤 객체에도 접근할 수 있다.
## 속성 및 특성
모든 창에는 미리 정의된 속성 집합과 특성 집합이 있으며, 이들은 모두 X 서버에 저장되고 적절한 요청을 통해 클라이언트가 접근할 수 있다. 속성은 창의 크기, 위치, 배경색 등 창에 대한 데이터이다. 특성은 창에 첨부된 데이터 조각이다. 속성과 달리 특성은 X 윈도 코어 프로토콜 수준에서 의미가 없다. 클라이언트는 창의 특성에 임의의 데이터를 저장할 수 있다. 특성은 이름, 유형 및 값으로 특징지어진다. 특성은 명령형 프로그래밍 언어의 변수와 유사하며, 애플리케이션은 주어진 이름과 유형을 가진 새 특성을 생성하고 그 안에 값을 저장할 수 있다. 특성은 창과 연결된다. 동일한 이름을 가진 두 개의 특성이 두 개의 다른 창에 존재할 수 있으며, 다른 유형과 값을 가질 수 있다. 특성은 주로 클라이언트 간 통신에 사용된다. 예를 들어, `WM_NAME`이라는 특성은 창의 이름을 저장하며, 창 관리자는 일반적으로 이 특성을 읽고 창의 이름을 창 상단에 표시한다. `xprop` 프로그램은 창의 특성을 표시할 수 있다. 특히, `xprop -root`는 X 리소스(프로그램의 매개변수)를 포함한 루트 창의 특성을 보여준다.
## 이벤트
이벤트는 클라이언트에게 관심 있는 일이 발생했음을 알리기 위해 서버가 클라이언트에게 보내는 패킷이다. 클라이언트는 서버에게 다른 클라이언트에게 이벤트를 보내도록 요청할 수 있으며, 이는 클라이언트 간 통신에 사용된다. 예를 들어, 클라이언트가 현재 선택된 텍스트를 요청할 때, 선택을 처리하고 있는 창을 담당하는 클라이언트에게 이벤트가 전송된다. 창의 내용은 특정 조건(예: 창이 가려진 경우)에서 "파괴"될 수 있다. 파괴된 내용의 영역이 보이는 상태가 될 때마다 서버는 `Expose` 이벤트를 생성하여 창의 일부를 그려야 한다는 것을 클라이언트에게 알린다. 다른 이벤트는 키보드 또는 마우스 입력, 새 창 생성 등을 클라이언트에게 알리는 데 사용될 수 있다. 일부 종류의 이벤트는 항상 클라이언트에게 전송되지만, 대부분의 종류의 이벤트는 클라이언트가 이전에 관심이 있다고 명시한 경우에만 전송된다. 이는 클라이언트가 특정 종류의 이벤트에만 관심이 있을 수 있기 때문이다. 예를 들어, 클라이언트는 키보드 관련 이벤트에는 관심이 있지만 마우스 관련 이벤트에는 관심이 없을 수 있다.
## 색상 모드
X 윈도 시스템이 색상을 처리하는 방식은 때때로 사용자에게 혼란을 줄 수 있으며, 역사적으로 여러 가지 다른 모드가 지원되었다. 대부분의 최신 애플리케이션은 트루컬러 (24비트 색상, 빨강, 녹색, 파랑 각 8비트)를 사용하지만, 오래되거나 특수 애플리케이션은 다른 색상 모드를 요구할 수 있다. 많은 상업용 특수 애플리케이션은 PseudoColor를 사용한다. X11 프로토콜은 실제로 대부분의 그래픽 작업에서 단일 색상을 나타내기 위해 픽셀 값이라고 불리는 단일 32비트 부호 없는 정수를 사용한다. 원색의 강도를 전송할 때는 각 색상 구성 요소에 16비트 정수가 사용된다. 다음 색상 표현이 존재하며, 특정 장치에서 모두 지원되지 않을 수 있다. * **DirectColor:** 픽셀 값은 별도의 빨강, 녹색, 파랑 하위 필드로 분해된다. 각 하위 필드는 별도의 색상표를 인덱싱한다. 모든 색상표의 항목은 변경될 수 있다. ** **TrueColor:** DirectColor와 동일하지만, 색상표 항목이 하드웨어에 의해 미리 정의되어 변경할 수 없다. 일반적으로 빨강, 녹색, 파랑 색상표는 각각 (거의) 선형적인 강도 변화를 제공한다. * **GrayScale:** 픽셀 값은 단색 강도를 포함하는 단일 색상표를 인덱싱한다. 색상표 항목은 변경될 수 있다. ** **StaticGray:** GrayScale과 동일하지만, 색상표 항목이 하드웨어에 의해 미리 정의되어 변경할 수 없다. * **PseudoColor** (Chunky): 픽셀 값은 색상 강도를 포함하는 단일 색상표를 인덱싱한다. 색상표 항목은 변경될 수 있다. ** **StaticColor:** PseudoColor와 동일하지만, 색상표 항목이 하드웨어에 의해 미리 정의되어 변경할 수 없다.
# Xlib 및 기타 클라이언트 라이브러리
Xlib 대부분의 클라이언트 프로그램은 Xlib 클라이언트 라이브러리를 통해 서버와 통신한다. Xlib 외에 XCB 라이브러리는 X 프로토콜에 더 가깝게 작동한다. 특히, 대부분의 클라이언트는 Xaw, 모티프, GTK+ 또는 Qt와 같은 라이브러리를 사용하며, 이들은 다시 Xlib를 사용하여 서버와 상호 작용한다. Qt는 5.0 릴리스에서 Xlib에서 XCB로 전환했지만, 클라이언트 프로그램은 이 변경의 영향을 거의 받지 않았다.
# ICE 클라이언트 간 통신
X 윈도 코어 프로토콜은 클라이언트 간 통신을 위한 메커니즘을 제공한다. 특히 창 속성 및 이벤트, 그리고 클라이언트-클라이언트 메시지 이벤트가 있다. 그러나 이러한 상호 작용을 위한 프로토콜은 지정하지 않는다. 대신, 별도의 클라이언트 간 통신 규칙 세트가 이러한 프로토콜을 관장한다. Inter-Client Communication Conventions Manual은 선택을 통한 데이터 교환 및 애플리케이션과 창 관리자 간의 상호 작용을 위한 프로토콜을 지정한다. 일부 사람들은 이 사양이 어렵고 혼란스럽다고 생각했다.quote=The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance.quote=ICCCM is about as horrible as the [Unix Hater’s Handbook's] authors describe, but that’s hard to notice these days because modern toolkits and window managers do a pretty good job of hiding the ugliness from applications. 애플리케이션의 룩 앤드 필 및 통신의 일관성은 일반적으로 특정 데스크톱 환경에 프로그래밍함으로써 다루어진다. ICE(Inter-Client Exchange protocol)는 클라이언트 간 상호 작용을 위한 프로토콜 구축을 위한 프레임워크를 지정하여, 프로그래머가 그 위에 특정 프로토콜을 구축할 수 있도록 한다. 특히, XSMP(X Session Management protocol)는 ICE를 기반으로 하는 프로토콜로, 애플리케이션과 세션 관리자 간의 상호 작용을 관장한다. 세션 관리자는 대화형 세션이 끝날 때 데스크톱 상태를 저장하고 동일한 사용자로 다른 세션이 다시 시작될 때 이를 복구하는 프로그램이다. freedesktop 사양에는 새로운 규칙이 포함되어 있다. 여기에는 드래그 앤 드롭 규칙 Xdnd (데이터를 선택하고 다른 창으로 드래그하여 전송하는 데 사용됨)와 내장 애플리케이션 규칙 Xembed (애플리케이션이 다른 애플리케이션의 하위 창에서 실행되는 방식을 자세히 설명함)가 포함된다.
## 선택, 잘라내기 버퍼, 드래그 앤 드롭
X 윈도 선택 X 윈도 시스템의 선택, 잘라내기 버퍼 및 드래그 앤 드롭 메커니즘을 통해 사용자는 한 창에서 다른 창으로 데이터를 전송할 수 있다. 선택 및 잘라내기 버퍼는 (일반적으로) 사용자가 창에서 텍스트 또는 다른 데이터를 선택하고 다른 창에 붙여넣을 때 사용된다. 드래그 앤 드롭은 사용자가 창에서 무언가를 선택한 다음, 선택 항목을 클릭하고 다른 창으로 끌어다 놓을 때 사용된다. 두 개의 다른 애플리케이션이 두 창을 처리할 수 있으므로, 데이터 전송에는 동일한 X 서버에 연결된 다른 클라이언트들이 상호 작용해야 한다. X 윈도 코어 프로토콜에는 선택 교환에 특정한 일부 유형의 요청 및 이벤트가 포함되어 있지만, 전송은 주로 일반 클라이언트-클라이언트 이벤트 전송 및 창 속성을 사용하여 이루어지며, 이는 선택 전송에 특정하지 않다. 사용자는 클라이언트 간에 다양한 유형의 데이터를 전송할 수 있다. 일반적으로 텍스트이지만 픽스맵, 숫자, 객체 목록 등도 될 수 있다. 선택 및 드래그 앤 드롭은 능동적인 메커니즘이다. 사용자가 창에서 데이터를 선택하면 해당 창을 처리하는 클라이언트는 해당 데이터를 요청하는 애플리케이션으로 전송하기 위한 프로토콜을 적극적으로 지원해야 한다. 이와 대조적으로 잘라내기 버퍼는 수동적인 메커니즘을 제공한다. 사용자가 일부 텍스트를 선택하면 해당 내용이 잘라내기 버퍼로 전송되며, 창을 처리하는 애플리케이션이 종료되고 창이 파괴되더라도 그곳에 남아 있다.
## 창 관리자
X 윈도 매니저 창 관리자는 창과 그래픽 사용자 인터페이스의 다른 그래픽 요소의 일반적인 모양을 제어하는 프로그램이다. X 윈도 시스템의 다른 설치에서 모양의 차이는 주로 다른 창 관리자의 사용 또는 창 관리자의 다른 구성에서 비롯된다. 창 관리자는 창의 위치를 결정하고, 창 주위에 장식 테두리를 배치하고, 아이콘을 처리하고, 창 외부(배경)에서 마우스 클릭을 처리하고, 특정 키 스트로크를 처리하는 등의 작업을 담당한다. X 서버의 관점에서 창 관리자는 다른 클라이언트와 마찬가지로 클라이언트로 작동한다. 창의 초기 위치와 창 주위의 장식 테두리는 다음 요청을 사용하여 창 관리자가 처리한다. # 애플리케이션은 서버에 특정 창의 하위 창을 매핑(표시)하는 요청을 만족시키지 않고 대신 이벤트를 보내도록 요청할 수 있다. # 애플리케이션은 창의 부모를 변경하도록 요청할 수 있다. 창 관리자는 첫 번째 요청을 사용하여 최상위 창(루트 창의 자식)을 매핑하는 모든 요청을 가로챈다. 다른 애플리케이션이 최상위 창의 매핑을 요청할 때마다 서버는 이를 수행하지 않고 창 관리자에게 이벤트를 보낸다. 대부분의 창 관리자는 창을 재부모화한다. 즉, 더 큰 최상위 창(프레임 창이라고 함)을 만들고 원래 창을 그 하위로 재부모화한다. 그래픽적으로 이는 원래 창을 프레임 창 안에 배치하는 것에 해당한다. 원래 창이 차지하지 않는 프레임 창의 공간은 창 주위의 장식 프레임("테두리" 및 "제목 표시줄")에 사용된다. 창 관리자는 프레임 창에서 마우스 클릭을 처리한다. 이를 통해 사용자는 예를 들어 테두리나 제목 표시줄을 클릭하고 드래그하여 창을 이동하거나 크기를 조정할 수 있다. 창 관리자는 아이콘 및 그래픽 사용자 인터페이스의 관련 시각적 요소도 처리한다. 아이콘은 X 윈도 코어 프로토콜 수준에 존재하지 않는다. 이는 창 관리자에 의해 구현된다. 예를 들어, 창이 "아이콘화"되어야 할 때, FVWM 창 관리자는 창의 매핑을 해제하고 아이콘 이름을 위한 창을 만들고, 가능하면 아이콘 이미지를 위한 다른 창을 만든다. 따라서 아이콘의 의미와 처리는 전적으로 창 관리자에 의해 결정된다. wm2와 같은 일부 창 관리자는 아이콘을 전혀 구현하지 않는다.
## 세션 관리자
X 세션 관리자 대략적으로 세션의 상태는 특정 시점의 "데스크톱 상태"이다. 즉, 현재 콘텐츠가 있는 창 세트이다. 더 정확하게 말하면, 이러한 창을 관리하는 애플리케이션 세트와 이러한 애플리케이션이 필요한 경우 관리되는 창의 상태를 복원할 수 있도록 하는 정보이다. X 세션 관리자라고 알려진 프로그램이 세션의 상태를 저장하고 복원한다. 가장 두드러진 점은 세션 관리자를 사용하면 사용자가 대화형 세션에서 로그아웃한 후에도 다시 로그인할 때 정확히 동일한 창을 동일한 상태로 찾을 수 있다는 것이다. 이를 위해 세션 관리자 프로그램은 로그아웃 시 실행 중인 애플리케이션의 이름을 저장하고 로그인 시 다시 시작한다. 애플리케이션의 상태도 복원되려면 (창의 콘텐츠를 복원하는 데 필요하다) 애플리케이션은 세션 관리자의 요청에 따라 실행 상태를 저장하고 다시 시작할 때 다시 로드할 수 있어야 한다. X 윈도 시스템에는 `xsm`이라는 기본 세션 관리자가 포함되어 있다. 개발자들은 특정 데스크톱 시스템을 위해 다른 세션 관리자를 작성했다. 주요 예시로는 KDE의 ksmserver, Xfce의 xfce4-session, GNOME의 gnome-session이 있다.
# X 디스플레이 관리자
X 디스플레이 관리자 X 디스플레이 관리자라고 알려진 프로그램은 X 윈도 시스템에서 그래픽 로그인 프롬프트를 표시한다. 더 일반적으로, 디스플레이 관리자는 로컬 컴퓨터에서 하나 이상의 X 서버를 실행하거나 원격 컴퓨터에서 실행 중인 X 서버로부터 들어오는 연결을 수락한다. 로컬 서버는 디스플레이 관리자에 의해 시작되며, 디스플레이 관리자는 이 서버에 연결하여 사용자에게 로그인 화면을 제시한다. 원격 서버는 디스플레이 관리자와 독립적으로 시작되어 디스플레이 관리자에 연결한다. 이 상황에서 디스플레이 관리자는 그래픽 텔넷 서버처럼 작동한다. X 서버는 디스플레이 관리자에 연결하여 세션을 시작할 수 있으며, 이 세션을 사용하는 애플리케이션은 디스플레이 관리자와 동일한 컴퓨터에서 실행되지만 (사용자 앞의 컴퓨터 또는 원격 컴퓨터일 수 있는) X 서버가 실행되는 컴퓨터에서 입출력을 한다. X 윈도 시스템은 기본 제공되는 디스플레이 관리자로 XDM을 포함한다. 다른 디스플레이 관리자로는 GDM (그놈), KDM/SDDM (KDE), WDM (윈도 메이커에서 사용되는 WINGs 위젯 세트 사용) 및 entrance (Enlightenment v.17에서 사용되는 아키텍처 사용)가 있다.
# 사용자 인터페이스 요소
초기 X용 위젯 툴킷에는 Xaw (아테나 위젯 세트, 1983), OLIT (OPEN LOOK 인트린식스 툴킷, 1988), XView (1988), 모티프 (1980년대) 및 Tk가 포함되었다. OLIT과 XView는 썬의 레거시 OpenWindows 데스크톱 환경의 기본 툴킷으로 기능한다. 모티프는 공통 데스크톱 환경(CDE)을 위한 기본 툴킷을 제공한다. CDE는 솔라리스, AIX 및 HP-UX와 같은 상업용 유닉스 시스템에서 사용되는 데스크톱 환경이다. (솔라리스 10에는 CDE와 그놈이 모두 포함되어 있으며, 후자가 lc = 선호되는 데스크톱 환경이다.) 최근에 개발된 툴킷에는 Qt (1991-, KDE에서 사용), GTK+ (1997-, 그놈에서 사용), WxWidgets (1992-), FLTK (1998-), FOX (1997-) 및 fpGUI (2005-현재)가 포함된다.
# 확장
샤이플러와 게티스는 X 서버를 간단하지만 확장 가능하게 설계했다. 따라서 현재 많은 기능이 프로토콜 확장 내에 존재한다. 프로토콜 수준에서 각 확장에는 새로운 요청/이벤트/오류 패킷 유형이 할당될 수 있다. 확장 기능은 클라이언트 애플리케이션이 확장 라이브러리를 통해 접근한다. 현재 X 서버 구현에 확장을 추가하는 것은 서버 설계의 모듈성 부족으로 인해 어려운 것으로 알려져 있다.url-status=dead XCB 프로젝트의 장기 목표는 XML 프로토콜 설명에서 확장의 클라이언트 및 서버 측을 모두 자동 생성하는 것이다. 다음 표는 개발된 확장 중 일부를 도입 시기에 따라 대략적으로 정렬한 것이다. {| class="wikitable" |- ! 확장 || 설명 및 참고 사항 |- | Composite || 전체 창 계층의 오프스크린 렌더링으로, 애플리케이션 및 합성 관리자가 어느 지점에서든 효과를 적용할 수 있도록 한다. 창의 알파 투명도 및 그림자 효과와 같은 기능에 필요하다. |- | Damage || 창의 수정된 영역을 추적하고, 디스플레이를 최신 상태로 유지하는 데 필요한 대역폭 사용을 최소화한다. |- | XFixes || 여러 프로토콜 변경 사항. |- | Extended-Visual-Information (EVIE) || 클라이언트가 핵심 프로토콜이 제공하는 것 이상의 핵심 X 시각 정보에 대한 정보를 결정할 수 있도록 한다. |- | Distributed Multihead (DMX) || DMX X 서버와 통신한다. |- | X-Video Motion Compensation (XvMC) || 비디오 모션 보상을 지원하는 GPU로 오프로드한다. |- | GLX || 창 내에서 OpenGL 렌더링 지원. |- | XRender || 알파 블렌딩을 사용한 하드웨어 가속 이미지 합성. |- | 크기 조정 및 회전 (RANDR) || X 화면의 크기, 반사, 회전 및 새로 고침 빈도를 동적으로 변경한다. |- | Xinerama || 여러 모니터에 데스크톱 분할. |- | Display Power Management Signaling (DPMS) || 모니터 절전 모드 제어를 허용한다. |- | X 키보드 확장 || 향상된 키보드 레이아웃 처리. |- | DOUBLE-BUFFER || 깜박임 없는 애니메이션을 제공한다. |- | RECORD || 서버 테스트에 사용된다. |- | MIT-SHM || 성능 향상을 위해 공유 메모리를 사용한다. |- | SYNC || X 서버 내에서 타이머를 제공하고 클라이언트(예: 다른 호스트 및 운영 체제에서 실행 중)를 동기화한다. 네트워크로 인해 발생하는 오류 때문에 생성되었다. |- | XTEST || 가짜 입력을 생성하기 위해. XAutomation 패키지의 `xte` 애플리케이션을 사용한다. |- | XInputExtension || 그래픽 태블릿과 같은 입력 장치 지원; libXi quote = libXi - library for the X Input Extension 로 구현 가능 |- | BIG-REQUESTS || 길이가 262,140바이트를 초과하는 요청을 활성화한다. |- | XC-MISC || 리소스 ID 범위 오버런 수정 archive-date=September 27, 2011 |- | X 비디오 확장 || 하드웨어 비디오 오버레이 및 재생 시 하드웨어 기반 비디오 스케일링 지원. Xv라고도 불린다. (xv 프로그램과 혼동하지 마시오.) |- | Shape || 비직사각형 및 부분 투명(이진, 알파 불투명도 없음) 창 지원. |- | MIT-SCREEN-SAVER || X 서버가 내장 화면 보호기를 켤 때 프로그램을 시작한다. |- | SECURITY || 향상된 서버 보안 제공 archive-date=September 27, 2011 |- | X-Resource || X 서버의 리소스 사용량에 대해 질의할 수 있도록 한다. |- | XFree86-Bigfont || |- | XFree86-DGA || 직접 선형 프레임버퍼 접근(직접 그래픽 접근)을 제공한다. X.Org 7.6에서 대부분 제거될 예정Disable XFree86-DGA requests except relative mouse motion, until Xinput 2 allows killing it all. X.Org Wiki - Releases/7.6 |- | XFree86-VidModeExtension || 모델라인과 감마를 동적으로 구성한다. |}
## 더 이상 사용되지 않는 확장
{| class="wikitable" |- ! 확장 || 설명 및 참고 사항 |- | Low Bandwidth X (LBX) || 안전한 셸 연결을 통해 VNC 터널링으로 대체되었으며, LBX보다 더 빠르다는 것이 입증되었다. |- | PEX || "PHIGS Extension to X"; PHIGS 3D 장면 그래프 API 지원. OpenGL을 사용한 GLX가 대신 자주 사용된다. |- | XImage Extension || MIT-SHM이 대신 사용된다. |- | XEvIE || X 이벤트 가로채기 확장. 모든 키보드 및 마우스 이벤트를 가로채야 하는 사용자를 위해 설계되었다. X.Org 7.5에서 제거되었다.7.5 release announcement |- | XFree86-Misc || 입력 속성으로 대체되었다. X.Org 7.5에서 제거되었다. |- | DEC-XTRAP || XTrap은 제어하는 X 클라이언트가 X 워크스테이션과의 실제 사용자 상호 작용을 에뮬레이트할 수 있도록 한다. 시각적 출력, 실제 키보드 및 마우스 입력을 모니터링하고 장치 입력을 시뮬레이션하도록 자신을 등록한다. 일반적인 사용 사례는 밀리초 단위로 사용자가 인식하는 대화형 응답 시간의 정확한 성능 측정일 것이다. 사용자 에뮬레이션 스크립트를 기록한 다음 반복적으로 재생할 수 있다. XTrap은 1988년경 디지털 이큅먼트 코퍼레이션 엔지니어들에 의해 오픈 소스로 출시되었다. X.Org 7.5에서 제거되었다. |- | TOG-CUP || 색상표 활용 정책을 제공한다. X.Org 7.5에서 제거되었다. |- | MIT-SUNDRY-NONSTANDARD || 초기 X11 구현을 사용했던 클라이언트를 위한 다양한 하위 호환성 기능 지원. Pre-X11R4 클라이언트와의 호환성을 위함. 2006년부터 비활성화됨. X.Org 7.5에서 제거되었다. |- | XC-APPGROUP || X.Org 7.5에서 제거되었다. |- | XPRINT || 더 이상 사용되지 않는다. 애플리케이션이 다른 디스플레이 장치와 마찬가지로 프린터로 출력을 렌더링할 수 있도록 한다. 2008년 5월에 제거되었다.Commit removing XPrint |}
# 참고 자료
# ref=Manrique2001 # ref=Maguolo2005 # url-access=registration # ref=IBM1994 # ref=Quercia1993 archive.org has the 1990 edition.
# 추가 자료
* Robert W. Scheifler and James Gettys: X Window System: Core and extension protocols, X version 11, releases 6 and 6.1, Digital Press 1996, * archive-date=3 January 2007 * Introduction to X Windows[sic] * archive-date=2 January 2006