웨이랜드와 Qt

Wayland는 Linux에서 X11의 대안으로 개발되었습니다. 주요 목적은 애플리케이션의 콘텐츠가 공유 화면에 함께 표시되는 방식과 사용자가 동일한 입력 장치를 공유하는 여러 애플리케이션과 상호 작용할 수 있는 방법을 관리하는 것입니다.

운영 체제에서 이 역할을 디스플레이 서버라고도 합니다. 웨이랜드 디스플레이 서버는 컴포지터 및 창 관리자라고도 불리며, 이 서버가 수행하는 특정 작업을 가리키기도 합니다.

여기서는 웨이랜드와 Qt에서의 역할에 대해 간략하게 소개하겠습니다. Wayland 자체에 대한 자세한 내용과 배경은 공식 문서를 참조하세요.

디스플레이 서버란?

디스플레이 서버는 화면 공간과 기타 공유 리소스를 관리하는 운영 체제의 일부입니다. 일반적인 데스크톱 시스템에서는 화면에 그래픽을 렌더링하고 입력을 수신할 수 있기를 기대하는 여러 독립 애플리케이션이 동시에 실행될 수 있습니다.

디스플레이 서버는 애플리케이션과 화면 및 입력 장치와 같은 공유 리소스 사이의 링크입니다. 데스크톱 시스템의 일반적인 디스플레이 서버는 애플리케이션 콘텐츠를 사용자가 이동하고 크기를 조정할 수 있는 별도의 직사각형 '창'에 배치합니다. 디스플레이 서버는 애플리케이션 콘텐츠가 화면의 올바른 위치에 표시되는지, 활성 창이 키보드의 입력을 받는지, 겹치는 창이 올바른 순서로 그려지는지 등을 확인합니다.

다른 유형의 시스템에서는 디스플레이 서버가 더 제한적일 수 있습니다. 예를 들어 화면이 자동차의 계기판이나 지게차의 제어판인 경우 창을 이동하고 크기를 조정하는 것이 바람직하지 않을 수 있습니다. 대신 각 애플리케이션을 화면의 미리 정의된 영역에 고정하고 미리 할당된 디바이스로부터 입력을 받을 수 있습니다.

어느 쪽이든 동일한 리소스를 놓고 경쟁하는 여러 개의 격리된 프로세스가 있는 한 디스플레이 서버는 유용합니다.

웨이랜드의 역할

Wayland라는 이름은 여러 가지 관련 항목을 지칭할 수 있습니다:

• 디스플레이 서버와 클라이언트 간의 통신을 위한 프로토콜 세트.
• 프로세스 간 통신을 위한 함수가 포함된 C로 작성된 라이브러리로, 해당 프로토콜을 구현하기 위한 기반 역할을 합니다.
• 프로토콜 확장을 위한 XML 기반 언어 및 이러한 확장으로부터 바인딩 코드를 C로 생성하기 위한 도구.

Qt는 프로토콜의 클라이언트 측과 서버 측 모두에 대한 구현을 제공합니다.

일반 Qt 애플리케이션은 "wayland" QPA 플러그인(특정 시스템에서는 기본값)을 선택하여 Wayland 디스플레이 서버에서 클라이언트로 실행할 수 있습니다. 또한 Qt Wayland Compositor 모듈을 사용하여 디스플레이 서버 자체를 개발할 수도 있습니다.

또한 Qt에는 새로운 인터페이스로 Wayland 프로토콜을 쉽게 확장할 수 있는 편리한 기능도 있습니다.

웨이랜드 및 기타 기술

Linux 데스크톱에서 Wayland는 X11 및 관련 확장 프로그램의 대안입니다. 핵심은 컴포지팅 디스플레이 서버이며, "컴포지터"라는 용어는 종종 Wayland 서버를 설명하는 데 사용됩니다. 즉, 클라이언트가 콘텐츠를 화면 밖 버퍼에 렌더링하고 나중에 화면의 다른 클라이언트와 "합성"하여 그림자, 투명도, 배경 흐림 등과 같은 창 효과를 허용합니다.

원래 X11 프로토콜의 중요한 설계 원칙 중 하나는 디스플레이 서버가 화면과 입력 장치만 있는 얇은 단말기에서 실행될 수 있다는 것입니다. 그러면 클라이언트는 더 많은 처리 능력을 갖춘 원격 시스템에서 실행되어 네트워크 연결을 통해 서버와 통신하게 됩니다.

이와는 대조적으로, Wayland는 최신 설정에서는 클라이언트와 디스플레이 서버가 일반적으로 동일한 하드웨어에서 실행된다는 점에 착안하여 설계되었습니다. 분산 컴퓨팅, 원격 스토리지 및 원격 데스크톱 기능은 일반적으로 다른 메커니즘을 통해 처리됩니다. 이를 프로토콜에 설계하면 클라이언트와 서버 간에 그래픽 메모리를 공유할 수 있습니다: 컴포저가 클라이언트 콘텐츠를 화면에 배치할 때 그래픽 메모리의 한 부분에서 다른 부분으로 간단히 복사할 수 있습니다.

이 기능이 최적으로 작동하려면 그래픽 드라이버가 Wayland를 지원해야 합니다. 이 지원은 EXT_platform_wayland 이라는 EGL 의 확장을 통해 제공됩니다.

X11은 컴포지션 및 직접 렌더링과 같은 기능을 지원하도록 확장되었지만, Wayland는 처음부터 이러한 사용 사례를 중심으로 설계되었습니다. 또한 시간이 지남에 따라 X11이 복잡해진 것과는 대조적으로 작고 확장 가능한 것을 목표로 합니다.

확장성 및 임베디드 시스템

Wayland는 최소한의 코어로 쉽게 확장할 수 있으므로 임베디드 Linux 플랫폼을 구축할 때 이상적인 도구입니다.

예를 들어 데스크톱 스타일의 창 시스템 기능은 핵심 프로토콜의 일부가 아닙니다. 대신 Wayland에는 클라이언트가 표면을 관리할 수 있는 방법을 제공하는 "셸"이라는 특별한 범주의 프로토콜 확장이 있습니다. 데스크톱 스타일의 기능은 XDG Shell 이라는 셸을 통해 제공됩니다. 다른 유형의 시스템에는 더 전문화된(그리고 아마도 더 제한적인) "셸"을 사용할 수 있습니다. 예를 들어 In-Vehicle Infotainment 시스템을 만들 때는 IVI Shell 을 사용하는 것이 좋습니다.

Wayland 서버는 클라이언트가 연결할 때 지원되는 프로토콜(또는 "인터페이스") 목록을 브로드캐스트하며, 클라이언트는 사용하려는 프로토콜에 바인딩할 수 있습니다. 이 인터페이스는 표준 인터페이스일 수도 있지만 새로운 확장 기능도 쉽게 추가할 수 있습니다. Wayland는 프로토콜을 정의하기 위해 쉽게 이해할 수 있는 XML 형식을 정의하고 있으며, waylandscanner 도구를 사용하여 이로부터 C 코드를 생성할 수 있습니다. (Qt에는 추가 C++ 바인딩 코드를 생성하는 qtwaylandscanner 도구도 있습니다.)

클라이언트가 인터페이스에 바인딩하면 서버에 "요청"을 보낼 수 있고 서버는 클라이언트에 "이벤트"를 보낼 수 있습니다. 요청과 이벤트, 그리고 그 인수는 프로토콜을 설명하는 XML 파일에 정의되어 있습니다.

플랫폼을 처음부터 구축하는 경우 서버와 클라이언트의 코드를 모두 제어할 때 확장을 추가하는 것은 운영 체제 기능을 쉽고 제어된 방식으로 추가할 수 있는 방법입니다.

다중 프로세스 또는 단일 프로세스

Qt로 간단한 임베디드 플랫폼을 빌드할 때는 UI의 모든 부분을 단일 프로세스에서 실행하는 것이 가장 좋은 방법입니다. 그러나 시스템이 더 복잡해지면 멀티 프로세스 시스템을 고려할 수 있습니다. 이것이 바로 웨이랜드가 필요한 이유입니다. Qt를 사용하면 개발 프로세스의 어느 시점에서든 단일 프로세스와 다중 프로세스 사이를 전환할 수 있습니다.

멀티 프로세스의 이점

다음 다이어그램은 멀티 프로세스와 싱글 프로세스 시스템의 차이점을 보여줍니다.

멀티 프로세스 클라이언트 아키텍처

단일 프로세스 클라이언트 아키텍처

모듈은 Qt Wayland Compositor 모듈은 임베디드 Linux의 멀티 프로세스 시스템에서 디스플레이 서버와 컴포저를 생성하는 데 이상적입니다. 멀티 프로세스를 사용하면 다음과 같은 이점이 있습니다:

• 안정성
• 보안
• 성능
• 상호 운용성

멀티 프로세스의 장단점

단일 프로세스에서 멀티 프로세스로 전환할 때는 다음과 같은 장단점을 염두에 두는 것이 중요합니다:

• 비디오 메모리 사용량 증가
• 메인 메모리 사용량 증가
• 그래픽 리소스의 반복적인 저장
• 입력 지연 시간

X11 또는 사용자 지정 솔루션 대신 Wayland를 사용해야 하는 이유

앞서 설명한 것처럼 X11은 오늘날의 일반적인 시스템 설정에 최적화되어 있지 않습니다. 상당히 크고 복잡하며 사용자 지정 기능이 부족합니다. 실제로 X11로 클라이언트를 원활하게 실행하고 끊김 없이 60fps에 도달하는 것은 어렵습니다. 반면 Wayland는 구현하기 쉽고 성능이 우수하며 최신 그래픽 하드웨어에서 효율적으로 실행하는 데 필요한 모든 부분을 포함하고 있습니다. Linux의 임베디드 멀티 프로세스 시스템의 경우 Wayland가 표준입니다.

그러나 구형 하드웨어나 레거시 애플리케이션으로 작업하는 경우에는 Wayland가 좋은 선택이 아닐 수 있습니다. Wayland 프로토콜은 보안과 격리를 염두에 두고 설계되었으며, 클라이언트가 사용할 수 있는 정보와 기능에 대해 엄격하고 보수적입니다. 이로 인해 인터페이스가 더 깔끔하고 안전해지지만, 기존 애플리케이션에서 기대하는 일부 기능은 Wayland에서 더 이상 제공되지 않을 수 있습니다.

특히 Wayland가 최선의 선택이 아닐 수 있는 세 가지 일반적인 사용 사례가 있습니다:

1. 하드웨어 또는 플랫폼이 오래되어 X11만 지원하는 경우, 이 경우에는 선택의 여지가 없습니다.
2. 보안과 단순성을 위해 Wayland 프로토콜에 없는 기능에 의존하는 레거시 애플리케이션을 지원해야 하는 경우.
3. Wayland에서 전혀 실행되지 않는 UI 툴킷을 사용하는 레거시 애플리케이션을 지원해야 합니다. 경우에 따라 이러한 애플리케이션을 XWayland에서 대신 실행하여 이 문제를 해결할 수 있습니다.

X11이 매우 인기가 많았을 때 개발자들은 X11 문제를 우회하기 위해 자체적인 커스텀 솔루션을 작성했습니다. 이전 Qt 버전에는 Qt 윈도우 시스템(QWS)이 있었지만 지금은 단종되었습니다. 오늘날에는 이러한 사용 사례의 대부분이 Wayland에서 지원되며 사용자 지정 솔루션은 점점 더 일반화되고 있습니다.

Qt Wayland가 제공하는 기능

클라이언트용
Qt 클라이언트는 Wayland 프로젝트의 일부로 개발된 참조 컴포지터인 Weston을 포함한 모든 Wayland 컴포지터에서 실행할 수 있습니다.

모든 Qt 프로그램은 (다중 프로세스 시스템의 일부로) Wayland 클라이언트 또는 독립형 클라이언트(단일 프로세스)로 실행할 수 있습니다. 이는 시작 시 결정되며, 다양한 백엔드 중에서 선택할 수 있습니다. 개발 프로세스 중에 데스크톱에서 클라이언트를 먼저 개발한 다음 나중에 대상 하드웨어에서 테스트할 수 있습니다. 항상 실제 대상 하드웨어에서 클라이언트를 실행할 필요는 없습니다.

단일 프로세스 클라이언트 개발

Linux 컴퓨터에서 개발하는 경우 개발 컴퓨터의 창 내에서 컴포저를 실행할 수도 있습니다. 이렇게 하면 대상 디바이스와 매우 유사한 환경에서 클라이언트를 실행할 수 있습니다. 클라이언트를 다시 빌드하지 않고 -platform wayland 으로 컴포저를 실행하여 컴포저 내에서 실행할 수도 있습니다. -platform xcb (X11용)을 사용하는 경우 데스크톱에서 클라이언트를 실행할 수 있습니다. 즉, 컴포저를 사용할 준비가 되기 전에 클라이언트 개발을 시작할 수 있습니다.

서버의 경우
서버 또는 컴포저는 디스플레이에 연결하여 각 클라이언트의 콘텐츠를 화면에 표시합니다. 컴포저는 입력을 처리하고 해당 클라이언트에 입력 이벤트를 보냅니다. 차례로 각 클라이언트는 컴포저에 연결하여 해당 창의 콘텐츠를 전송합니다. 컴포저가 결정하는 것은 컴포저의 몫입니다:

• 콘텐츠를 표시하는 방법과 위치
• 표시할 콘텐츠
• 다양한 클라이언트 그래픽 버퍼로 수행할 작업

즉, 멀티 프로세스 시스템이 무엇인지 결정하는 것은 컴포저의 몫입니다. 예를 들어 클라이언트는 벽에 창문이 있는 3D 씬의 일부일 수도 있고, VR 시스템에 매핑되어 있거나 구체에 매핑되어 있을 수도 있습니다.

클라이언트 Qt Wayland Compositor 는 자체 컴포저를 구축하기 위한 API입니다. 커스텀 컴포저 UI를 구축하고 다양한 클라이언트의 창을 관리할 수 있는 완전한 자유를 제공합니다. Qt Quick 및 QML과 Qt Wayland Compositor 을 결합하여 인상적이고 상상력이 풍부한 UI를 만들 수 있습니다. 자세한 내용은 Qt Wayland Compositor.

Qt는 또한 강력하고 사용자 친화적인 API를 제공하여 Wayland 확장을 구현하고 QML 또는 C++에서 이를 사용할 수 있습니다.

관련 콘텐츠

• QtWS17 - Qt Wayland Compositor: 멀티 프로세스 사용자 인터페이스 만들기
• Qt Application Manager