리눅스 Wayland 의 우울한 미래
Fri, Jun 7 2019 00:20:00 KST안녕하세요.
요새 웨이랜드 때문에 스트레스를 좀 받고 있습니다.
데비안 Buster 에서 GNOME 3 의 기본 세션이 Wayland 라고 합니다.
https://wiki.debian.org/NewInBuster
Wayland is the default session type for GNOME 3.
무슨 말이냐면 기존에는 GNOME 이 x11 위에서 돌아갔는데, Buster 에서는 GNOME 이 wayland 위에서
돌아가도록 기본값으로 설정한다는 얘기입니다. 어차피 로그인할 때 xorg 세션에도 돌아가는 메뉴를 선택해서
사용하면 되니까 별 상관 없긴 합니다.
웨이랜드가 나온지가 10년 정도 되었습니다. 영문 위키 백과 참고
Wayland_(display_server_protocol)
다행히 각종 배포판에서는 Xwayland 로 x11, wayland 동시에 지원합니다.
그런데 이게 참 거시기한 문제가 있는데, 다음을 보시죠.
GTK_WINDOW_POPUP works differently in x11 and wayland.
https://gitlab.gnome.org/GNOME/gtk/issues/1934
gtk_window_new (GTK_WINDOW_POPUP)
으로 만든 윈도우가 x11 에서는 초점을 받지 않는데,
wayland 에서는 초점을 받습니다. 이러한 문제 때문에 오작동이 발생하는 어플이 있습니다.
geany 에서 중국어, 일본어를 입력할 때 geany 가 편집기에 preedit 를 보여주는 윈도우를 그려주는데 그게 x11 에서는 초점을 받지 않아서 정상적으로 입력할 수 있는데, wayland 에서는 초점을 받아서 reset 되어 버려서 중국어, 일본어를 입력할 수 없습니다. 이상하게도 한글은 입력 되더군요. 아마 한국어, 중국어/일본어 코드 별로 preedit string 을 편집기에 그리는 방법이 다른 것 같습니다.
nimf 에서는 gtk_window_new (GTK_WINDOW_POPUP)
로 candidate window, preedit window
를 그려주는데 그게 x11 에서는 정상 작동하고, wayland 에서는 초점을 받아서 자꾸 reset 되어버립니다.
ㅠㅠ
그래서 2017년 쯤인가.. 할 수 없이 GDK_BACKEND="x11"
옵션을 넣어서 사용하고 있죠. 제가 제대로 아는
툴킷이 gtk 밖에 없습니다. ㅠㅠ 다른 툴킷 공부할 시간이 없음.
언젠가 순수 wayland 환경이 되면 저런 꼼수가 통하지 않으니 그때 되면 또 다른 방법을 모색해봐야겠죠.
wayland 가 처음에 나올 때 참 거창하게 나왔는데, 지금 생각해보니 거창한게 아니라 거만한거였네요.
나온지 10년 정도 되었는데 x11 vs wayland 2019년 벤치마크를 보면 속도 차이가 거의 없습니다.
https://www.phoronix.com/scan.php?page=news_item&px=Fedora-30-Xorg-vs-Wayland
데비안 Buster 에서 wayland + GNOME 조합에서 저는 오히려 wayland 가 느리게 느껴집니다.
스크롤 버벅 거리고, 마우스 움직임이 버벅 거립니다. 반면 xorg + GNOME 조합에서는 부드럽습니다.
동영상을 재생해보더라도 xorg + GNOME 조합이 더 부드럽게 돌아갑니다.
그리고 가상 머신에 우분투 19.04 설치해서 wayland + ubuntu 조합해서 사용해봤더니 속도 개느리고 렌더링이 제대로 되지 않아 글자가 부분적으로 흐리게 보이더군요. 헐. 반면 xorg + ubuntu 조합에서는 부분적으로 렌더링 되는 부분 없이 정상적으로 보입니다.
이 정도면 wayland 망했다고 볼 수 있나요? 그냥 폭망했으면 좋겠습니다.
ibus 도 참 안습인데 여러 배포판에 기본 입력기로 탑재하고 GNOME 에 통합하려는 노력을 아직도 하는데, 그런
미친 짓 좀 안 했으면 좋겠습니다.
ibus 사례를 볼 때, ibus 가 설계상에 오류가 있고, 품질이 개떡같아도 폐기하지 않는 것처럼 wayland 또는
wayland backend 품질이 아무리 개떡같더라도 폐기하지 않고 리눅스 진영에서 ibus, wayland 를 열심히
밀어줘서 여러 개발자/사용자들 열폭하게 만들 것이라 확신합니다.
개떡같은 ibus, wayland 이제는 제발 실패를 인정하고 폐기했으면 좋겠습니다.
차라리 리눅스 데스크탑 개나 줘버리는게 더 좋을 듯.
여기 2019년 벤치마크 결과를 보면 wayland 나 xorg 나 오십보 백보인데 오히려 xorg 가 약간 빠릅니다.
사실 차이가 미미해서 의미가 없습니다.
https://openbenchmarking.org/result/1905024-HV-FEDORA30D09&obr_sgm=y
여기 보면 이런 내용이 나오는데, 좀 충격적이네요.
Windows, Android, Mac OS X 도 이런 방법으로 작동한다고 하는거 같은데, 리눅스의 경우는 골때리는게,
입력 방법 input method api 만 보더라도 gtk, qt, xim, wayland 가 제각각이지요.
통합 입력 api가 없기 때문에 우리가 입력 문제를 겪는 거에요. 파편화 문제.
리눅스 데스크탑/그래픽도 통합 api 이런 게 없어 파편화될 가능성이 보이네요. 지금도 파편화되어 불편하지만, 앞으로 더 심화될 듯. gtk, qt, wxwidget 등이 각각의 dpi 와 각각의 폰트 렌더링을 수행한다면 참 짜증 폭발하겠죠. 뭐 지금도 마찬가지만.
https://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html#wayland
!! Applications (GUI toolkits) must implement their own font antialiasing - there’s no API for setting system-wide font rendering. Most sane and advanced windowing systems work exactly this way - Windows, Android, Mac OS X. In Wayland all clients (read applications) are totally independent.
!! Applications (GUI toolkits) must implement their own DPI scaling. The above issues are actually the result of not having one unified graphical toolkit/API (and Wayland developers will not implement it). Alas, no one is currently working towards making existing toolkits share one common configuration for setting font antialiasing, DPI scaling and windows shadowing. At least in theory these issues can be easily solved, in practice we already have three independent toolkits for Wayland (GTK3/Qt5/Enlightenment).
xorg, wayland 둘다 속도도 비슷비슷하고(오히려 wayland 가 조금 더 느림), 불편한 것도 비슷비슷하지만,
xorg 보다 불안한 wayland 라는 뻘짓 왜 하고 있는 건지 도무지 이해가 되지 않습니다.
Mir 마냥 폭망했으면 좋겠습니다.
wayland 나온지 10년 정도 되었습니다. 앞으로 10년이 더 흘러도 이 모양일 거라는 거 예상합니다.
ibus 보십시오. 그거 나온지 10년이 넘어도 한글 입력 버그 아직까지도 해결하지 못 했더군요.
wayland 말고 다른 뭔가가 나와서 그게 앞으로의 리눅스 데스크탑을 이끌어 갔으면 좋겠네요.
아니면 GNOME 프로젝트가 주축이 되어 이끌어 가던가.
리눅스 데스크탑 환경은 MS 윈도우, Mac OS, 안드로이드 환경이랑은 다릅니다.
MS 윈도우, Mac OS, 안드로이드 환경은 거의 단일에 가까운 환경이고,
리눅스 데스크탑 환경은 잘게 파편화되어 있는 상태이고 그러한 문제들 때문에 개발자/사용자들이 지금까지도
골탕먹고 있는 환경입니다. 이러한 리눅스 데스크탑 환경을 통합하지는 못할 망정 wayland 라는 것을 들고 나와
10년의 세월이 흘렀지만 실제 나아진 것이 없습니다.
wayland 가 성공하든 실패하든 리눅스 데스크탑 환경의 편의성과는 관련이 없습니다.
옛날에 유닉스 시절에 CDE (공통 데스크탑 환경 Common Desktop Environment) 라는게 나왔었는데,
리눅스 데스크탑에도 이런게 좀 나왔으면 좋겠네요. freedesktop 이라고 이미 있긴 하지만. 아휴.. 그냥 한숨
밖에 안 나옵니다.
일단 버그 보그를 해 놓았습니다.
만약 순수 wayland 환경이라면 CJK 사용자들은 리눅스 데스크탑 사용을 포기해야 할 정도로 매우 심각한
버그입니다. 관심을 가져 주시기 바랍니다.
GTK_WINDOW_POPUP works differently in x11 and wayland.
https://gitlab.gnome.org/GNOME/gtk/issues/1934
다행히 Xwayland 가 x11, wayland 어플을 돌릴 수 있기 때문에
GDK_BACKEND="x11" onboard
이런 식으로 사용하는 것이 가능합니다.
onboard 는 화상 키보드(on-screen keyboard)입니다. 위에처럼 했을 경우 초점을 가지지 않습니다만
wayland 환경에서 오작동하는군요.
nimf 는 candidate window (중국어, 일본어, 한자 등을 표현하는 창), preedit window (X 어플에서
조합 글자를 표시하지 않는 경우, 입력기가 조합 글자를 표시하는데에 사용하는 창)에
gtk_window_new (GTK_WINDOW_POPUP)
을 사용합니다. wayland backend 에서는 초점을 가지기
때문에 오작동하므로 nimf.c
소스코드에
g_setenv ("GDK_BACKEND", "x11", TRUE);
를 넣었습니다. x11 과 wayland 를 동시 지원하는 Xwayland 가 가동되는 환경에서는 정상 작동하지만, weston 에서는 오작동합니다.
수년전에 이 문제 때문에 fcitx 소스코드를 살펴본 적이 있었는데, fcitx 는 XCreateSimpleWindow
를
사용합니다. 따라서 Xwayland 환경에서는 정상 작동하지만 weston 환경에서는 오작동할 것으로 보입니다.
이 버그는 CJK 사용자가 wayland 환경에서 리눅스 데스크탑을 더 이상 사용할 수 없게 만드는 매우 심각한
버그입니다. 이 버그가 해결되지 않으면 CJK 사용자들은 리눅스 데스크탑을 버려야만 합니다.
절대 과장이 아니며 구라가 아닙니다. 이 버그가 해결될 때까지 wayland 사용을 보류해야 합니다.
이쯤되면 wayland 개발자들은 리눅스 안티가 아닌가.. 그런 생각이 듭니다. ㅋㅋㅋ