2026년에는 드디어 Wayland를 쓸 수 있을까?
원문은 Michael Stapelberg님이 에 게재했습니다. 이 블로그 구독하기
Wayland는 리눅스에서 그래픽 스택을 구현하기 위한 X 서버(X11, Xorg)의 후계자다. Wayland 프로젝트는 사실 2008년에 시작됐는데, 내가 X11용 i3 타일링 윈도우 매니저를 만든 2009년보다 1년 이른 시점이다 — 하지만 지난 18년간(!) Wayland는 내 컴퓨터에서 한 번도 제대로 쓸 수 없었다. 폐기 예정인 소프트웨어에 머물고 싶지 않아 매년 Wayland로 옮겨 보려 시도하는데, 이 글에서는 2026년 현재 Wayland로 이주하지 못하게 막는 요소가 무엇인지 정리한다.
역사적 배경
초창기 몇 년 동안 Wayland는 내 컴퓨터에서 실행 자체가 거의 되지 않았다. 운 좋게 화면에 뭔가 떴을 때도, 데모 컴포지터인 Weston에서 장난감 같은 데모 앱 몇 개를 실행할 수 있는 정도가 전부였다.
2014년 무렵 GNOME이 Wayland를 지원하기 시작했고, 몇 년 뒤 KDE가 뒤를 이었다. Firefox, Chrome, Emacs 같은 주요 애플리케이션들은 Wayland 도입이 더 느려서, 아주 최근까지도 — geeqie 같은 경우는 지금도 — 사용자가 별도 플래그나 환경 변수를 지정해 실험적인 구현을 직접 활성화해야 했다.
안타깝게도 드라이버 지원 상황은 수년간 열악한 채로 남아 있었다. 내 8K 모니터를 지원하는 유일한 카드인 nVidia 그래픽 카드에서는 Wayland가 아예 동작하지 않거나 심한 그래픽 깨짐과 충돌을 일으켰다.
2020년대에 들어서면서 점점 더 많은 배포판이 기본 세션을 Wayland로 전환하거나 심지어 X11 세션을 아예 제거하겠다고 발표했고, RHEL은 X 서버에 대한 기여를 단계적으로 축소하고 있다.
Asahi Linux(Mac용, 자체 GPU 드라이버를 사용한다!) 같은 최신 리눅스 배포판은 Wayland를 주력 데스크톱 스택으로 간주하고, X11은 최대한 지원하는 수준에만 머무르고 있다.
그래서 Wayland로 전환해야 한다는 압박은 점점 커지고 있다! 이제 쓸 만한 상태가 됐을까? 무엇이 아직 부족할까?
Wayland 실행시키기
하드웨어
테스트는 내 랩 PC로 진행했는데, 2022년 하이엔드 리눅스 PC에서 약간 업그레이드한 버전이다.
내 셋업에 대한 자세한 설명은 stapelberg uses this: my 2020 desk setup 글에 정리해 두었다.
이 글에서 가장 중요한 점은 Dell 8K 32인치 모니터(해상도: 7680x4320!)를 사용한다는 것으로, 내 경험상 이 모니터는 nVidia 그래픽 카드에서만 제대로 호환된다(가끔 다른 카드도 시도해 본다).
그래서 랩 PC와 메인 PC 모두 nVidia GPU를 사용한다:
- 랩 PC에는 nVidia GeForce RTX 4070 Ti가 들어 있다.
- 메인 PC에는 nVidia GeForce RTX 3060 Ti가 들어 있다.
(내 PC에 왜 더 오래된 카드를 쓰는지 궁금할 텐데, 한 번 충돌이 있었을 때 GPU를 의심해 4070에서 기존에 쓰던 3060으로 다시 교체했기 때문이다.)
nVidia 드라이버 지원
수년 동안 nVidia 드라이버는 Wayland에서 전혀 지원되지 않았다.
알려진 바에 따르면 nVidia는 Wayland가 사용하던 API 지원을 거부하고 자신들의 EGLStreams 방식이 더 우수하다고 주장했다. 다행히 nVidia 드라이버 495(2021년 말)에서 GBM(Generic Buffer Manager) 지원이 추가됐다.
하지만 GBM 지원이 추가된 뒤에도 많은 Wayland 세션을 실행할 수는 있게 됐지만, 세션이 부드럽게 동작하지는 않았다. 심한 그래픽 깨짐과 아티팩트가 나타나 제대로 작업을 할 수 없었다.
이 깨짐 현상을 해결한 것이 explicit sync 지원이었다. nVidia 드라이버는 AMD나 Intel과 달리 implicit sync를 지원하지 않기 때문에, Wayland(와 wlroots, sway)에 explicit sync 지원이 필요했다.
Sway 1.11(2025년 6월)과 wlroots 0.19.0이 explicit sync를 지원하는 첫 버전이다.
동작하지 않음: 8K 모니터의 TILE 지원
nVidia 드라이버가 이제 Wayland에서 그 자체로는 동작하게 됐지만, 안타깝게도 내 환경에서 Wayland를 쓰기에는 아직 충분하지 않았다. 내 Dell UP3218K 모니터는 MST(Multi Stream Transport)와 TILE 지원을 이용해 두 개의 DisplayPort 1.4 연결이 필요하다. 이 조합은 지난 8년 이상 X11에서는 아무 문제 없이 동작해 왔다.
GNOME은 이 모니터를 네이티브 해상도인 7680x4320@60으로 제대로 설정하지만, sway에서는 모니터가 잘못 인식되어 두 개의 별도 모니터로 나타난다.
이런 동작의 원인은 wlroots가 TILE 속성을 지원하지 않기 때문이다(2019년의 이슈 #1580). 다행히 2023년에 기여자 EBADBEEF가 초안 머지 리퀘스트 !4154를 보내 TILE 속성 지원을 추가했다.
하지만 TILE 패치를 적용해도 내 모니터는 여전히 제대로 동작하지 않았다. 모니터의 오른쪽 절반이 그냥 검게 나온 것이다. grim으로 스크린샷을 찍으면 전체 화면이 제대로 보이므로 출력 문제로 보였다. 2025년 8월부터 EBADBEEF와 몇 차례 의견을 주고받았지만(살펴봐 줘서 고맙다!), 원인을 찾지 못했다.
한 분기가 지난 뒤, 코딩 어시스턴트인 Claude Code(집필 시점에는 Opus 4.5)로 복잡한 이슈를 디버깅하면서 좋은 경험을 했기에 다시 한번 시도해 보기로 했다. 이틀에 걸쳐 여러 테스트를 실행하며 문제를 좁혀 나갔고, Claude가 sway, wlroots, Xorg, mesa 등의 소스 코드를 분석하고 직접 실행해 볼 수 있는 테스트 프로그램을 만들게 했다.
결국 Wayland와는 독립적인 최소 재현 프로그램을 만들었는데, 이를 통해 SRC_X DRM 속성이 nVidia에서는 동작하지 않지만(반면 Intel 등에서는 동작한다!) Intel에서는 동작한다는 것을 보여줄 수 있었다. nVidia 포럼에 영상과 함께 버그 리포트를 올렸으니, nVidia 엔지니어가 살펴봐 주길 기대한다!
중요한 것은, 이제 버그가 특정됐으니 Claude에게 우회 방법을 구현하게 했다는 점이다. 화면의 오른쪽 절반(SRC_X=3840 위치)을 다른 버퍼로 복사한 뒤, 그 버퍼를 SRC_X=0으로 해서 표시하는 방식이다.
그 패치를 적용하자 마침내 처음으로 8K 모니터에서 Sway를 사용할 수 있게 됐다! 🥳
참고로 GNOME이 네이티브 해상도를 성공적으로 설정한다고 해서 GNOME에서 모니터를 쓸 만하다는 뜻은 아니다! GNOME은 타일드 디스플레이를 지원하긴 하지만 개별 타일의 업데이트가 동기화되지 않아 화면 중앙에 심한 티어링이 발생하는데, X11에서 본 어떤 현상보다 훨씬 심하다. GNOME/mutter 머지 리퀘스트 !4822가 이 문제를 해결해주길 기대한다.
소프트웨어: NixOS
2025년 동안 나는 모든 컴퓨터를 NixOS로 옮겼다. 선언적인 접근 방식 덕분에 이런 테스트를 하기에 정말 좋았는데, 시스템을 이전 버전으로 안정적으로 되돌릴 수 있기 때문이다.
NixOS 25.11 설치에서 Wayland/sway 세션을 사용할 수 있게 하기 위해, NixOS 설정 파일(configuration.nix)에 다음 내용을 추가했다:
# GDM display manager (can launch both X11/i3 and Wayland/Sway sessions)
services.displayManager.gdm.enable = true;
services.displayManager.gdm.autoSuspend = false;
# enable GNOME (for testing)
services.desktopManager.gnome.enable = true;
programs.sway = {
enable = true;
wrapperFeatures.gtk = true;
extraOptions = [ "--unsupported-gpu" ];
};또한 environment.systemPackages에 다음과 같은 Wayland 전용 프로그램들을 추가했다:
environment.systemPackages = with pkgs; [
# …
foot # terminal emulator
wtype # replacement for xdotool type
fuzzel # fuzzy matching program starter
wayland-utils # for wayland-info(1)
gammastep # redshift replacement
];이 설정을 활성화하면 실행 중인 X11 세션이 있다면 종료된다는 점에 유의하자.
혹시 모르니 설정을 변경한 뒤 시스템 전체를 재부팅했다.
실험 결과
이 설정으로 Wayland 세션에서 꼬박 하루 정도 실제 업무를 해 보았다. 실제로 일을 해 보려 해야 가벼운 테스트에서는 드러나지 않는 문제들이 드러난다. 하루 대부분을 Wayland 문제를 고치는 데 썼다 😅. 아래 섹션들에서 알게 되거나 관찰한 내용을 정리한다.
데스크톱: i3 → sway
수년 전 Wayland가 더 유명해졌을 때, 사람들이 i3 이슈 트래커에서 i3를 Wayland로 포팅할 계획이 있냐고 물었다. 나는 아니라고 답했다. 내 컴퓨터 중 어느 것에서도 실행조차 되지 않는 환경에 어떻게 프로그램을 포팅하겠는가? 게다가 풀타임 직장을 다니면서 얼리 어답터가 되어 Wayland 개발을 이끌어 갈 시간도 없을 거라는 걸 알고 있었다.
이런 입장 때문에 2016년 무렵 Drew DeVault가 Sway 프로젝트를 시작했다. Sway는 i3의 Wayland 버전이라 할 수 있다. 나는 Sway를 경쟁자로 보지 않는다. 오히려 사람들이 i3 프로젝트를 그토록 좋아해서 다른 환경을 위해 비슷한 프로그램을 만드는 수고를 마다하지 않았다는 사실이 놀랍고 멋지게 느껴졌다! 정말 기분 좋은 칭찬이다! 😊
Sway는 i3 설정 파일과 호환되는 것을 목표로 하며, 대체로 그렇다.
궁금하다면, Sway 기본값에서 내가 변경한 내용은 다음과 같다. 주로 내가 사용하는 NEO 키보드 레이아웃에 맞춰 키 바인딩을 옮기고, 예전에 내 ~/.xsession 파일에서 설정하던 input/output 블록을 구성한 것이다:
Sway 기본 설정에서 내가 변경한 내용
--- /home/michael/src/sway/config.in 2025-09-24 19:08:38.876573260 +0200
+++ /home/michael/.config/sway/config 2025-12-31 15:50:38.616697542 +0100
@@ -9,19 +9,76 @@
# Logo key. Use Mod1 for Alt.
set $mod Mod4
# Home row direction keys, like vim
-set $left h
-set $down j
-set $up k
-set $right l
+set $left n
+set $down r
+set $up t
+set $right d
# Your preferred terminal emulator
set $term foot
# Your preferred application launcher
-set $menu wmenu-run
+set $menu fuzzel
+
+font pango:Bitstream Vera Sans Mono 8
+
+titlebar_padding 4 2
+
+# Make Xwayland windows recognizeable:
+for_window [shell="xwayland"] title_format "%title [Xwayland]"
+
+workspace_layout stacking
+
+# Open two terminal windows side-by-side on new workspaces:
+# https://github.com/stapelberg/workspace-populate-for-i3
+exec ~/go/bin/workspace-populate-for-i3
+
+exec gammastep -l 47.31:8.50 -b 0.9
+
+input * {
+ xkb_layout "de"
+ xkb_variant "neo"
repeat_delay 250
repeat_rate 30
+}
+
+input * {
+ accel_profile adaptive
+ pointer_accel 0.2
+}
### Output configuration
#
-# Default wallpaper (more resolutions are available in @datadir@/backgrounds/sway/)
-output * bg @datadir@/backgrounds/sway/Sway_Wallpaper_Blue_1920x1080.png fill
+output * bg /dev/null fill #333333
+output * scale 3
#
# Example configuration:
#
@@ -33,14 +90,41 @@
#
# Example configuration:
#
-# exec swayidle -w \
-# timeout 300 'swaylock -f -c 000000' \
-# timeout 600 'swaymsg "output * power off"' resume 'swaymsg "output * power on"' \
-# before-sleep 'swaylock -f -c 000000'
+exec swayidle -w \
+ before-sleep '~/swaylock.sh' \
+ lock '~/swaylock.sh'
#
# This will lock your screen after 300 seconds of inactivity, then turn off
# your displays after another 300 seconds, and turn your screens back on when
# resumed. It will also lock your screen before your computer goes to sleep.
+bindsym $mod+l exec loginctl lock-session
+
+ # Notifications
+ bindsym $mod+period exec dunstctl close
### Input configuration
#
@@ -63,11 +147,13 @@
# Start a terminal
bindsym $mod+Return exec $term
# Kill focused window
- bindsym $mod+Shift+q kill
+ bindsym $mod+Shift+x kill
# Start your launcher
- bindsym $mod+d exec $menu
+ bindsym $mod+a exec $menu
# Drag floating windows by holding down $mod and left mouse button.
# Resize them with right mouse button + $mod.
@@ -142,12 +228,11 @@
bindsym $mod+v splitv
# Switch the current container between different layout styles
- bindsym $mod+s layout stacking
+ bindsym $mod+i layout stacking
bindsym $mod+w layout tabbed
- bindsym $mod+e layout toggle split
# Make the current focus fullscreen
- bindsym $mod+f fullscreen
+ bindsym $mod+e fullscreen
# Toggle the current focus between tiling and floating mode
bindsym $mod+Shift+space floating toggle
@@ -156,7 +241,7 @@
bindsym $mod+space focus mode_toggle
# Move focus to the parent container
- bindsym $mod+a focus parent
+ bindsym $mod+u focus parent
#
# Scratchpad:
#
@@ -192,37 +277,25 @@
bindsym Return mode "default"
bindsym Escape mode "default"
}
-bindsym $mod+r mode "resize"
+#bindsym $mod+r mode "resize"
#
# Status Bar:
#
# Read `man 5 sway-bar` for more information about this section.
bar {
- position top
# When the status_command prints a new line to stdout, swaybar updates.
# The default just shows the current date and time.
- status_command while date +'%Y-%m-%d %X'; do sleep 1; done
+ status_command i3status
}Sway에서 다음과 같은 문제들을 겪었다:
예전에 쓰던 libinput 설정을 똑같이 어떻게 구성해야 할지 모르겠다. X11에서 사용하던 설정은
xinput-list-props-mx-ergo.txt를 참고하면 된다. Sway에서 제공하는accel_profile설정은 내가 예전에 쓰던 것과 일치하지 않는 것 같다.마우스 커서/포인터가 어쩐지 버벅이는 느낌이다?! 트랙볼을 움직였을 때 반응이 더 느리게 오는 것 같고, 화면을 가로지를 때도 덜 부드럽게 움직인다.
Simon Ser는 현재 nVidia 드라이버에서 하드웨어 커서 지원이 동작하지 않기 때문일 수 있다고 추측한다.
Xwayland 스케일링 미지원: Xwayland를 통해 실행된 프로그램은 흐릿하게 보이거나(기본값) 두 배로 확대되어 보인다(
Xft.dpi: 288설정 시). 이는 Sway 특유의 제약으로, KDE는 2022년에 이 문제를 해결했다. Sway 이슈 #2966을 보면 Sway 개발자들이 어떤 이유에서인지 이 방식을 별로 좋아하지 않는 것 같지만, 내 이주 관점에서는 매우 아쉽다. Xwayland로 오래된 프로그램을 실행하는 하위 호환 옵션이 사실상 쓸 수 없게 된다.가끔 키보드 단축키가 두 번 실행되는 것처럼 보인다! 예를 들어 스택에 있는 다섯 개의 Chrome 창 중 첫 번째에 포커스를 두고 그 창을 다른 워크스페이스로 옮기면, 한 개가 아니라 두 개의 창이 옮겨진다. 또한 다음과 같은 메시지도 보인다(비록 단축키 이중 실행 문제와 정확히 연관된 것은 아니지만):
[ERROR] [wlr] [libinput] event0 - https: kinT (kint36): client bug: event processing lagging behind by 32ms, your system is too slow…그리고 이건 뭔가 잘못됐다고 생각한다. 내 하이엔드 리눅스 PC가 느리다고 할 수는 전혀 없기 때문이다.
GTK: 글꼴 크기
GIMP나 Emacs 같은 GTK 프로그램을 처음 실행했을 때 모든 글꼴이 너무 크게 보였다! 아무래도 스케일링 관련 설정을 아직 갖고 있었고, 다음과 같이 초기화해야 했던 것 같다:
gsettings reset org.gnome.desktop.interface scaling-factor
gsettings reset org.gnome.desktop.interface text-scaling-factor디버깅 팁: GNOME 설정은 dconf dump / 명령으로 확인할 수 있다(~/.config/dconf에 저장됨).
GTK: 백엔드
geeqie 같은 일부 프로그램은 명시적으로 export GDK_BACKEND=wayland 환경 변수를 지정해야 하는 것 같고, 그렇지 않으면 Xwayland에서 실행된다. 이상하다.
글꼴 렌더링
X11과 Wayland 사이에서 글꼴 렌더링이 다르다는 것도 알게 됐다! 예를 들어 Chrome 브라우저 탭 제목이나 주소 표시줄에서 그 차이가 보인다:
처음에는 Wayland가 기본적으로 다른 font-antialiasing과 font-hinting 설정을 사용하나 보다 생각해, 다음 설정(기본값은 font-antialiasing=grayscale, font-hinting=slight)으로 여러 가지 실험을 해봤지만 예전처럼 렌더링되게 만들 수는 없었다:
gsettings set org.gnome.desktop.interface font-antialiasing 'rgba'
gsettings set org.gnome.desktop.interface font-hinting 'full'업데이트: Wayland에서는 GTK3가 ~/.config/gtk-3.0/settings.ini 설정 파일을 무시하고 dconf만 사용한다는 점을 알려준 Hugo에게 감사한다! 다음 dconf 설정을 지정하니 글꼴 렌더링이 일치하게 됐다:
gsettings set org.gnome.desktop.interface font-name 'Cantarell 11'화면 잠금: swaylock
두 프로그램의 아키텍처 차이를 금방 알게 됐다:
i3lock은 화면 잠금 창을 보여준다. i3lock을 종료하면 화면 잠금이 해제된다.
swaylock을 종료하면 Red Screen Of Death 상태가 된다.
이 상태에서 벗어나려면 swaylock을 다시 시작해 잠금을 해제해야 한다. 커맨드라인에서
swaylock프로세스에SIGUSR1을 보내 잠금을 해제할 수 있다.
이건 내게는 매우 놀라운 일이었지만, (Wayland) 설계상 의도된 동작이다! 자세한 내용은 Sway 이슈 #7046을 참고하고, ext-session-lock-v1 Wayland 프로토콜의 다음 인용을 보자:
“컴포지터는 렌더링을 중단하고 일반 클라이언트에 입력을 제공해서는 안 된다. 대신 컴포지터는 모든 출력을 불투명한 색상으로 가려 정상적인 내용이 완전히 숨겨지도록 해야 한다.”
그러니 테스트용으로 SSH를 통해 swaylock을 실행할 때는 Ctrl+C로 그냥 취소하지 말고 반드시 잠금을 해제해야 한다는 점을 기억하자. 그리고 절대로 충돌하지 않길 바라자.
예전에는 다음과 같은 래퍼 스크립트로 i3lock을 실행했는데, 모니터를 끄고(입력이 들어오면 다시 켜진다):
#!/bin/sh
# Turns on DPMS, mutes all output, locks the screen.
# Reverts all settings on unlock, or when killed.
revert() {
xset dpms 0 0 0
pactl set-sink-mute @DEFAULT_SINK@ 0
}
trap revert SIGHUP SIGINT SIGTERM
xset +dpms dpms 15 15 15
(sleep 1 && xset dpms force off) &
pactl set-sink-mute @DEFAULT_SINK@ 1
i3lock --raw 3840x2160:rgb --image ~/i3lock-wallpaper-3840x2160.rgb -n
revertWayland에서는 DPMS 동작을 swayidle을 이용해 다르게 구현해야 한다:
#!/bin/sh
# Turns on DPMS, mutes all output, locks the screen.
# Reverts all settings on unlock, or when killed.
swayidle -w \
timeout 5 'swaymsg "output * dpms off"' \
resume 'swaymsg "output * dpms on"' &
swayidle=$!
revert() {
kill $swayidle
pactl set-sink-mute @DEFAULT_SINK@ 0
}
trap revert SIGHUP SIGINT SIGTERM
pactl set-sink-mute @DEFAULT_SINK@ 1
swaylock --image ~/i3lock-wallpaper-3840x2160.jpg
reverti3 IPC 자동화
i3 윈도우 매니저는 IPC 인터페이스(프로세스 간 통신)를 통해 확장할 수 있다.
나는 이 인터페이스를 사용하는 작은 도구 몇 개를 쓰고 있다.
이 도구들을 Sway와 함께 사용하면서 다음과 같은 문제들을 발견했다:
go.i3wm.org/i3/v4Go 패키지를 사용하는 도구들은 현재 특별한 소켓 경로 훅이 필요하다. 전환을 쉽게 하려면 패키지에서 이 부분을 투명하게 처리하도록 포함해야 할 것이다.Sway 설정에서
exec로 시작한 도구들이 Sway를 종료(swaymsg exit)하고 새 세션에 로그인해도 예상과 달리 계속 실행된다!내 workspace-populate-for-i3가 동작하지 않았다:
- Sway는 i3의 레이아웃 저장/복원 기능을 구현하지 않는다. Drew가 2017년에 그 기능이 “얻는 이득에 비해 너무 복잡하고 편법적이다”라고 판단했기 때문이다. 아쉽다. 마음에 들던 레이아웃 몇 개를 다른 방식으로 다시 만들어야 한다.
- Sway는
[con_id]기준으로 워크스페이스 노드를 매칭하지 않는다. 이를 수정하기 위한 풀 리퀘스트 #8980이 있다(5일 전에 독립적으로 올라온 것).
내 wsmgr-for-i3는 부분적으로 동작했다:
- 워크스페이스 복원(
wsmgr restore)은 동작했다. - Sway의
rename workspace명령 구현은 대상 이름에서 워크스페이스 번호를 제대로 인식하지 못하는 것 같다.
- 워크스페이스 복원(
터미널: foot
X11에서는 rxvt-unicode(URxvt) 터미널 에뮬레이터를 사용한다. 빠르고 미니멀한 외관 외에도 포기하고 싶지 않은 편의 기능이 몇 가지 있다:
- 스크롤백(= 명령어 출력)에서의 역방향 검색
- 키보드 단축키로 스크롤백에 있는 URL 열기
- 같은 작업 디렉터리에서 새 터미널 창 열기
- 셸에서 터미널 제목 업데이트하기
이전 실험에서 Alacritty나 Kitty를 시도해 봤지만 어느 것도 만족스럽지 않았다.
anarcat의 블로그 글 “Wayland: i3 to Sway migration” 덕분에 foot 터미널 에뮬레이터를 알게 됐는데, 정말 괜찮은 선택지로 보인다!
foot.ini 설정 파일을 URxvt 설정에 맞춰 만들기 시작했지만, 나중에 일부 색상이 일치하지 않는 것 같다는 걸 알게 됐다(녹색/빨간색 배경의 일부 텍스트 줄이 다르게 보였다). 왜 그런지는 아직 모르겠고 더 자세히 살펴보지는 않았다.
foot을 사용하면서 다음과 같은 문제들을 발견했다:
Ctrl+Enter를 누르면(실수로 꽤 자주 누르는 것 같다) 이스케이프 시퀀스가 입력되는데, URxvt는 Ctrl+Enter를 그냥 Enter처럼 처리한다.
이는 셸(Zsh의 경우)에서 우회할 수 있다. 자세한 내용은 foot 이슈 #628을 참고하자.
마우스로 URL 일부를 더블클릭하면 URL이 선택되긴 하지만(예상대로)
https:스킴 접두사 없이 선택된다! 마우스를 쓰고 싶을 때는 꽤 성가시다.Ctrl을 누르고 있으면 이 문제를 우회할 수 있는데, 그러면
foot이 포인터 아래에 있는 내용을 다음 공백 문자까지 모두 선택한다.screen(1)을foot에서 실행하면screen세션 안에서 실행되는 프로그램에서 색상 지원이 되지 않는다. 아마도 terminfo 관련 문제인 것 같다…? GNOME 터미널에서도 같은 문제를 재현할 수 있다. 하지만 URxvt나 xterm에서는 잘 동작한다.텍스트를 선택하면 줄 전체가 아니라 줄 안의 텍스트만 하이라이트된다. 내가 익숙한 다른 터미널 에뮬레이터와는 다른 동작이지만, 이를 바꿀 수 있는 옵션은 보이지 않는다.
다음은 “kthreadd” 오른쪽을 트리플 클릭한 뒤의
foot스크린샷이다:
하지만 echo 출력 줄을 트리플 클릭하면 전체 줄이 아니라 내용만 하이라이트된다:
텍스트 에디터: Emacs
Emacs의 Wayland 지원은 꽤 실망스럽다. 표준 Emacs 버전은 X11만 지원하므로 Sway에서는 Xwayland로 실행된다. Sway가 Xwayland에서의 스케일링을 지원하지 않기 때문에 Emacs가 흐릿하게 보인다(위/배경 창):
네이티브 Wayland 지원(아래/전경 창)은 pgtk 버전의 Emacs(NixOS에서는 emacs-pgtk)에서만 제공된다. pgtk는 원래 별도 브랜치였지만 Emacs 29(2023년 7월)에서 병합됐다. X11에서 pgtk에는 문제가 있는 것으로 보인다(X11에서 Emacs-pgtk를 실행하면 경고가 나온다). 그래서 당분간은 두 개의 별도 버전이 있어야 한다…
안타깝게도 pgtk의 텍스트 렌더링은 네이티브 X11 텍스트 렌더링과 다르게 보인다! 줄 높이와 글자 간격이 다른 것 같다:
왜 다른지는 모르겠다! 예전 동작과 똑같이 만드는 방법을 아는 사람이 있을까?
다른 텍스트 렌더링 외에도 내게 가장 큰 문제는 입력 지연이다. Emacs-pgtk는 Emacs보다 확연히 느리게(반응이 둔하게) 느껴진다. Reddit에서 여러 번 보고됐고(스레드 1, 스레드 2) Emacs 버그 #71591로도 보고됐지만, 별다른 해결책은 없는 것 같다.
Emacs를 원격으로 실행하는 방법도 찾아야 한다. 지금까지는 SSH를 통한 X11 포워딩을 사용해 왔는데(광케이블 연결에서는 잘 동작하고 지연도 낮다). waypipe를 한번 살펴봐야 할 것 같은데 아직 기회가 없었다.
브라우저: Chrome
Chrome을 실행해 chrome://gpu 디버그 페이지를 확인하면 상태가 좋아 보인다:
하지만 브라우저 창을 옮기거나 크기를 조절한 뒤 얼마 지나지 않아 GPU 프로세스가 다음과 같은 메시지와 함께 죽고, 예를 들어 WebGL이 더 이상 하드웨어 가속되지 않는다:
ERROR:ui/ozone/platform/wayland/gpu/gbm_pixmap_wayland.cc:95] Cannot create bo with format=RGBA_8888 and usage=Scanout|Rendering|Texturing
ERROR:ui/gfx/linux/gbm_wrapper.cc:405] Failed to create BO with modifiers: Invalid argument (22)
ERROR:ui/ozone/platform/wayland/gpu/gbm_pixmap_wayland.cc:95] Cannot create bo with format=RGBA_8888 and usage=Texturing
ERROR:gpu/command_buffer/service/shared_image/shared_image_factory.cc:981] CreateSharedImage: could not create backing.
ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:397] SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
ERROR:components/viz/service/gl/exit_code.cc:13] Restarting GPU process due to unrecoverable error. Context was lost.
R:gpu/ipc/client/command_buffer_proxy_impl.cc:321] GPU state invalid after WaitForGetOffsetInRange.
ERROR:content/browser/gpu/gpu_process_host.cc:1005] GPU process exited unexpectedly: exit_code=8704물론 하드웨어 가속 없이 브라우저를 사용하는 것은, 특히 고해상도에서는 매우 답답하다. Chrome을 --disable-gpu-compositing 옵션으로 실행하면 GPU 프로세스가 종료되는 문제는 우회되는 것 같지만, 여전히 X11에서만큼 부드럽게 느껴지지는 않는다.
내게 또 다른 큰 문제는 Sway가 Chrome 창을 닫았던 워크스페이스에서 다시 열어 주지 않는다는 점이다. _NET_WM_DESKTOP EWMH 아톰을 추적하고 복원하는 지원은 i3에 2016년 1월에, Chrome에 2016년 5월에, Firefox에 2020년 3월에 추가됐다.
나는 보통 5개 이상의 워크스페이스와 그보다 더 많은 Chrome 창을 동시에 열어 두기 때문에, 매일(업무용 컴퓨터를 부팅할 때) 10개가 넘는 Chrome 창을 일일이 정리해야 하는 것은 매우 성가시다.
Simon Ser는 이 문제가 새로운 Wayland 프로토콜(xdg-session-management, 머지 리퀘스트 !18)로 해결될 것이라고 말했다.
화면 공유
나는 원격 근무를 많이 하기 때문에 화면 공유는 기본 중의 기본 기능이다. 거의 매일 브라우저에서 다양한 시나리오와 요구사항으로 화면 공유를 사용한다.
X11에서는 Chrome에서 다음과 같은 경험을 하는 데 익숙하다. “Window” 탭을 클릭하면 내 창들의 미리보기가 보인다. 창을 선택하고 확인하면 그 창의 내용이 공유된다:
Wayland/sway에서 화면 공유를 동작하게 하려면 xdg-desktop-portal과 xdg-desktop-portal-wlr(후자는 sway가 사용하는 wlroots 전용)을 설치해야 한다.
이 패키지들을 설치한 상태에서 내가 본 동작은 다음과 같다:
- Chrome 탭을 공유할 수 있다.
- 전체 모니터를 공유할 수 있다.
- 특정 창을 공유할 수 없다(전체 모니터가 하나의 창으로 나타난다).
이는 xdg-desktop-portal-wlr(및 다른 포털)의 제약으로, upcoming Sway 1.12 릴리스에서 해결될 예정이다.
직접 시험해 보려고 NixOS 설정을 git 버전의 sway와 wlroots를 사용하도록 변경했다. “Window” 탭을 클릭하면 창을 선택해야 하는 선택 창이 나타난다:
창을 선택한 뒤에는 Chrome에서 그 창의 내용만 미리보기로 보인다:
확인한 뒤에는 또 다른 선택 창이 나타나 창을 다시 선택해야 한다. 주목할 점은 두 번째 단계에서 미리본 창과 선택한 창 사이에 아무런 연결이 없다는 것이다. 다른 창을 선택하면 그 창이 공유된다:
이제 그 창이 화면 공유된다(그러니까 기능 자체는 이제 동작한다. 좋다!), 하지만 아쉽게도 낮은 해상도로 공유되어 동료들에게는 텍스트가 흐릿하게 보인다.
이 문제를 xdg-desktop-portal-wlr 이슈 #364로 보고했는데, 잘못된 스케일 팩터가 적용되는 것이 원인인 것 같다. 이슈에 제공된 패치는 내 환경에서는 잘 동작한다.
하지만 큰 그림에서 보면 전체 흐름 자체가 잘못된 것 같다. Chrome의 “Window” 탭을 클릭했을 때 별도의 선택 창이 뜨면 안 된다. 모든 창의 미리보기가 보여야 하고, 별도의 선택 창이 아니라 Chrome 안에서 창을 선택할 수 있어야 한다.
스케일링 글리치
출력 스케일링을 활성화했을 때 매우 성가신 글리치도 발견했다. 창 사이(탭 또는 스택 컨테이너 안)나 워크스페이스 사이를 전환할 때 (일부!) 창의 내용이 “이리저리 튀는” 현상이었다.
이 현상을 처음 발견한 곳은 foot 터미널 에뮬레이터였는데, 동작은 다음과 같다:
- 워크스페이스를 변경하거나 스택 또는 탭 컨테이너 안에서 포커스를 전환해 다른
foot터미널로 포커스를 옮긴다. - 새
foot터미널이 텍스트 내용이 약간 어긋난 상태로 나타난다. - 몇 밀리초 안에
foot의 텍스트가 올바른 위치로 튀어 오른다.
이 창으로 포커스를 옮긴 직후, 내용이 몇 픽셀 움직이는 순간을 iPhone으로 촬영했다:
나중에는 Chrome 창도 전환 직후 잠시 흐릿하게 보이는 현상을 발견했다.
내 추측으로는 Sway가 보이지 않는 창에 대해서는 스케일 팩터를 1로 설정하기 때문에, 포커스를 전환할 때 애플리케이션이 scale-3 콘텐츠 버퍼를 제공할 때까지 scale-1 콘텐츠 버퍼가 보이는 것 같다.
알림: dunst
dunst는 Wayland를 네이티브로 지원한다. dunst 1.13을 써 봤는데 별다른 문제는 발견하지 못했다.
피커: rofi
rofi는 v2.0.0(2025-09-01)부터 Wayland에서 동작한다.
나는 Emoji 피커로 rofi와 rofimoji를 함께 사용한다. 텍스트 입력은 xdotool 대신 wtype이 동작하는 것 같다. 별다른 문제는 느끼지 못했다.
스크린샷: grim?
평소에 사용하던 maim(1) 대신 grim(1)을 시도해 봤지만, 아쉽게도 캡처할 창을 선택하는 grim의 -T 플래그는 사용하기 꽤 번거롭고(1배 스케일로 캡처된다).
혹시 좋은 대안을 아는 분이 있을까?
결론
마침내 내 환경에서 Wayland 세션을 동작시키는 데 어느 정도 진전을 이뤘다!
이번 Wayland/sway 실험에 대한 판정을 내리기 전에, X11/i3에서의 내 경험이 정말 좋다는 점을 먼저 설명하고 싶다. 일상적인 컴퓨터 사용에서 티어링이나 다른 아티팩트, 글리치를 전혀 보지 못한다. 컴포지터를 사용하지 않기 때문에 입력 지연도 매우 좋다. 한 번은 직접 만든 키보드로 X11의 Emacs에서 약 763μs 정도로 측정된 적이 있다(출력 지연 제외), kinX: latency measurement(2018) 글을 참고하자.
그래서 내 관점에서는 기존의 완벽하게 동작하는 스택(내 기준)에서 Sway로 옮기는 것은 단점뿐이다. 이전에는 없던 새로운 그래픽 글리치가 보인다. 가장 많은 시간을 보내는 프로그램(Chrome과 Emacs)이 눈에 띄게 더 나빠졌다. 구현이 다르거나 아예 프로그램을 교체해야 하기 때문에 수많은 새로운 버그를 마주하게 된다.
처음으로 Wayland 경험이 X11과 대등한 수준에 도달할 수 있어 보이지만, 현실적으로는 아직 몇 주, 심지어 몇 달의 작업이 더 필요할 것이다. 내 경험상 디버깅 세션은 그래픽 카드를 교체하고 모니터 배선을 다시 해야 버그를 좁힐 수 있어 금방 몇 시간이 걸린다. 안타깝게도 수많은 이슈를 고치는 데 기여할 시간이 별로 없으므로, 당분간은 X11/i3를 계속 사용할 생각이다.
내게 Wayland/Sway 세션이 데일리 드라이버로 준비됐다고 할 수 있는 조건은 다음과 같다:
- Sway가 더 이상 가끔 일부 키 바인딩을 두 번 실행하지 않을 때(“유령 키 입력”)
- Sway에서 창이나 워크스페이스 사이를 전환할 때 글리치가 더 이상 보이지 않을 때.
- Chrome이 지속적으로 하드웨어 가속될 때.
- Chrome 창이 시작될 때 이전 워크스페이스로 복원될 때.
- Emacs가 다음 중 하나를 만족할 때:
- Xwayland를 통해 실행되면서 Sway가 스케일링을 제대로 지원하거나,
- 혹은 pgtk 변형이 입력 지연 문제를 해결하고 어떻게든 예전과 동일하게 텍스트를 렌더링하게 될 때.
댓글
로그인하고 댓글 남기기