태그 보관물: shell

[스터디-공지] WAYLAND 기반 윈도우 매니저 동작 원리 이해 (2주차)

이번 주 스터디에서는 지난 주에 시간이 부족하여 진행하지 못했던 컴포지팅과 최적화와 관련된 내용을 진행하려고 합니다. 최적화라는게 딱히 정답이 있는게 아니고, 전체 소프트웨어 계층에서 할 수 있는건 다 하자는거기 때문에 디스플레이 동기화, GPU, 컴포지팅, 어플리케이션까지 다양한 계층과 관련된 최적화 이슈를 다룰 예정입니다. 아래는 이번 스터디에서 다루게 될 세부 내용들입니다.

  • 컴포지팅 동작 원리 및 최적화 (scene graph, 데미지/클리핑 관리, …)
  • OpenGL 렌더러 최적화 (buffer_age, unpack_subimage, swap_buffers_with_damage, …)
  • 하드웨어 플레인 최적화
  • 디스플레이 동기화 최적화 (double/triple buffering, …)
  • WAYLAND 프로토콜 최적화 (subsurface protocol, presentation protocol, …)

자세한 사항은 금요일에 올릴 예정인 세미나 자료를 참고하시기 바랍니다. 그리고 세부 모임 공지는 아래와 같습니다.

일시 : 2014년 9월 28일 (일요일) 오후 2시 ~ 4시
장소 : 성균관대학교 자연과학캠퍼스 제 1공학과 21515호 (1호선 성균관대역)
연락 : nemoux00@gmail.com (페이스북 그룹 : https://www.facebook.com/groups/uxcoding/)

그리고 세미나가 끝난 후 따로 약속이 없으신 분들은 가볍게 식사라도 같이 하면 좋을꺼같습니다^^

Advertisements

[스터디-공지] WAYLAND 기반 윈도우 매니저 동작 원리 이해 (1주차)

이번 주 스터디에서는 WAYLAND 기반 윈도우 매니저의 출력 과정에 대한 내용을 진행하려고 합니다. 윈도우 매니저의 가장 중요한 역할이면서 성능에 가장 많은 영향을 주는 것이 컴포지팅이기 때문에 실제로 다루어야 할 내용 또한 많은 것 같습니다. 아래는 이번 스터디에서 다루게 될 세부 내용들입니다.

  • 윈도우 매니저 출력 과정 이해 (클라이언트 & 서버 구조, …)
  • 공유 메모리 기반 컴포지팅 동작 과정 이해 (shm, pixman, …)
  • 하드웨어 가속 기반 컴포지팅 동작 과정 이해 (opengl/egl, drm/kms, …)
  • 컴포지팅 과정 이해 (scene graph, …)
  • 디스플레이 동기화 과정 이해 (더블 버퍼링, vertical sync, …)

이번 주에 할 내용을 간단히 얘기하면, 어플리케이션(윈도우 클라이언트)이 윈도우에 무언가를 그리고 윈도우 매니저(윈도우 서버)가 이를 반영하여 실제 화면(모니터)에 뿌리는 과정에 대한 내용이라고 보시면 됩니다. 다루어야 할 내용과 이해가 필요한 부분이 많기 때문에 최적화와 관련된 내용과 확장 기능은 3주차에 진행할 계획입니다.

세부 모임 공지는 아래와 같습니다.

일시 : 2014년 9월 20일 (토요일) 오후 2시 ~ 4시
장소 : 성균관대학교 자연과학캠퍼스 제 1공학관 21515호 (1호선 성균관대역)
연락 : nemoux00@gmail.com (페이스북 그룹 : https://www.facebook.com/groups/uxcoding/)

본 스터디는 UI/UX 관련 오픈 소스에 대한 인프라가 조금이라도 넓어졌으면 좋겠다는 마음으로 시작한 것이니 이제 공부를 시작하시는 분들도 편한 마음으로 오시면 좋겠습니다. 그리고 참석하실 분들은 미리 연락주시면 감사하겠습니다.

[스터디-공지] WAYLAND 기반 윈도우 매니저 동작 원리 이해

예전에 공지드렸던 스터디를 이제 시작하려고 합니다.

본 스터디는 X 프로토콜을 대체하는 WAYLAND 프로토콜을 기반으로 윈도우 매니저의 동작 원리를 이해하고, 실제 코드레벨에서 분석하는 것이 목적입니다. (최종적으로는 자신이 원하는 형태의 윈도우 매니저를 개발할 수 있는 수준에 이르기를 기대합니다.) 이를 위한 첫 단계로 윈도우 매니저의 전체적인 동작 원리를 알아보는 시간을 우선 가져보려고 합니다.

본 스터디는 하나의 토픽을 선정하여 4~5 주 정도 연속으로 진행하고, 1~2 주 정도 쉬고나서 다음 토픽을 진행하는 방식으로 진행할 계획입니다. 그리고 매주 한번씩 모여 2시간 정도 진행할 계획이고, 1시간은 지난 시간에 했던 내용, 혹은 전반적인 내용에 관해서 자유롭게 얘기를 나누고, 나머지 1시간은 저희가 세미나 형식으로 다음 내용을 발표하는 형태로 진행할 계획입니다.

첫 번째 토픽은 윈도우 매니저를 기반으로 하는 SW 플랫폼의 전체적인 동작 원리를 이해하는 것이 목적입니다. 첫 토픽을 진행하면서 윈도우 매니저의 전반적인 내용에 대해 간략하게나마 이해를 하고, 이후에는 특정 부분에 대한 소스분석이나 최적화와 관련된 토픽들을 진행할 계획입니다.

첫 번째 토픽에 대한 스터디 일정은 다음과 같습니다.

0 주차 (8월 30일 토요일 오후 2-4시) : WAYLAND/WESTON 기반 윈도우 매니저 소개
– 윈도우 매니저 사용 목적, 구성 요소, 기본 동작 과정 소개 (compositor, shell, toolkit, …)
– 필수 오픈소스 소개 (pixman, cairo, pango, drm/egl, …)
– wayland/weston 구성 요소, 기본 동작 과정 소개 (입/출력 동작 과정)

1 주차 (9월 13일 토요일 오후 2-4시) : 출력 과정 이해
– 컴포지팅 동작 원리 이해
– 공유 메모리 기반 컴포지팅 과정 이해 (shm, pixman, …)
– 하드웨어 가속 기반 컴포지팅 과정 이해 (opengl, egl, drm, …)
– wayland/weston 기반 컴포지팅 과정 이해

2 주차 (9월 20일 토요일 오후 2-4시) : 입력 과정 이해
– 입력 장치 관리 이해 (udev, evdev, …)
– 포커스 모델 이해 (마우스, 키보드, 멀티 터치, …)
– wayland/weston 기반 입력 장치 동작 과정 이해
– wayland/weston 기반 가상 키보드/한글 입력 동작 과정 이해

3 주차 (9월 27일 토요일 오후 2-4시) : 렌더링 최적화 기술 분석
– scene graph 동작 과정 분석 (레이어 관리, 데미지/클리핑 관리, …)
– 더블 버퍼핑, 디스플레이 동기화, 하드웨어 플레인 동작 과정 분석
– OpenGL 확장 기능 분석 (buffer_age, unpack_subimage, swap_buffers_with_damage, …)

4 주차 (10월 4일 토요일 오후 2-4시) : WAYLAND 기반 윈도우 매니저 분석
– 서페이스 관리 분석 (윈도우 활성화, 서브서페이스, …)
– 그랩 인터페이스 분석 (윈도우 이동, 크기 변환, …)
– 데이터 인터페이스 분석 (drag & drop, selection, clipboard, …)
– 쉘 인터페이스 분석 (wayland/xdg shell, workspace, …)
– 확장 프로토콜 분석 (subsurface, presentation, …)

5 주차 (10월 11일 토요일 오후 2-4시) : UI/UX 플랫폼 분석
– wayland 기반 UI/UX 플랫폼 구조 분석
– 툴킷 엔진 지원 분석 (GTK, QT, …)
– X 프로토콜 지원 분석 (xwayland)
– 어플리케이션 지원 분석 (브라우저, 동영상 재생, …)
– wayland 기반 윈도우 매니저 소개 (weston, mutter, kwin, hawaii, …)

이렇게 6 주 동안 진행할 계획이고, 다음 주(0 주차)에는 이번 토픽을 시작하기에 앞서 필요한 기본적인 내용을 소개드릴 계획입니다. 그리고 저희가 WAYLAND/WESTON 으로 EGL 까지 실습해 볼 수 있는 환경을 VMWARE 가상 이미지로 만들어서 드릴테니 받아가시기 바랍니다. (압축해서 7기가 정도 됩니다.)

위치는 성균관대학교 자연과학캠퍼스(1호선 성균관대역)이고, 구체적인 장소는 교내에 저희가 세미나실을 예약한 후에 다시 공지하도록 하겠습니다. 그리고 이미 이메일을 통해 참여 신청을 해주신 분들 외에 참여하시고 싶으신 분들은 장소 섭외 문제 때문에 미리 저희에게 이메일로 (nemoux00@gmail.com) 신청해주시기 바랍니다.

마지막으로 스터디에 대한 문의나 향후 기술적인 논의는 저희가 미리 만들어놓은 페이스북 그룹(https://www.facebook.com/groups/uxcoding/) 을 통해 해주시면 감사하겠습니다.

[WAYLAND] wayland 관련 참여해볼만한 프로젝트 소개

우리가 무언가 새로운 것을 배우고자 할 때 가장 좋은 방법 중에 하나는 일단 부딪쳐서 경험해보는 것입니다. 특히, 소프트웨어 개발자들에게는 직접 해본다는건 그 무엇보다 중요한 일인거같습니다. 그래서 오늘은 현재 활발히 진행 중인 대표적인 wayland 와 관련된 오픈소스 프로젝트들을 간단히 소개드리고자 합니다. 필자는 wayland 를 이용한 컴포지터와 쉘을 개발 중이기 때문에 관련 내용들이 블로그에 많지만, 다양한 클라이언트와 툴킷들도 wayland 를 지원하기 위한 작업들을 한창 진행 중이니 혹시 관심있으신 분들은 참여해보시면 좋은 경험이 될것같습니다.

wayland

# wayland
wayland 는 XML 파일 형식으로 되어있는 wayland 프로토콜을 클라이언트와 서버가 사용할 수 있는 C 코드와 헤더파일로 변환해주는 일과 실제 유닉스 도메인 소켓을 이용하여 메시지를 주고 받을 수 있도록 도와주는 라이브러리입니다. wayland 프로토콜을 이용하는 모든 클라이언트와 서버는 이 라이브러리를 이용하게 됩니다. 주로, wayland 의 창시자인 kristian høgsberg 이 관리하고 작년 중후반부터 안정화가 되어서 현재는 수정이 거의 없는 상태입니다.

# weston compositor
wayland 를 이용한 레퍼런스 컴포지터입니다. 말그대로 여러 서페이스들을 하나의 화면으로 합쳐주는 pixman 과 OpenGL 기반의 렌더링과 입출력 장치 관리 등을 제공합니다. 기능적인 부분과 정책적인 부분들이 많기 때문에 취향에 따라 할 수 있는 일들은 아직 굉장히 많이 남아있는 상태이고, 더군다나 FBDEV, DRM, X11 과 같은 기본적인 백엔드외에 다양한 백엔드들에 대한 지원도 가능하기 때문에 혹시 관심있는 사람은 새로운 백엔드를 개발해서 추가할 수 있는 기회도 있습니다. (하지만 wayland 프로토콜에 대한 검증과 레퍼런스 컴포지터이기 때문에 최적화나 사소한 버그 수정보다는 새로운 기능이나 정책에 대한 검증이 우선시 되고 있어 약간 폐쇠적인 성향이 있습니다.) 그리고 weston compositor 를 이용하여 다양한 쉘을 개발할 수 있도록 플러그인을 제공하고 있습니다.

# weston desktop-shell
weston shell-plugin 을 이용하는 기본적인 데스크탑 환경을 위한 쉘입니다. 이것도 검증을 위한 쉘이기 때문에 현재 디자인이나 이런 부분들은 아무도 신경을 쓰지 않고 있습니다.

# hawaii/orbital shell
weston shell-plugin 을 이용하는 데스크탑 환경을 위한 쉘들입니다. 둘다 QT5 기반이라서 디자인도 상당히 깔끔하고, 특히 hawaii 프로젝트는 상당히 빠른 속도로 개발되고 있는 프로젝트입니다. 새로운 데스크탑 환경을 개발하고 싶거나 관심있으신 분들은 참고하시면 많은 도움이 될 것 같습니다.

# mutter/kwin
리눅스 양대 데스크탑 환경인 gnome 과 kde 의 컴포지터로써 작년부터 꾸준히 wayland 지원 작업을 진행해왔고, 특히 mutter 의 개발자는 wayland/weston 에서도 굉장히 활발하게 활동하고 있고 아주 큰 영향력을 행사하고 있습니다. 하지만 X11 때부터 오랫동안 이어져오던 프로젝트여서 소스가 크고 X11 에 의존적인 부분이 많아서 실질적으로 참여하기 위해서는 어느 정도 준비가 필요할 것 같습니다.

# EFL
주로 스마트 장치에서 사용되고 있는 리눅스 기반의 통합 GUI 환경이고, 주로 삼성의 타이젠에서 사용되고 있고 주요 개발자들이 삼성 소속이기 때문에 약간 폐쇠적일꺼 같습니다. (이건 어디까지나 추측일뿐…) 하지만 그래서 그런지 가장 적극적으로 X11 에 대한 의존성을 제거하고 wayland 로 넘어가고 있는 프로젝트입니다. 소스를 보진 않았지만 wayland 를 위해 컴포지터를 거의 새로 개발했다고 하는 기사를 여러 번 봤기 때문입니다. 아무래도 다양한 데스크탑 환경을 책임지고 있는 mutter/kwin 보다는 빠르게 행동을 취하기 용이해서 그런 것 같습니다.

# xwayland
wayland 에서 X11 호환성을 유지할 수 있도록 도와주는 프로젝트입니다. 현재 weston 에 레퍼런스 구현물이 있고, xserver 측에도 백엔드 작업이 진행 중입니다. 아직 안정화가 필요하고 현재도 다양한 최적화가 진행 중입니다.

# libinput
wayland 를 이용하여 컴포지터와 쉘을 개발할 때 사용할 수 있는 udev/evdev 기반의 입력 장치 처리를 위한 라이브러리입니다. 공식 프로젝트로 인정받은지 얼마되지 않았고, 멀티터치 등 다양한 새로운 기능들이 추가되고 있어 앞으로 많은 작업들이 필요한 프로젝트입니다.

# mesa/DRM/linux kernel DRM driver
데스크탑과 스마트 장치 모두에서 OpenGL 을 이용한 컴포지팅이 일반화되었기 때문에 현재도 그렇고, 앞으로도 다양한 최적화 작업이 진행될 것으로 예상됩니다. 특히, wayland 를 이용한 스마트폰, 스마트TV, 스마트Car 와 같은 장치를 개발하는 회사에서 많은 관심을 가지고 있는 분야이기도 합니다. 하지만 mesa 소스의 난해함과 리눅스 커널 드라이버까지 포함되어있어 진입 장벽이 다른 프로젝트에 비해 상당히 높은 편입니다.

# input-method
wayland 에서 가상 키보드와 같은 input method 를 지원하는 프로젝트도 진행 중입니다. 현재 weston 은 간단한 형태의 가상 키보드를 제공하고 있기 때문에 관심있으신 분은 참고하면 좋을 것 같습니다.

# GTK+/QT
리눅스의 가장 대표적인 툴킷들이기 때문에 작년부터 활발히 wayland 지원 작업을 진행해왔습니다. 하지만 아직 xdg_shell 인터페이스가 안정화되지 않은 문제와 여러 가지 진행 중인 것들이 많이 남아있기 때문에 현재도 활발히 진행되고 있습니다.

# clutter/cogl
OpenGL 기반의 컴포지팅 라이브러리로 여러 어플리케이션에서도 사용 중이지만, 현재 mutter 에서도 사용 중입니다. 그래서 아직 안정화는 안 됐지만 wayland 컴포지터를 개발할 때 편리하게 사용할 수 있는 기능들이 몇 가지 들어가있습니다. 아쉬운 점은 정확한 이유는 모르겠지만 개발자 커뮤니티가 활발하진 않습니다.

# ozone-chrome
wayland 입장에서 가장 중요하고 필요한 일 중의 하나인 브라우저 지원을 해결해줄 수 있는 고마운 프로젝트입니다. ozone 은 크롬이 다양한 환경에서 쉽게 동작할 수 있도록 도와주는 계층이고, ozone 에 wayland 백엔드 지원 작업이 인텔을 중심으로 활발히 진행되고 있습니다. 최근 wayland 위에서 HTML5 기반의 하드웨어 가속을 지원하는 유투브 동영상 재생 데모도 공개되었습니다.

# gstreamer
세계적인 오픈소스 컨설팅 회사인 Collabora 에서도 wayland 에 굉장히 많은 관심을 가지고 참여를 하고 있습니다. 특히, Collabora 가 가장 많은 관심을 가지고 있는 프로젝트가 gstreamer 이기 때문에 wayland 에서도 영상 재생을 원활히 할 수 있는 기능에 대한 기여가 특히 높습니다. wayland 는 데스크탑 환경 뿐 아니라 스마트 환경에서도 활용도가 높기 때문에 위에서 언급했던 OpenGL 을 이용한 컴포지팅 최적화와 더불이 많은 회사들이 관심을 가지고 있는 분야입니다.

이외에도 수많은 프로젝트가 활발히 진행 중입니다. 기존의 X11 환경에서 혹은 프레임버퍼 위에서 동작하던 거의 모든 UI 관련된 프로젝트들이 wayland 로 전환되고 있다고 보면 되기 때문에 앞으로 wayland 의 필요성과 활용도는 점점 더 높아질 것으로 예상됩니다.

[WAYLAND] 어플리케이션 지원

wayland 가 제대로 자리를 잡기 위해 가장 필요한 것은 바로 어플리케이션 지원이다. 여기에는 현재 크게 보면 두 가지 방식이 존재한다. 첫 번째는 X11 기반의 어플리케이션을 지원하는 방식이고, 두 번째는 wayland 기반의 어플리케이션을 직접 지원하는 방식이다. 지난 글에서 이미 X11 기반의 어플리케이션 지원 문제는 xwayland 를 이용하여 해결하고 있다고 설명하였고, 오늘은 wayland 가 어떤 형태로 어플리케이션 개발을 지원하고 있는지, 그리고 할 계획인지에 초점을 맞춰서 설명하고자 한다.

app

위의 그림은 현재 다양한 형태의 어플리케이션들과 툴킷, 그리고 wayland 기반의 컴포지터/쉘의 관계를 나타낸 것이다. 일반적으로 UI 프로그래밍을 할 때는 세 가지 정도의 방식을 사용하는데, 첫 번째는 GTK+/QT 와 같은 툴킷을 사용하여 개발하는 것이고, 두 번째는 X11 이나 wayland 의 로우레벨 인터페이스를 직접 사용하여 개발하는 것이고, 마지막은 OpenGL 을 사용하여 개발하는 것이다.

첫 번째 GTK+/QT 와 같은 툴킷을 사용하는 경우에 대해 살펴보자. 위의 그림에서 보는 것처럼 대다수의 툴킷 엔진들은 다양한 백엔드를 지원한다. 대표적으로 X11 을 지원하고 있고, MS 윈도우 환경에서도 사용할 수 있도록 백엔드를 지원하는 경우도 많다. 그리고 현재 GTK+ 와 QT 의 경우에는 이미 wayland 를 백엔드로 지원하고 있고, 점점 완성도를 높여가고 있다. 이외에도 많은 툴킷들이 wayland 를 백엔드로 지원하는 작업을 진행 중이고, 머지않아 실제로 사용 가능한 수준에 도달할 것으로 보인다. 이 경우에는 대부분 어플리케이션이 툴킷의 백엔드에 영향을 받지 않기 때문에 수정없이 바로 wayland 에서 사용할 수 있게 된다. 그리고 아직 wayland 백엔드가 없는 툴킷 엔진들도 X11 프로토콜을 지원하는 xwayland 를 이용하여 그대로 사용할 수 있다.

두 번째 로우레벨 인터페이스를 직접 사용하는 경우를 살펴보자. 이미 언급했던 것처럼 X11 프로토콜을 직접 사용하는 어플리케이션도 xwayland 를 이용하여 wayland 에서 수정없이 동작 할 수 있다. 그리고 wayland 가 제공하는 여러 가지 인터페이스를 직접 이용하여 개발하는 것 또한 가능한데, wayland 에서 제공하는 인터페이스는 크게 보면 두 가지로 분류된다. 첫 번째 코어 인터페이스(core interface) 는 wl_surface, wl_buffer, wl_seat 과 같이 쉘의 형태에 영향을 받지 않는, 주로 필요한 화면을 생성하고, 그 화면에 내용을 갱신하고, 입력 장치로부터 들어오는 이벤트를 받기 위해 사용된다. 그리고 나머지 쉘 인터페이스(xdg shell interface) 는 윈도우의 위치를 옮기고 크기를 조절하거나, 전체화면으로 전환하는 등의 쉘이 제공하는 기능으로, 현재 개발되고 있는 쉘 인터페이스인 xdg_shell 은 gnome 과 kde 가 목표로 하는 개인용 데스크탑 환경에 적합한 쉘 인터페이스이다. 추후에 필요하다면 타블릿이나 다양한 환경에 필요한 쉘 인터페이스들이 개발될 것으로 보인다. 대부분의 어플리케이션 개발자들은 툴킷 엔진을 이용하기 때문에 필요가 없겠지만, 만약에 기존의 툴킷을 wayland 로 포팅하는 일을 한다면 반드시 알아야 하는 부분이다.

마지막으로 OpenGL 을 사용하는 경우를 살펴보도록 하겠다. OpenGL 은 크게 렌더링 API 와 플랫폼 API 로 구성된다. 렌더링 API 는 우리가 흔히 아는 vertex 와 같은 실제 무언가를 그리기 위해 사용되는 API 이고, 플랫폼 API 는 OpenGL 을 사용할 수 있는 환경을 구축하기 위해 사용되는 API 이다. 예를 들어 OpenGL 컨텍스트를 생성하거나 텍스쳐와 프레임버퍼를 생성하는 일들은 현재 OpenGL 이 동작 중인 시스템과 관련되어 있기 때문에 이는 플랫폼 API 라고 해서 따로 분류가 된다. 이 플랫폼 API 는 다양한 것들이 존재하는데 리눅스의 X11 환경에서 사용하는 GLX 와 MS 의 윈도우 환경에서 동작하는 WGL, 그리고 애플의 OSX 에서 동작하는 CGL 등이 있다. 그리고 최근 Khronos Group 에서 표준화되고 있는 EGL 은 다양한 환경에서 사용할 수 있는 플랫폼 API 이고, 현재 wayland 는 EGL 만을 지원하고 있다. (참고로 이미 MS 의 윈도우와 애플의 OSX 도 EGL 을 지원하고 있는 것으로 알고 있다.) 그래서 wayland 에서 OpenGL 을 이용한 어플리케이션을 개발할때는 플랫폼 독립적인 렌더링 API 와 EGL 플랫폼 API 를 이용하여 개발하면 된다. (현재 wayland-egl 은 mesa 와 같이 협력하면서 개발 중이다. 그리고 GLX 는 아직 xwayland 에 의해 지원되지 않는 것으로 알고 있지만, 언젠가는(?) 누군가에 의해(?) 지원되지 않을까 예상해본다.)

이 외에도 현재 개발 중인 것들은 효과적인 영상 재생을 위한 presentation feedback extension 이나, 여러 개의 GPU 를 효과적으로 지원하기 위해 offloading 을 지원하는 dma-buf (prime) 같은 기능들도 있다. 앞으로도 꾸준히 여러 가지 어플리케이션 개발에 도움이 될만한 다양한 확장 기능들이 추가될 것으로 보인다.

[WAYLAND] 윈도우 및 레이어 관리

윈도우 매니저의 기본적인 역할 중에 하나는 여러 개의 윈도우를 여러 가지 정책에 의해 결정된 순서대로 차곡차곡 쌓아서 보여주는 것이다. 결정된 순서에 의해 실제 스크린에 출력할 화면을 만들어내는 것은 컴포지터의 역할이라고 볼 수 있지만, 그 순서를 결정하는 것은 바로 쉘의 역할이다. 오늘은 wayland/weston 에서 어떤 방식으로 윈도우들의 순서를 결정하고 관리하는지 알아보고자 한다.

우선 한 가지 설명하고 넘어가야 할 부분이 바로 뷰(view) 이다. 초기 weston 은 서페이스(surface) 가 실제 위치(geometry) 를 가지는 윈도우의 역할을 수행했지만, 몇 달 전에 그 역할을 뷰라는 새로운 자료구조에게 넘겨주었다. (사실 필자가 작년 5 월달쯤에 nemoshell 초기 버전을 개발할 때 이렇게 했었는데, 그 뒤에 weston 에 이러한 기능이 추가되었다.) 이렇게 하면 여러 가지 좋은 점이 있지만 그 중에 하나는 하나의 서페이스를 여러 개의 윈도우가 공유하는 것이 훨씬 간단해진다는 것이다. 실제 현재도 weston 에서 관리하는 서페이스 자료 구조는 뷰의 리스트를 가지고 있고, 서페이스의 내용들이 뷰 리스트 전체에 동시에 반영되게 되어있다. 이런 이유로 쉘에서 관리하는 쉘서페이스(shell surface) 에서 직접적으로 관리하는 대상은 더 이상 서페이스가 아닌 뷰가 된다.

weston 에서 윈도우를 화면에 실제로 나타나게 하고, 마우스로 잡아서 위치를 옮기거나 크기를 변경하기 위해서는 wl_shell 인터페이스의 get_shell_surface 리퀘스트를 이용해야 한다. wl_surface 를 인자로 해당 리퀘스트를 호출하여 weston 에서 서페이스를 위한 새로운 뷰와 쉘서페이스를 만들고나면, 이제 실제로 윈도우가 화면에 나타나기 위한 모든 준비가 끝난 것이다. (실제로 화면에 나타나는 것은 wl_surface 에 처음으로 commit 을 요청한 시점이다. 단순히 얘기하면 실제 윈도우에 채울 내용이 생기면 윈도우를 화면에 표시하겠다는 말이다.) 위의 관계들을 간단히 그림으로 표현하면 아래와 같다.

view

이제 본격적으로 weston 에서 윈도우를 어떻게 관리하는지 알아보도록 하자. 현재의 weston 은 레이어(layer) 라는 자료구조를 이용하여 윈도우(실제로는 뷰) 들을 여러 계층으로 구분해서 관리하고 있다. 예를 들어, 풀스크린(fullscreen) 레이어는 전체화면 모드로 동작 중인 뷰가 속해있고, 커서(cursor) 레이어는 마우스 커서를 표시하는 뷰가 속해있다. 아래 그림은 뷰와 레이어의 관계, 그리고 현재 weston 에 어떤 레이어들이 정의되어있는지를 보여주고 있다.

layer

가운데 fade_layer 부터 background_layer 는 먼저 보여지는 순서대로 나열한 것이다. 즉, fade_layer 에 속해있는 뷰들이 화면의 가장 앞에 보일 것이고, background_layer 에 속해있는 뷰들이 화면의 가장 뒤에 보일 것이다. 각각의 레이어들이 어떤 역할을 하는지 간단히 소개하도록 하겠다.

  • fade_layer..전체 화면을 fade in 시킬 때 사용하는 레이어이다. 검은색의 뷰를 전체 화면 크기로 출력하면 가장 높은 레이어에 있기 때문에 검은색의 뷰만 보일 것이다. 이 레이어가 커서 레이어보다 높은 위치에 있기 때문에 마우스 커서 조차 보이지 않을 것이다.
  • cursor_layer..페이드 레이어보다는 낮지만 다른 무엇보다는 높은 레이어이다. 그렇기 때문에 마우스 커서가 항상 제일 위에 보이게 된다.
  • fullscreen_layer..전체화면 모드의 뷰가 속해있는 레이어이고, 패널 레이어보다 높기 때문에 시작 메뉴보다 위에 위치하게 된다.
  • panel_layer..시작 메뉴와 같은 뷰들이 속해있는 레이어이다. 워크스페이스 레이어보다는 높기 때문에 전체화면 모드가 아닌 뷰들보다는 항상 위에 존재하게 된다.
  • workspace_layer..일반적인 뷰들이 위치하는 레이어이고, 여러 개의 워크스페이스를 사용하면 한번에 하나의 워크스페이스 레이어만이 레이어 리스트에 연결된다.
  • background_layer..가장 아래 있는 배경 화면을 보여주는 뷰가 속해있다.
  • lock_layer..스크린세이버가 작동하여 윈도우 매니저가 잠금 모드에 진입할 때만 연결되는 레이어로, 커서 레이어 바로 아래로 연결된다.
  • input_panel_layer..가상 키보드가 있을때만 사용되는 레이어로 패널 레이어 바로 뒤에 위치하기 때문에 일반 윈도우보다는 항상 위에 존재하게 된다.

전체 레이어의 우선순위는 이런 형태로 구성되어있고, 일반적인 뷰들이 모여있는 워크스페이스 레이어에 대해 몇 가지만 추가로 설명하도록 하겠다. 예를 들어, 브라우저 하나와 터미널 하나가 띄워져있다고 가정해보자. 현재는 브라우저가 앞에 있고 터미널이 뒤에 있다. 이런 상황에서 터미널을 앞으로 가져와서 사용하고 싶을때는 마우스로 터미널을 클릭하면 터미널이 앞으로 나와서 키보드로 입력 가능한 상태가 된다. 이건 입력 장치의 포커스와 관련된 얘기지만 오늘은 레이어 얘기를 하고 있으니 간단히만 설명하도록 하겠다. weston 은 마우스 왼쪽 버튼을 현재 포커스된 뷰를 활성화시키는 용도로 바인딩시켜놓았다. 그래서 마우스를 클릭하게 되면 포인터 장치에 포커스되어있는 뷰를 현재 워크스페이스 레이어의 맨 위로 옮기고, 키보드 장치의 포커스로 등록한다. (마우스와 같은 포인터 장치는 움직일 때마다 포커스를 갱신하기 때문에, 포인터가 터미널 위에 올라간 순간 바로 포커스로 등록된다.) 이런 과정을 거치기 때문에 터미널이 브라우저 앞으로 나와서 키보드로 입력 가능한 상태가 되는 것이다.

이제 마지막으로 간단히 저렇게 구성된 레이어와 뷰 리스트들이 어떻게 컴포지팅되는지를 설명하도록 하겠다. 현재의 weston 은 매번 화면을 갱신할 때마다 전체 레이어에 속해있는 모든 뷰들을 하나의 리스트로 재구성한다. 맨 위의 fade_layer 에 있는 뷰들부터 하나씩 가져와서 하나의 리스트에 순서대로 쌓고, 그 결과물을 렌더러에게 넘기면 그 순서대로 최종 화면을 만들어내게 된다.

지금까지 기능적인 부분에 초점을 맞춰 윈도우 계층 관리에 대해 알아보았다. 하지만 쉘의 역할은 다양한 정책적인 결정이 필요한 경우가 많기 때문에 가끔 애매한 상황이 발생한다. 예를 들어, 며칠 전에 메일링 리스트에 올라왔던 버그 중에 하나는 전체화면 모드의 터미널에서 커맨드로 터미널을 실행하게 되면 새로 실행된 터미널은 워크스페이스 레이어에 속하기 때문에 전체화면 모드의 터미널에 가려져 보이지 않지만, 새로 실행된 터미널이 활성화될 때 키보드 포커스를 가져가기 때문에 키보드 포커스를 가지고 있는 뷰가 화면에 보이지 않는 상황이 연출된다. 이건 가장 기본적인 정책 두 가지가 충돌한 경우라고 볼 수 있는데, 현재 몇 가지 논의가 오고 가고 있지만 아직 결론이 나진 않았다. 이런 것처럼 실제 쉘을 개발할 때는 기능적인 부분도 많이 이해를 해야겠지만, 이런 사용자 경험 관련된 정책적인 부분들에 대해서도 많은 고민이 필요한 것 같다.

[WAYLAND] 4. 입력 장치

이번 시간에는 키보드, 마우스와 같은 입력 장치들이 어떻게 다루어지는지를 살펴보고자 한다. 우선 입력 장치를 다루기 전에 seat 이라는 개념에 대해 간단히 설명하도록 하겠다. seat 은 한국어로 번역하면 자리/좌석을 의미한다. 즉 한 명의 사용자가 자리에 앉아서 사용할 수 있는 장치들의 묶음을 보통 하나의 seat 이라고 보면 된다. 예를 들어 우리가 일반적으로 사용하는 키보드와 마우스, 그리고 모니터가 각각 하나씩 있으면 하나의 seat 이 완성이 되는 것이다. 그래서 일반적인 사용자들은 “seat0” 만을 사용한다(보통은 키보드, 마우스 모니터가 하나씩 있기 때문에). 하지만 마치 하나의 서버에 여러 개의 터미널을 접속해서 사용하는 것처럼 하나의 본체에 여러 개의 키보드, 마우스 그리고 모니터를 연결해서 사용하는 경우도 있을 수 있다. 이럴 경우에는 윈도우 매니저가 multi-seat 환경을 지원해야만 여러 명의 사용자가 동시에 혹은 각각 윈도우 환경을 사용할 수 있다. multi-seat 자체만으로도 여러 가지 이슈들이 많기 때문에 자세한 이야기는 따로 하도록 하겠다(이를 위해 우리가 전통적으로 알고 있는 virtual terminal 과 최근 많은 이슈화가 되고 있는 systemd/logind 에 대해 조만간 자세히 다루도록 하겠다.)

우선 wayland/weston 환경에서 입력 장치를 사용하기 위해서는 일단 udev 를 이용하여 현재 사용 가능한 입력 장치들을 활성화 한다. 이때 기본적으로 “seat0” 를 사용하지만 옵션으로 다른 seat 을 사용할 수 있다(현재의 weston 은 기본적으로 하나의 컴포지터 인스턴스에서 하나의 seat 만 사용할 수 있다. 즉, 여러 개의 seat 을 사용하기 위해서는 독립적인 컴포지터 인스턴스를 필요한 만큼 동작시켜야 한다.) 그리고 활성화된 입력 장치들은 evdev 를 이용하여 이벤트를 전달받을 수 있도록 준비하여 클라이언트가 요청하면 바로 사용할 수 있도록 준비를 마무리한다.

weston 이 초기화를 끝낸 후, 클라이언트가 실행되면 weston 은 wl_registry 인터페이스를 이용하여 클라이언트에게 wl_seat 인터페이스를 등록하도록 요청하고, 클라이언트가 wl_seat 인터페이스를 등록하고 나면 weston 은 클라이언트에게 현재 사용가능한 입력 장치들에 대한 정보를 capabilities 이벤트를 이용하여 전달한다. 만약 현재 하나의 키보드와 하나의 마우스가 사용가능하다면 클라이언트는 capabilities 이벤트 핸들러에서 이 사실을 알 수 있고, 바로 키보드와 마우스를 사용하기 위해 각각 wl_keyboard 인터페이스와 wl_pointer 인터페이스를 등록한다. 그리고나서 해당 클라이언트가 키보드와 마우스에 포커싱이 되면 해당 입력 장치에서 발생한 이벤트들을 wl_keyboard, wl_pointer 인터페이스를 통해 전달받게 된다. 아래의 그림은 wayland/weston 에서 입력 장치가 동작하는 전체적인 과정을 간단히 그림으로 표현한 것이다.

seat

위의 그림을 보면서 간단히 요약하면, weston 에서 udev 로 현재의 seat (기본적으로 “seat0”) 에 해당하는 입력 장치들을 evdev 를 이용하여 사용가능하도록 준비한다. 그리고 클라이언트에게 사용가능한 입력 장치들에 대한 정보를 wl_seat 인터페이스의 capabilities 이벤트로 전달하고, 클라이언트는 필요한 입력 장치들을 사용하기 위해 wl_keyboard, wl_pointer 혹은 wl_touch 인터페이스를 연결한다. 여기까지가 wayland/weston 환경에서 입력 장치가 동작하는 과정이다.