2 poin oleh GN⁺ 2026-01-05 | 1 komentar | Bagikan ke WhatsApp
  • Wayland adalah stack grafis penerus X11 yang dimulai pada 2008, tetapi penulis menilai selama 18 tahun ia belum bisa menggunakannya dengan layak di sistemnya sendiri
  • Per 2025, dukungan GBM dan explicit sync pada driver nVidia membuat eksekusi dasar menjadi memungkinkan, tetapi perpindahan penuh masih sulit karena masalah seperti belum adanya dukungan TILE untuk monitor 8K
  • Ada kemajuan teknis penting di Sway 1.11 dan wlroots 0.19.0, tetapi masih ada banyak hambatan penggunaan nyata seperti latensi input, glitch grafis, dan masalah scaling Xwayland
  • Aplikasi utama seperti Chrome dan Emacs masih menunjukkan masalah seperti penurunan performa, perbedaan rendering, dan ketidakstabilan akselerasi hardware
  • Secara umum, Wayland “akhirnya mulai mendekati layak pakai sehari-hari”, tetapi untuk pekerjaan harian kombinasi X11/i3 masih lebih stabil

Latar belakang historis Wayland

  • Wayland adalah proyek penerus X server (X11, Xorg) yang dimulai pada 2008, dan penulis mengembangkan manajer jendela tiling i3 untuk X11 pada 2009
  • Pada awalnya hanya compositor demo Weston yang bisa dijalankan, lalu GNOME pada 2014, dan setelah itu KDE mulai mendukung Wayland
  • Aplikasi utama seperti Firefox, Chrome, Emacs hanya bisa memakai Wayland melalui flag eksperimental
  • GPU nVidia dalam waktu lama tidak berjalan di Wayland atau memunculkan error grafis, dan masalah kompatibilitas monitor 8K juga terus berlanjut
  • Belakangan ini distro utama seperti Fedora, RHEL, Asahi Linux mengadopsi Wayland sebagai stack desktop bawaan atau satu-satunya, sehingga tekanan untuk beralih makin besar

Menyusun lingkungan eksekusi Wayland

  • Sistem uji memakai nVidia RTX 4070 Ti (PC lab) dan RTX 3060 Ti (PC utama)
  • Dukungan GBM ditambahkan mulai driver nVidia 495 (2021), dan fitur explicit sync diimplementasikan pada Sway 1.11 (2025) dan wlroots 0.19.0
  • Namun karena tidak ada dukungan untuk properti TILE pada monitor 8K Dell UP3218K, di Sway layar ditampilkan terbelah menjadi dua
    • Melalui patch dari EBADBEEF dan analisis Claude Code, ditemukan bug properti SRC_X DRM, lalu dengan patch workaround tampilan layar penuh berhasil dicapai
  • GNOME mendukung TILE, tetapi muncul tearing parah di tengah layar
  • Di lingkungan NixOS 25.11, penulis menyiapkan GDM, GNOME, dan Sway secara paralel, lalu menambahkan tool khusus Wayland seperti foot, fuzzel, dan wayland-utils

Hasil eksperimen: lingkungan Sway

  • Sway kompatibel dengan sebagian besar konfigurasi i3, dan penulis menyesuaikan layout keyboard NEO serta pengaturan input dan output
  • Masalah utama:
    • Pointer mouse terlambat dan gerakannya tidak mulus (diduga karena tidak adanya dukungan hardware cursor nVidia)
    • Aplikasi Xwayland tidak bisa di-scaling, sehingga tampil buram atau mengalami pembesaran ganda
    • Sebagian shortcut mengalami eksekusi ganda (ghost key press)
  • Pada aplikasi GTK, masalah awal ukuran font yang terlalu besar diselesaikan dengan gsettings reset
  • Karena GTK3 hanya memakai pengaturan dconf, font-name harus ditetapkan lewat dconf agar rendering konsisten
  • swaylock, tidak seperti i3lock, masuk ke status “layar merah” saat keluar dan hanya bisa dilepas dengan SIGUSR1
  • Tool otomasi berbasis i3 IPC hanya kompatibel sebagian karena perbedaan path socket, proses yang tetap tertinggal, dan tidak adanya dukungan pemulihan layout

Pengujian aplikasi utama

  • foot terminal ringan, tetapi ditemukan beberapa masalah seperti perbedaan warna, penanganan Ctrl+Enter, pemilihan URL, dan masalah warna pada screen
  • Emacs versi bawaan berjalan di Xwayland sehingga tampil buram, sedangkan versi pgtk memiliki latensi input dan perbedaan jarak huruf
  • Chrome menghentikan akselerasi hardware karena crash pada proses GPU, dan saat pemulihan jendela informasi workspace sebelumnya tidak dipertahankan
  • Screen sharing dimungkinkan melalui xdg-desktop-portal-wlr, tetapi ada masalah seperti tidak adanya dukungan berbagi per jendela dan transmisi resolusi rendah
  • Saat output scaling diaktifkan, muncul glitch ketika isi jendela sesaat bergeser atau menjadi buram
  • Notifikasi dunst dan rofi (2.0.0 ke atas) bekerja normal, sedangkan tool screenshot grim terasa kurang nyaman untuk pemilihan jendela

Kesimpulan: kemungkinan memakai Wayland pada 2026

  • Sesi Wayland/Sway untuk pertama kalinya mendekati tingkat yang layak dipakai, tetapi masih ada banyak cacat
  • Lingkungan X11/i3 memberikan latensi input rendah di kisaran 763μs dan stabilitas sempurna
  • Saat beralih ke Wayland, muncul glitch grafis, latensi input, dan penurunan performa aplikasi utama
  • Syarat yang dibutuhkan untuk pemakaian harian:
    • Penyelesaian input tombol ganda dan glitch perpindahan di Sway
    • Stabilisasi akselerasi hardware Chrome dan dukungan pemulihan jendela
    • Perbaikan latensi input dan rendering pada Emacs (pgtk)
  • Kesimpulannya, Wayland masih belum siap untuk pekerjaan harian, dan penulis berencana tetap memakai X11/i3

1 komentar

 
GN⁺ 2026-01-05
Komentar Hacker News
  • Wayland hanyalah sebuah protokol, jadi ada banyak implementasi berbeda (GNOME, KDE, wlroots, dll.)
    Xorg punya struktur di mana desktop dibangun di atas satu fondasi yang kokoh, tetapi di Wayland tiap desktop pada dasarnya seperti menciptakan ulang rodanya sendiri
    Weston bagus sebagai referensi, tetapi tidak cocok untuk penggunaan sehari-hari
    Menurut saya, yang dibutuhkan adalah pustaka standar yang bisa dipakai bersama oleh semua desktop. wlroots menargetkan peran itu, tetapi GNOME atau KDE tampaknya tidak akan segera pindah
    • Saya rasa X.org memilih tingkat abstraksi yang tepat. WM tidak perlu menangani input atau output secara langsung, dan berkat itu kesederhanaan serta efisiensi dayanya bagus. Wayland pada dasarnya gagal belajar dari pelajaran X11
    • Saya pernah memakai Sway dan Hyprland, dan sekarang niri. Sway dan niri yang berbasis wlroots cukup bagus, tetapi tetap ada banyak bug acak. Masalah pointer di aplikasi Wine, crash saat screen sharing, masalah warna 10-bit, dan sebagainya. Mungkin akan stabil sekitar 2027, tetapi untuk pengembangan selama 20 tahun, rasanya tidak efisien
    • KDE dan GNOME masing-masing punya implementasi xdg-desktop-portal sendiri, sehingga menimbulkan masalah kompatibilitas. Jika berbasis wlroots maka harus memakai xdg-desktop-portal-wlr, sedangkan untuk Hyprland harus memakai xdg-desktop-portal-hyprland.
      Struktur Wayland sendiri memang tampak bagus secara teori seperti di dokumen arsitektur resmi, tetapi dalam praktiknya masih banyak fitur yang hilang di tingkat protokol
    • Sebenarnya X juga sebuah protokol, tetapi karena ada implementasi tunggal bernama X.org, kebingungannya lebih sedikit. Secara teknis bukan hal mustahil untuk punya satu pustaka yang distandardisasi di level wlroots
    • Pengembang Wayland awalnya merancangnya sebagai protokol khusus display. Mereka berharap protokol input atau manajemen jendela akan dibuat oleh kelompok terpisah, tetapi itu tidak berjalan baik.
      Upaya menggantikan Wayland sekarang pada akhirnya bisa menjadi pemborosan karena hanya mengulang bagian-bagian yang sebenarnya sudah matang
  • Saya masih belum tahu alasan kenapa harus memakai Wayland. Xorg itu stabil, dan kebanyakan tulisan pemecahan masalah juga dimulai dengan “kalau pakai Wayland, kembali saja ke Xorg”.
    Mungkin adopsi serius baru akan meningkat ketika distro memaksanya jadi default seperti systemd dulu
    • Pengguna biasa memang tidak punya alasan kuat untuk pindah. Tapi Wayland menangani hal yang lemah di X11 seperti penskalaan multi-display dengan baik.
      Dari sudut pandang GNOME dan KDE, dorongan pindah ke Wayland juga besar karena ingin mengurangi beban pemeliharaan X11.
      Menurut saya target tahun ini adalah mencapai level “tanpa kekurangan yang berarti”
    • Wayland terasa memberi performa yang lebih mulus, tetapi saya tetap harus memakai Xorg karena beberapa aplikasi.
      GNOME 49 di Arch dan Ubuntu sudah menghapus Xorg dari pilihan default, dan KDE kemungkinan akan segera menyusul. Era Xorg memang sedang berakhir
    • Dulu saya harus mengedit xorg.conf secara manual, tetapi setelah mencoba Wayland secara eksperimental di Ubuntu, saya pindah sepenuhnya. Mungkin karena GPU AMD, semuanya mulus tanpa masalah
    • Kelebihan Wayland adalah fractional scaling
    • Saya perlu memakai alat seperti x2x, xev, dan xdotool, tetapi itu tidak mungkin karena model keamanan Wayland, jadi saya tetap di Xorg
  • Anggapan bahwa Nvidia menolak GBM API Wayland adalah salah paham. GBM adalah API tidak resmi di dalam Mesa, jadi Nvidia tidak bisa mengimplementasikannya secara langsung.
    Karena itu mereka mengusulkan alternatif netral-vendor bernama EGLStreams.
    Justru masalahnya adalah pihak freedesktop tidak menyediakan struktur yang memungkinkan driver Nvidia bekerja
    • Tapi saya tetap heran bagaimana Mesa sebagai proyek open source bisa bergantung pada API tertutup
  • Saya sudah bertahun-tahun memakai Wayland di Gnome dan tidak punya masalah sama sekali.
    Tentu mungkin karena perangkat keras saya sederhana dan bukan Nvidia, tetapi saya ingin menekankan bahwa Wayland memang bisa bekerja dengan baik
    • Saya juga sama, di Sway (2016) dan KDE Plasma 6 semuanya berjalan sempurna. Hanya game Steam yang saya jalankan lewat XWayland. Kombinasi AMD/Intel jauh lebih stabil
    • Bahkan di perangkat Nvidia, belakangan ini juga berjalan cukup mulus. Dulu tersendat-sendat, tetapi sekarang rasanya lebih baik daripada Xorg.
      Hanya saja fitur seperti kontrol posisi jendela atau menjelajah aplikasi lain masih harus disiasati dengan Gnome Shell Extension
    • Seperti kisah orang yang dulu tidak merasa terganggu oleh kedipan monitor CRT, ketidaknyamanan kecil seperti rasa input yang sedikit berbeda atau perbedaan font di Wayland bisa dirasakan berbeda oleh tiap orang
  • Saya sudah beberapa tahun memakai Wayland berbasis wlroots/swaywm, dan bahkan eGPU bekerja sempurna.
    Tapi mungkin itu juga karena saya memakai perangkat AMD. Hidup terlalu singkat untuk dihabiskan menghadapi masalah Nvidia
    • Sebaliknya, di grafis terintegrasi Intel, sway sering crash, jadi saya kembali ke i3+Xorg
    • Saya sudah memakai Nvidia selama 23 tahun dan tidak pernah punya masalah besar. Menurut saya ini cuma soal pilihan masing-masing
    • Dulu saya juga memakainya dengan baik di Nvidia, dan layar 5K pun oke dengan patch TILE.
      Saya sempat pindah ke Wayland karena dukungan penskalaan multi-output, lalu kembali lagi
  • Saya baru-baru ini pindah ke Linux karena masalah Windows, dan dulu itu mustahil karena tidak adanya fractional scaling.
    Berkat Wayland, itu teratasi dan merupakan peningkatan besar. Tetapi karena tidak semua distro menjadikan Wayland sebagai default, saya memilih Ubuntu.
    Snap Firefox yang tidak memakai akselerasi hardware agak merepotkan
    • Bagi saya juga, fractional scaling adalah hal yang paling kurang di Linux.
      Di macOS, pengaturan seperti “terlihat seperti 1440p” tetap sempurna, dan di Windows sedikit buram.
      Di Linux, X11 lambat, sementara Wayland masih punya latensi performa
  • Saya juga memakai kombinasi i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotool.
    Mengganti stack yang bekerja sempurna ini ke Sway berarti lebih banyak rugi daripada untung.
    Saya rasa luar biasa bahwa Michael sudah mencoba dan mendokumentasikannya
    • Kesan saya, dia sangat teliti dalam mencatat masalah nyata yang terjadi
  • Saya tidak berniat pindah sebelum window manager (WM) yang saya pakai mendukung Wayland.
    Masalah terbesar Wayland adalah banyak proyek WM tidak bisa beralih karena kekurangan tenaga pengembang.
    Memang bisa diakali dengan XWayland, tetapi saya tidak ingin menambah lapisan pada lingkungan yang sudah bekerja sempurna
    • Jika Anda memakai StumpWM, versi Wayland-nya yaitu Mahogany sedang dikembangkan secara aktif.
      Selain itu, Wayback adalah proyek untuk menjalankan seluruh desktop X11 di atas Wayland
  • Saya memakai Wayland di laptop Framework dan semuanya berjalan sempurna.
    Monitor 4K, perpindahan layar tunggal, fractional scaling, semuanya tanpa masalah.
    Bahkan di Chromebook lama, screen tearing hilang dan semuanya berjalan mulus.
    Sampai sekarang saya belum merasakan kekurangannya, malah satu-satunya kekurangan adalah mendengar orang bilang itu “salah”
    • Bagus kalau berjalan baik, tetapi sebaliknya kita juga harus mengakui bahwa ada orang yang tidak bisa memakainya dengan baik
    • Hanya karena Anda beruntung tidak mengalami masalah bukan berarti kekurangannya tidak ada
  • Bagi saya Wayland hanya punya kekurangan dan tidak punya kelebihan. Saya rasa struktur yang melempar kompleksitas ke lapisan lain itu salah.
    Ke depan saya akan tetap memakai Xorg dan Openbox
    • Menyebarkan kompleksitas dari satu tempat ke banyak tempat adalah keputusan yang sulit dipahami
    • Meski begitu, pemeliharaan Xorg terus berkurang, dan para pengembang utama juga sedang pindah ke Wayland.
      Pada akhirnya Wayland akan menjadi satu-satunya pilihan yang masih dikelola secara aktif