| 운영 체제 | ||||||
| {{{#!wiki style="word-break: keep-all; margin: -16px -11px" | UNIX | | | |||
| DOS | ||||||
| 기타 | RTOS · | }}} | ||||
| 취소선 처리된 배포판은 개발 중단된 배포판. | ||||||
| Linux / UNIX GUI 환경 | |||
| {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="border: 0px solid; margin: -11px; margin-top: -8px; margin-bottom: -6px;" | 윈도우 시스템 | X11 · Wayland · Mir · SurfaceFlinger · Quartz | |
| 윈도우 매니저 | Compositing, Stacking | Mutter · MATE/Marco · Muffin · KWin · Openbox · xfwm · twm | |
| Tiling | xmonad · Bspwm · i3 | ||
| Dynamic | Awesome · dwm | ||
| 디스플레이 매니저 | GDM · SDDM(KDM) · LightDM · LXDM | ||
| 데스크톱 환경 | GTK | GNOME · MATE · Cinnamon · Budgie · Unity · Xfce · LXDE · Pantheon · Phosh | |
| Qt | KDE(Plasma Mobile) · LXQt · Deepin · JDE · UKUI | ||
[clearfix]
1. 개요
X11, X Window System, Xorg, 혹은 그냥 X으로 불린다.1984년에 MIT에서 처음 개발되었으며 MIT 허가서로 배포된다. 현재는 X.org 재단에서 개발
리눅스(+유닉스)의 GUI는 대개 X 윈도우 위에서 동작한다.
그래픽 출력을 위해 클라이언트 서버 모델을 사용하며, TCP/IP 네트워크 기반의 X 프로토콜로 통신을 한다. 간단하게, 클라이언트가 무언가 그래픽적인 요구를 X 서버로 전달하면, X 서버가 요청을 처리하여 클라이언트로 반환해 준다. 이러한 구조를 가지게된 이유는 한 컴퓨터에 모니터, 키보드를 여럿 붙이고 동시에 이용하던 시절에 작성된 프로그램이기 때문이다. 이 구조 덕에 다른 시스템에 설치되어 있는 프로그램을 내 시스템에 X 윈도우를 통해 원격으로 출력할 수 있다.
1.1. 서버-클라이언트 구조의 이해
X 서버와 X 클라이언트를 이해하기 위해, 메모장을 예로 들어보자. 메모장은 X 클라이언트가 된다. 웹브라우저, 동영상 재생기, 게임 같은 모든 GUI 프로그램을 X 클라이언트라고 생각해도 무리는 없다. 메모장을 실행하면
- X 클라이언트 메모장에 실행 명령이 전달되고
- 호출을 받은 메모장은 X 서버에 "가로세로 크기는 이만큼, 배경색과 글자색은 이렇게, 커서는 깜빡일 것." 하고 X 서버로 X 프로토콜을 날린다.
- 이제 X 서버는 그래픽 카드와 모니터로 하여금 메모장이 표시되게 명령을 내리고
- 사용자가 키를 두들기면 같은 식으로 해당 글자들도 화면에 나타나게 된다.
정리를 하면 X 서버는 X 클라이언트의 요청에 대한 결과를 디스플레이 장치에 출력하거나 키보드, 마우스, 터치 스크린과 같은 사용자 입력을 X 클라이언트에 전달하는 역할을 한다. 원격 시스템의 X 클라이언트도 로컬 시스템의 X 서버에서 담당할 수 있는데 X 윈도가 네트워크 기반의 서버/클라이언트 방식이기에 가능한 것이다.
다만 오늘날 데스크톱 리눅스에서는 위와 같은 방식을 쓰지 않고 그래픽 하드웨어를 통해 바로 그린다. 이를 DRI라고 한다. 원격 서버에 접속해서 작업하는 경우에나 위와 같은 방식을 사용한다.
2. 문제점
- 프로그램이 크다. X11은 XFree86[1]의 라이센스 문제를 해결하기 위해 XFree86의 구버전을 토대로 개발한 프로그램이다. 그런데 하도 오래 쓰다보니 코드 최적화가 이루어질래야 이루어질 수가 없고, 여러 편의사항을 추가하다 보니 덩치가 많이 커졌다.
- 보안 이슈. 현재 실행 중인 프로그램이 백그라운드에서 키보드 입력을 읽어들일 수 있다. 또한 타 윈도우의 화면을 읽는 등의 행위도 가능하다.
- HiDPI 지원 문제
- HDR 메타데이터 문제
X11은 1984년에 처음 릴리즈되었는데 그동안 컴퓨터 환경은 많은 변화가 있었다. X11은 당시 환경에 맞게 하나의 서버에 다수의 터미널 기기가 접속하여 GUI를 쓰도록 설계되었다. 하지만 오늘날 개인용 컴퓨터에서 이러한 방식은 대부분의 상황에서 오버헤드만 증가시킬 뿐이다. 그래서 해결하기 위해 X11에 DRI 확장이 추가되었고 리눅스는 이를 사용하여 그래픽 하드웨어를 통해 바로 렌더링을 수행한다.
사실 X11은 아래의 Wayland와 성능 차이는 크지 않다.[2] 그럼에도 X11을 대체하기 위해 Wayland를 개발하는 이유는 X11이 컴퓨터 환경의 변화에 따라 여러 확장 기능들이 추가되었고 그에 따라 프로그램 덩치가 커지고 코드가 복잡해졌기 때문이다. 코드가 방대하고 복잡하고 이해하기 어려우니 기능을 추가하거나 수정하기 어렵고 무엇보다 이를 나서서 하려는 코드 기여자가 없다. 즉 개발이 정체되어 버렸다.
게다가 HiDPI 지원 문제도 있다. 이는 현재 X11 구조에서는 꼼수로만 쓸 수 있을 뿐, 대대적인 개편 없이는 근본적인 해결이 불가능하다. 그런데 앞서 말했듯 그런 일을 할 개발자가 없다.
그래서 X11을 대대적으로 뜯어고치느니 차라리 이 기회에 잘 설계된 새로운 프로토콜을 만들자고 해서 나온 게 Wayland이다.
이런 움직임 때문에 2023년경 부터 X11을 지원하지 않고 Wayland만을 지원하는 상용 프로젝트부터 (Studio One)시작해 메이저 DE인 GNOME 또한 X11 지원을 중단 예정이며 KDE또한 X11 지원을 삭제할 예정이고 Firefox또한 Wayland만을 지원하는 빌드가 예정되어 있다.
3. Wayland
위 문제점을 해결하기 위해 리눅스 커널 바로 위에서 동작하는 Wayland가 개발되었다.리눅스 커널에서 최신 그래픽스 칩셋을 지원하는 기술들이 필요하여 X11과 중복되는 부분이 많아졌기에 이 부분을 모던화 하기 위해 시작했다. 2008년부터 시작되었으며, 2012년에 버전 1.0이 나왔다. 초기에는 하드웨어 호환성과 안정화 문제도 있어 사용이 많지 않았으나, GNOME의 디폴트가 Wayland가 되면서 GNOME을 채택하고 있는 페도라, 데비안 등 배포판이 사용하고 있다.
단점으로는 VNC 같은 원격 접속은 Wayland가 부족한 점이 있는데, X11은 TigerVNC, X11vnc, X2go 등 여러 가지 프로그램을 통해 지원하나 Wayland는 ogon, gnome-remote-desktop, krfb, waypipe 등 다양한 프로그램이 있지만 특정 데스크톱 환경에 종속되어 있거나 X11 세션에만 접속할 수 있는 제한이 있다.
메이저 배포판인 우분투가 Mir를 만들어 경쟁을 하기도 했으나 프로젝트가 좌초하고, 우분투 17.10에 Wayland가 정식 채택되었다. 하지만 그 다음 LTS 버전인 18.04에서는 X11로 복귀 했으며, 결국 20.04에서는 Wayland로 바뀌었으나 X11도 선택가능하다.
이미 x11을 사용하는 프로그램이 많으므로, Wayland 호환이 안되는 프로그램을 위해 Wayland를 이용해 X11 호환을 제공하는 xwayland도 존재한다.
NVIDIA 그래픽 카드와 궁합이 나쁜 편이다. NVIDIA는 AMD나 인텔과는 달리 Wayland가 사용하는 GBM을 거부하고 독자 기술인 EGLStream을 통해 Wayland API를 제공한다. 495 버전 부터는 Nvidia도 GBM을 지원한다. 다만 Nvidia의 GBM 지원에 버그가 있어서 불안정한 부분이 있다. 510 버전에 고쳐질 것이라고 한다. #
X11에 비해 단점만 있는 것은 아니다. 엔비디아와 Xorg간의 드라이버 호환성으로 인해 커널과 모니터 화면이 멈춰버리는 문제가 발생한다. DRM(Direct Rendering Manager)을 설정하고 나면 커널은 살아있지만 유저 세션이 손상되어 얼마 버티지 못한다. 하지만 Wayland 시스템은 이런 문제가 전혀 일어나지 않고 혹시라도 하드웨어 이상으로 그래픽카드가 순간적으로 인식 불량이 발생해도 신호가 끊겨 검은 화면만 나타나고 세션에서 작동중인 프로세스는 영향이 없다.
2023년 현재에는 Fedora, Ubuntu등의 배포판이 Wayland를 아예 기본값으로 설정해놓을 정도로 꽤나 안정화되었기 때문에 X11과 비교해도 사용상에 큰 문제는 없다. 특히 Waydroid등 Wayland만 지원하는 프로그램도 있기 때문에 사용자는 더 많아질 것이다.
2024년 현재는 Wayland 사용 환경이 안정화되면서 GNOME, KDE Plasma, MATE, LXQt, Sway등이 Wayland를 지원하거나 아예 기본적으로 Wayland를 사용하기 시작했으며, X11만 지원했던 Xfce, Cinnamon도 드디어 실험적인 기능으로 Wayland를 정식 도입하는 등 초창기에 비해 상황이 나아지기 시작했다.
크롬북의 ChromeOS도 자체 데스크톱 환경에 Wayland를 사용한다.
3.1. Compositor
Wayland는 어디까지나 디스플레이 서버 프로토콜(규약)이다. 즉 응용 프로그램의 통신을 받아 화면을 그려주는 디스플레이 서버 프로그램이 별도로 존재하며, Wayland는 이 디스플레이 서버와 응용 프로그램 간에서 통신하는 방법에 대한 표준을 정의한 것이라고 생각하면 된다.여기서 디스플레이 서버 역할을 하는 프로그램을 Wayland Compositor라고 부르며, 여러 종류가 존재한다.
- Weston - Wayland 프로젝트에서 자체 개발하고 있는 Wayland Compositor의 참조 구현이다.
- KWin - KDE에서 사용하는 X11 윈도우 매니저. Wayland도 지원한다.
- Mutter - GNOME에서 사용한다.
[1] X11이 만들어지기 전에 있던 X 윈도우 시스템이다.[2] 상술했듯 X11도 DRI 덕분에 GPU에 직접 접근하기 때문에 렌더링 성능은 큰 차이가 없다. 그러나 렌더링 이외의 부분들 (입력, 윈도 이벤트 핸들링 등)은 레거시 X 클라이언트 서버 모델을 그대로 사용하기 때문에 이 부분에서 X11 쪽에서 레이턴시가 더 발생한다.