1. 툴킷은 원래 X11 하위 수준 프리미티브를 사용하여 화면에 콘텐츠를 그렸습니다. 현재 글꼴 처리 및 텍스트 렌더링은 GLX(X 프로토콜을 통한 OpenGL) 및 DRI(Direct Rendering)와 같은 X 프로토콜 확장을 사용하여 클라이언트 측에서 수행됩니다.

2. X 서버는 모든 창과 그 크기 및 위치를 알고 있습니다. 창은 X11의 서버측 개체입니다. 클라이언트는 X 서버에 창 생성 요청을 보낼 수 있으며, 서버는 생성되는 창의 ID로 응답합니다. Windows는 일반적으로 사용자가 창 관리자와 상호 작용할 때 크기를 조정하며, 창 관리자는 창 크기를 조정하기 위해 X11 API 호출을 사용하여 서버에 요청을 보냅니다.

3. 창 관리자는 특별한 것이지만 일반적인 X11 클라이언트 응용 프로그램입니다. 창 관리자는 일반 X 클라이언트 응용 프로그램과 동일한 X 호출을 사용하고 그리기 기본 요소 및 포인터 이벤트와 같은 동일한 이벤트를 처리합니다. 응용 프로그램 메뉴는 창 관리자가 그리는 장식의 일부가 아니라 응용 프로그램 자체에서 처리됩니다.

4. 데스크탑 환경의 "패널"과 "창 전환기"는 특히 창 전환과 같은 작업을 수행할 때 별도의 X 클라이언트이거나 창 관리자의 일부일 수 있습니다.

Wayland 창 관리자는 가장 낮은 수준의 X11과 매우 다릅니다. 왜냐하면 Wayland 아키텍처는 X11과 매우 다르기 때문입니다. Wayland를 실행하는 경우 Wayland Window Manager/Compositor가 필요합니다. 반면 일부 Wayland 창 관리자(예: KWin)는 거의 동일한 사용자 경험을 제공한다는 목표로 원래 X11 버전을 시작점으로 사용하여 작성되었으므로 사용자 관점에서 보면 두 가지 변형(KWin/X11 호환 가능) KWin/웨이랜드).

바라보다Linux 디스플레이는 어떻게 작동합니까?

저는 Xlib를 사용하여 X11 애플리케이션(작은 게임)을 작성했습니다. 나는 창 관리자가 어떻게 작동하는지 보았지만 이에 대해 글을 쓴 적이 없습니다.

2부 및 3부 창 관리자

클라이언트가 창을 생성하면 서버는 요청을 받습니다. 클라이언트가 창을 매핑하면(서버에 창을 표시하도록 요청합니다. 매핑을 해제할 수도 있습니다: 작업 표시줄에 숨겨진 것처럼), 서버는 창 관리자에게 알립니다(클라이언트가 창 관리자로 등록해야 한다고 생각합니다). 창 관리자는 매핑을 가로채서 새 창의 창 ID를 가져온 다음 제목 표시줄, 프레임 부분(왼쪽, 오른쪽, 아래쪽) 및 중앙에 있는 큰 하위 창 덩어리가 있는 자체 창을 만듭니다. 원래 창을 중간에 있는 이 큰 비트로 재설정하도록 서버에 지시합니다. 그런 다음 이 현재 창을 매핑합니다.

X11에서는 모든 것이 창이라는 점에 유의하세요. Windows에는 다른 창이 포함되어 있습니다. 모니터에는 루트 창이라는 하나의 창이 있습니다. 다른 모든 창은 이 루트 창 내에 있습니다. 파일 시스템의 디렉터리와 같습니다. 부모 재지정은 디렉터리를 동일한 파일 시스템을 사용하는 다른 디렉터리로 이동하는 것과 같습니다.

4부 패널

이들은 단지 다른 고객일 뿐입니다. 작업 표시줄은 창 관리자와 함께 작동합니다. 창 관리자는 작업 표시줄에 창의 상태를 알려줍니다.

클라이언트 메뉴 등

이는 창 관리자와 동일한 툴킷을 사용하여 생성할 수 있습니다. 그러나 그들은 고객의 일부입니다.

흥미로운 실험.

창 관리자 없이 X11을 실행해 보세요. 나머지 데스크톱 환경 없이 창 관리자를 사용해 보세요. 창 관리자와 다른 클라이언트를 (별도로) 일시 중지(프로세스 관리자에서 중지)해 보십시오. 로그아웃하거나 다른 클라이언트를 닫지 않고 창 관리자를 전환해 보세요.

이 실습은 창 관리자의 기능을 이해하는 데 도움이 됩니다.