저는 Linux 시스템의 다양한 구성 요소가 디스플레이 서버에서 제공하는 서비스와 어떻게 상호 작용하는지 이해하려고 합니다. Wayland 기반 디스플레이 서버로 문제를 복잡하게 만들기 전에 먼저 X11에 집중하겠습니다.
- X11 기반 시스템에 매우 기본적인 GUI 응용 프로그램을 구현하려면 이론적으로 다음을 목표로 삼을 수 있다는 것을 알고 있습니다.X11용 C 라이브러리 바인딩특정 X 클라이언트를 생성하거나 생성하는 것과
XMapWindow같은 낮은 수준의 기본 요소를 활용합니다 .XDrawString이것은 Linux 구현의 가장 낮은 수준에서 GTK 또는 Qt와 같은 일반적인 GUI 툴킷에서 사용되는 API이기도 합니까? 아니면 버튼과 텍스트 필드를 다르게 그리는 걸까요? - ~에 따르면이 게시물, 창 관리자의 작업 중 하나는 창의 위치를 제어하는 것입니다. 어떻게 이런일이 일어 났습니까? 디스플레이 서버는 창 관리자가 표시하려는 각 창에 대해 알고 있으며 각 창에 대해 창 관리자가 위치와 필요한 크기를 제공할 것으로 기대합니까? 예를 들어, 창 크기가 조정될 때 이러한 크기를 업데이트하는 것은 창 관리자의 책임입니까?
- 위의 게시물을 다시 생각해보면, 창 관리자의 또 다른 임무는 창을 장식하는 것, 즉 응용 프로그램의 테두리와 컨트롤을 그리는 것입니다. 창 관리자는 이 작업을 어떻게 수행합니까? 위의 X11 기본 요소를 다시 사용하여 실제 X 클라이언트 주위에 개체를 그립니까? 그렇다면 X 클라이언트 개발자가 GUI에 프로그래밍한 메뉴가 무엇인지 어떻게 알 수 있습니까?
- 창 관리자뿐만 아니라 전체 데스크톱 환경(예: GNOME)을 실행하는 경우 환경별 구성 요소(예: 패널 및 창 전환기)를 그리는 방법은 무엇입니까? 별도의 X 클라이언트로 실행됩니까?
마지막으로 X11 대신 Wayland를 고려해보세요. 내가 이해한다면이 기사적절하게 말하면 Wayland 기반 디스플레이 서버는 "Wayland 컴포지터"라고 하며 합성 창 관리자의 기능을 통합합니다. 이는 Mutter와 같은 Wayland 컴포지터가 Compiz와 같은 기존 창 관리자와 완전히 호환되지 않는다는 것을 의미합니까?
답변1
툴킷은 원래 X11 하위 수준 프리미티브를 사용하여 화면에 콘텐츠를 그렸습니다. 현재 글꼴 처리 및 텍스트 렌더링은 GLX(X 프로토콜을 통한 OpenGL) 및 DRI(Direct Rendering)와 같은 X 프로토콜 확장을 사용하여 클라이언트 측에서 수행됩니다.
X 서버는 모든 창과 그 크기 및 위치를 알고 있습니다. 창은 X11의 서버측 개체입니다. 클라이언트는 X 서버에 창 생성 요청을 보낼 수 있으며, 서버는 생성되는 창의 ID로 응답합니다. Windows는 일반적으로 사용자가 창 관리자와 상호 작용할 때 크기를 조정하며, 창 관리자는 창 크기를 조정하기 위해 X11 API 호출을 사용하여 서버에 요청을 보냅니다.
창 관리자는 특별한 것이지만 일반적인 X11 클라이언트 응용 프로그램입니다. 창 관리자는 일반 X 클라이언트 응용 프로그램과 동일한 X 호출을 사용하고 그리기 기본 요소 및 포인터 이벤트와 같은 동일한 이벤트를 처리합니다. 응용 프로그램 메뉴는 창 관리자가 그리는 장식의 일부가 아니라 응용 프로그램 자체에서 처리됩니다.
데스크탑 환경의 "패널"과 "창 전환기"는 특히 창 전환과 같은 작업을 수행할 때 별도의 X 클라이언트이거나 창 관리자의 일부일 수 있습니다.
Wayland 창 관리자는 가장 낮은 수준의 X11과 매우 다릅니다. 왜냐하면 Wayland 아키텍처는 X11과 매우 다르기 때문입니다. Wayland를 실행하는 경우 Wayland Window Manager/Compositor가 필요합니다. 반면 일부 Wayland 창 관리자(예: KWin)는 거의 동일한 사용자 경험을 제공한다는 목표로 원래 X11 버전을 시작점으로 사용하여 작성되었으므로 사용자 관점에서 보면 두 가지 변형(KWin/X11 호환 가능) KWin/웨이랜드).
답변2
저는 Xlib를 사용하여 X11 애플리케이션(작은 게임)을 작성했습니다. 나는 창 관리자가 어떻게 작동하는지 보았지만 이에 대해 글을 쓴 적이 없습니다.
2부 및 3부 창 관리자
클라이언트가 창을 생성하면 서버는 요청을 받습니다. 클라이언트가 창을 매핑하면(서버에 창을 표시하도록 요청합니다. 매핑을 해제할 수도 있습니다: 작업 표시줄에 숨겨진 것처럼), 서버는 창 관리자에게 알립니다(클라이언트가 창 관리자로 등록해야 한다고 생각합니다). 창 관리자는 매핑을 가로채서 새 창의 창 ID를 가져온 다음 제목 표시줄, 프레임 부분(왼쪽, 오른쪽, 아래쪽) 및 중앙에 있는 큰 하위 창 덩어리가 있는 자체 창을 만듭니다. 원래 창을 중간에 있는 이 큰 비트로 재설정하도록 서버에 지시합니다. 그런 다음 이 현재 창을 매핑합니다.
X11에서는 모든 것이 창이라는 점에 유의하세요. Windows에는 다른 창이 포함되어 있습니다. 모니터에는 루트 창이라는 하나의 창이 있습니다. 다른 모든 창은 이 루트 창 내에 있습니다. 파일 시스템의 디렉터리와 같습니다. 부모 재지정은 디렉터리를 동일한 파일 시스템을 사용하는 다른 디렉터리로 이동하는 것과 같습니다.
4부 패널
이들은 단지 다른 고객일 뿐입니다. 작업 표시줄은 창 관리자와 함께 작동합니다. 창 관리자는 작업 표시줄에 창의 상태를 알려줍니다.
클라이언트 메뉴 등
이는 창 관리자와 동일한 툴킷을 사용하여 생성할 수 있습니다. 그러나 그들은 고객의 일부입니다.
흥미로운 실험.
창 관리자 없이 X11을 실행해 보세요. 나머지 데스크톱 환경 없이 창 관리자를 사용해 보세요. 창 관리자와 다른 클라이언트를 (별도로) 일시 중지(프로세스 관리자에서 중지)해 보십시오. 로그아웃하거나 다른 클라이언트를 닫지 않고 창 관리자를 전환해 보세요.
이 실습은 창 관리자의 기능을 이해하는 데 도움이 됩니다.