리눅스 그래픽 스택은 어떻게 구성됩니까?

리눅스 그래픽 스택은 어떻게 구성되어 있습니까? 나는 X / GTK / GNOME / KDE 등에 대해 항상 듣지만 실제로 그들이 실제로 무엇을하고 그들이 서로 그리고 스택의 다른 부분과 어떻게 상호 작용하는지 전혀 모른다. 유니티와 웨이 랜드는 어떻게 맞습니까?

X 윈도우 시스템은 클라이언트-서버 아키텍처를 사용합니다. X 서버는 디스플레이 (모니터 + 입력 장치)가있는 시스템에서 실행되는 반면 X 클라이언트는 다른 시스템에서 실행하고 X 프로토콜을 사용하여 X 서버에 연결할 수 있습니다 (직접적인 것이 아니라 라이브러리와 같은 라이브러리를 사용하여). Xlib 또는보다 최신의 비 차단 이벤트 중심 XCB). X 프로토콜은 확장 가능하도록 설계되었으며 많은 확장이 있습니다 (참조 xdpyinfo(1)).

X 서버는 창 생성 및 삭제, 그리기 작업 수행 (현재 대부분의 그리기는 클라이언트에서 수행되고 이미지는 서버로 전송 됨), 이벤트를 창으로 전송하는 등 낮은 수준의 작업 만 수행합니다. X 서버는 X :1 &(다른 X 서버에서 아직 사용하지 않은 숫자를 사용) 또는 Xephyr :1 &(Xephyr은 현재 X 서버에 내장 된 X 서버를 실행) 실행 한 다음 xterm -display :1 &새 X 서버 로 실행 하고 전환하여 수행합니다 (X 인증을 설정해야 할 수도 있음) 사용 xauth(1)).

보시다시피 X 서버는 거의하지 않고 제목 표시 줄을 그리거나 창 최소화 / 아이콘 화를하지 않으며 창 배치를 관리하지 않습니다 ... 물론 명령을 실행하여 창 배치를 수동으로 제어 할 수 있습니다 같은 xterm -geometry -0-0,하지만 일반적으로 위의 작업을 수행하는 특수 X 클라이언트가 있습니다. 이 클라이언트를 창 관리자 라고합니다 . 한 번에 하나의 창 관리자 만 활성화 할 수 있습니다. 여전히 이전 명령의 맨 X 서버가 열려있는 경우, 당신이 그것에 윈도우 매니저를 실행하려고 할 수 있습니다, 같은 twm, metacity, kwin, compiz, larswm, pawm, ...

우리가 말했듯이, X는 낮은 수준의 작업만을 수행하며 푸시 버튼, 메뉴, 툴바와 같은 높은 수준의 개념을 제공하지 않습니다 ... 이들은 툴킷 이라는 라이브러리에 의해 제공됩니다 . 예 : Xaw, GTK, Qt, FLTK, ...

데스크탑 환경은 통합 된 사용자 경험을 제공하도록 설계된 프로그램 모음입니다. 따라서 데스크탑 환경은 일반적으로 패널, 응용 프로그램 실행기, 시스템 트레이, 제어판, 구성 인프라 (설정을 저장할 위치)를 제공합니다. 잘 알려진 데스크탑 환경은 KDE (Qt 툴킷을 사용하여 빌드), Gnome (GTK를 사용), Enlightenment (자체 툴킷 라이브러리 사용), ...

일부 최신 데스크탑 효과는 3D 하드웨어를 사용하는 것이 가장 좋습니다. 새 구성 요소 인 composite manager 가 나타납니다 . X 확장 인 XComposite 확장은 창 내용을 복합 관리자에게 보냅니다. 컴포지트 관리자는 해당 내용을 텍스처로 변환하고 OpenGL을 통해 3D 하드웨어를 사용하여 여러 가지 방법 (알파 블렌딩, 3D 투영 등)으로 구성합니다.

얼마 전 X 서버는 하드웨어 장치와 직접 통신했습니다. 이 장치 처리의 상당 부분은 DRI (X 및 직접 렌더링 클라이언트에 의한 3d 하드웨어 액세스 허용 ), evdev (입력 장치 처리를위한 통합 인터페이스), KMS (그래픽 모드 설정을 커널로 이동)로 OS 커널로 이동했습니다. , GEM / TTM (텍스처 메모리 관리).

따라서 이제 대부분 X 외부에서 장치 처리가 복잡해지면서 단순화 된 창 시스템을 실험하기가 더 쉬워졌습니다. Wayland 는 복합 관리자 개념을 기반으로하는 창 시스템입니다. 즉, 창 시스템은 복합 관리자입니다. Wayland는 X에서 벗어난 장치 처리를 사용하고 OpenGL을 사용하여 렌더링합니다.

Unity는 넷북에 적합한 사용자 인터페이스를 갖도록 설계된 데스크탑 환경입니다.

기존 스택은 3 가지 주요 구성 요소를 기반으로합니다.

• 표시를 처리하는 X 서버
• 창을 프레임에 넣고 창을 최소화하는 등을 처리하는 창 관리자. Unix의 정책과 메커니즘의 분리
• stackexchange 웹 사이트를 표시하는 데 유용한 작업을 수행하는 클라이언트 X 프로토콜을 직접 사용하거나 (자살) xlib 또는 xcb (약간 더 쉬움)를 사용하거나 GTK + 또는 QT와 같은 툴킷을 사용할 수 있습니다.

X 아키텍처는 네트워크로 만들어 졌으므로 클라이언트는 별도의 호스트와 서버에있을 수 있습니다.

여태까지는 그런대로 잘됐다. 그러나 그것은 뒤로 돌아온 이미지였습니다. 오늘날 그래픽을 처리하는 것은 CPU가 아니라 GPU입니다. 커널을 모델에 통합하려는 시도가 많았습니다.

먼저 그래픽 카드 사용에 관한 몇 가지 가정이있었습니다. 예를 들어 화면 렌더링 만 가정했습니다. 현재 위키 백과 에서이 정보를 찾을 수는 없지만 DRI 1은 동시에 하나의 응용 프로그램 만 동시에 OpenGL을 사용한다고 가정했습니다 (바로 인용 할 수는 없지만 DRI를 기다리는 메모와 함께 WONTFIX와 가까운 곳에서 버그를 파낼 수 있습니다) 2).

간접 렌더링을 위해 몇 가지 임시 솔루션이 제안되었습니다 (복합 WM에 필요).

• XGL-카드와 직접 대화하는 응용 프로그램을 지원하는 초기 제안
• AIGLX-OpenGL 프로토콜의 네트워크 속성을 사용하는 승인 된 제안
• NVidia의 독자적인 솔루션

최신 아키텍처 (DRI 2)에 대한 작업이 시작되었습니다. 그것은 포함했다 :

• 메모리 처리를위한 커널 내부 지원 (GEM / TTM)
• 커널 모드 설정 (KMS)은 커널 내에서 해상도를 변경할 수 있으므로 X와 콘솔 간 전환시 지연을 피하고 X가 실행 중일 때도 패닉에 메시지를 표시하는 것과 같은 몇 가지 다른 기능 (IIRC가 구현 될 예정인 경우)을 피할 수 있습니다.

어떻게 든 갈륨 드라이버를 커널로 옮기는 직교가 시작되었습니다. Mesa 라이브러리는 CPU에서 OpenGL의 구현으로 시작한 다음 GPU 가속을 사용하기 시작했습니다. 항상 OpenGL로 강화되었습니다. OpenGL 3.0에서는 모델이 크게 바뀌었고 라이브러리를 다시 쓰는 것은 불가피했습니다. 그러나 코드를 공통 코드를 추출하고 여러 가지 3D API를 구현할 수있는 저수준 API를 제공하는 코드를 여러 계층으로 나눌 수있는 기회를 가지게되었습니다. 예를 들어 Wine은 DirectX가 OpenGL을 거치지 않고 Gallium과 직접 대화 할 수 있도록합니다. API 계층 (직접 1-1 호출이 없을 수 있음).

Wayland는 위의 내용을 약간 복잡하고 "역사"로 간주하는 프로젝트입니다. 1984 년의 디자인은 (높은 수정과 적용이되었지만) 21 c의 시작과 일치하지 않습니다. 지지자에 따르면.

완전한 OpenGL 지원 (일부 네트워크 지원에 중요)과 같은 일부 중요한 기능이 여전히 누락되었지만 더 큰 유연성과 성능을 제공한다고 가정합니다.

데스크탑 환경 및 창 관리자에 대해 조금 더 설명합니다. 창 관리자는 창의 작동 방식을 담당하는 응용 프로그램입니다. 예를 들어 작업 영역 관리, 제목 표시 줄 (windo 제목 및 최소화 / 최대 / 닫기 단추가있는 화면 상단의 항목) 등을 관리합니다.

처음에는 최소한의 WM 만 사용되었지만 나중에 사용자는 데스크탑 환경 (예 : 메뉴 시작, 데스크탑 배경 등을 포함한 더 많은 기능을 갖춘 버전)을 원하기 시작했습니다. 그러나 데스크탑 환경의 대부분은 종종 통합되어 있지만 창 관리자가 아닙니다.

얼마 후 OpenGL과 간접 렌더링을 사용하여 작업을 수행하는 컴포지트 WM이 도입되었습니다. 그래픽 효과뿐만 아니라 돋보기와 같은 일부 접근성 기능을보다 쉽게 ​​구현할 수 있습니다.

우선, 실제로 Linux 그래픽 스택이 없습니다. 리눅스는 그래픽 디스플레이 기능이 없습니다.

그러나 Linux 응용 프로그램은 그래픽 디스플레이를 사용할 수 있으며이를 수행하기위한 다양한 시스템이 있습니다. 가장 일반적인 것은 모두 X 윈도우 위에 구축됩니다.

X 프로토콜 스택 중간에 네트워크를 표준 ​​구성 요소로 사용할 수 있으므로 X는 네트워크 프로토콜입니다. 특정 사용 사례를 살펴 보겠습니다. 베를린의 물리학자는 스위스의 CERN에서 핵 입자 충돌기 중 하나에 대한 실험을 진행하려고합니다. 그는 원격으로 로그인하여 CERN의 슈퍼 컴퓨터 배열 중 하나에서 데이터 분석 프로그램을 실행하고 화면에 결과를 그래프로 표시합니다.

베를린에서 물리학자는 원격 애플리케이션에 그래픽 디스플레이 기능을 제공하는 일부 X 서버 소프트웨어를 실행하는 X 터미널 장치를 가지고 있습니다. X 서버 소프트웨어에는 특정 하드웨어의 특정 장치 드라이버와 통신하는 프레임 버퍼가 있습니다. 그리고 X 서버 소프트웨어는 X 프로토콜을 말합니다. 따라서 레이어는 그래픽 장치-> 장치 드라이버-> 프레임 버퍼-> X 서버-> X 프로토콜 일 수 있습니다.

그런 다음 스위스에서 응용 프로그램은 X 프로토콜을 사용하여 디스플레이에 연결하고 "사각형 그리기"또는 "알파 블렌드"와 같은 그래픽 디스플레이 명령을 보냅니다. 응용 프로그램은 아마도 높은 수준의 그래픽 라이브러리를 사용하고 그 라이브러리는 낮은 수준의 라이브러리를 기반으로 할 것입니다. 예를 들어, 응용 프로그램은 핵심 그래픽 그리기 명령에 Cairo라는 라이브러리를 사용하는 GTK 위에 빌드 된 WxWidget 툴킷을 사용하여 Python으로 작성 될 수 있습니다. 카이로 위에 OPENGL이있을 수도 있습니다. 계층은 WxWidgets-> GTK-> Cairo-> X Toolkit-> X 프로토콜과 같습니다. 분명히 중간에 프로토콜이 연결되어 있으며 Linux는 데이터를 완전히 내부적으로 전송하는 UNIX 소켓도 지원하므로 원하는 경우 두 가지 유형의 시스템을 한 시스템에서 실행할 수 있습니다.

X는 프로토콜 및 그래픽 디스플레이, 포인팅 장치 및 키보드를 실행하는 X 서버와 같은 아키텍처의 기본 요소를 나타냅니다.

GTK 및 QT는 창, 대화 상자, 버튼 등을 지원하는 두 가지 범용 GUI 라이브러리입니다.

그놈과 KDE는 그래픽 데스크탑의 창을 관리하는 두 개의 데스크탑 환경으로, 유용한 애플릿과 버튼 막대와 같은 것들을 제공합니다. 또한 앱이 다른 원격 컴퓨터에서 실행 되더라도 여러 응용 프로그램이 X 서버 (X- 터미널 장치)를 통해 통신 할 수 있습니다. 예를 들어 복사하여 붙여 넣기는 응용 프로그램 간 통신의 한 형태입니다. 그놈은 GTK 위에 구축되었습니다. KDE는 QT를 기반으로 구축되었습니다. 또한 KDE 데스크탑에서 GNOME 앱을 실행하거나 GNOME 데스크탑에서 KDE 앱을 실행할 수 있습니다. 모두 동일한 기본 X 프로토콜로 작동하기 때문입니다.

이것은 조직입니다.이 그림에서 여러 페이지의 텍스트에서 더 많은 것을 배울 수 있습니다.

데스크탑 및 일부 서버의 Linux는 여전히 모든 X 및 프레임 버퍼 그래픽입니다. X 창에서-GTK + 및 Qt가 제공되며 YES BOTH는 X 시스템을 사용하고 다시 데스크톱 환경이 많이 있습니다-그놈, KDE는 X 디스플레이 및 쉘 등을 사용합니다.

Btw, linux conf (http://blip.tv/file/4693305/)의 최근 비디오가있었습니다. Intel의 Keith Packard는 X와 GL *에 대해 이야기했습니다.