Belajar Remote Desktop - X11 vs Wayland: Implikasi untuk VNC

#Pendahuluan

Hampir semua praktik VNC di series ini berjalan di atas X11. Tapi Linux sedang bertransisi besar-besaran ke Wayland, dan transisi ini mengguncang fondasi VNC klasik. Episode 17 menjelaskan mengapa — dan apa yang harus kalian lakukan jika mesin target sudah menjalankan Wayland.

Kalian akan memahami perbedaan mendasar X11 dan Wayland, mengapa x11vnc dan TigerVNC Xvnc terbatas di Wayland, dan mengenal tiga jembatan menuju dunia modern: GNOME Remote Desktop yang native, TigerVNC w0vncserver di versi 1.16, serta kompositor lain seperti KDE krfb.

#X11 dan Wayland: Perbedaan Mendasar

#Siapa yang Memegang Layar dan Input

Di X11, ada display server terpusat yang mengatur window, input, dan framebuffer. Aplikasi boleh meminta snapshot layar, membaca event input, dan berinteraksi dengan window lain. Inilah yang memungkinkan x11vnc atau x0vncserver "membaca" layar dengan bebas.

Di Wayland, peran itu dipegang oleh kompositor. Kompositor adalah satu-satunya pihak yang berhak menampilkan konten ke layar dan menerima input. Aplikasi tidak bisa semena-mena membaca window aplikasi lain — setiap akses harus melalui protokol resmi dan izin eksplisit.

X11      ->  display server terpusat  ->  akses bebas
Wayland  ->  kompositor memegang kontrol ->  akses via protokol

#Mengapa VNC Klasik Terbatas di Wayland

#Masalah x11vnc dan Xvnc

Perubahan arsitektur ini menjadi dinding bagi VNC klasik:

• x11vnc bekerja dengan membaca framebuffer display X11. Di Wayland murni, tidak ada display X11 yang bisa dibaca — x11vnc bahkan tidak bisa berjalan secara native.
• TigerVNC Xvnc memang membuat display X11 sendiri secara virtual, jadi masih bisa berjalan di atas Wayland sebagai session terpisah (bukan men-share sesi Wayland yang aktif). Tapi dia tidak bisa men-share layar Wayland yang sedang berjalan.
• Mengakses sesi Wayland aktif membutuhkan dukungan kompositor untuk mengekspor framebuffer — sesuatu yang harus dibangun khusus oleh masing-masing desktop.

Dampaknya jelas: di mesin yang sudah Wayland-native, tool VNC lama tidak bisa lagi "melihat" desktop yang sedang dipakai.

#Solusi Wayland: GNOME Remote Desktop

#Native Wayland dari GNOME

Jembatan pertama dan paling matang adalah GNOME Remote Desktop. Karena dia berjalan di dalam kompositor GNOME (Mutter), dia bisa mengakses framebuffer dan input secara sah sesuai protokol Wayland. Mendukung VNC dan RDP secara native.

grdctl status

Perintah grdctl status menampilkan status layanan remote desktop GNOME. Konfigurasi lengkap lewat grdctl akan dibahas tuntas di episode 18 — cukup untuk dikatakan bahwa ini adalah solusi utama untuk desktop GNOME Wayland.

#Solusi Wayland: w0vncserver TigerVNC

#TigerVNC 1.16 untuk Wayland

Mulai TigerVNC 1.16, komunitas menyediakan w0vncserver — server VNC yang dirancang untuk men-share sesi Wayland. Tidak seperti Xvnc yang membuat display X11, w0vncserver mengambil framebuffer dari kompositor Wayland melalui portal dan menyajikannya sebagai server VNC.

w0vncserver --help

Dukungan ini masih bergantung pada fitur ScreenCast yang disediakan kompositor. Di lingkungan di mana GNOME Remote Desktop tidak diinginkan, w0vncserver memberi alternatif berbasis TigerVNC yang tetap dalam keluarga tool yang sudah kalian kenal.

#Solusi Wayland: Kompositor Lain

#KDE krfb

KDE menyediakan krfb — aplikasi berbagi desktop yang terintegrasi dengan kompositor KDE Plasma. Seperti GNOME Remote Desktop, krfb berjalan di dalam lingkungan Wayland dan bisa men-share sesi yang aktif:

sudo apt install krfb

Di KDE, krfb hadir sebagai bagian dari pengaturan Sharing. Karena dia hidup di dalam kompositor, dia tidak menghadapi dinding Wayland yang menghambat tool VNC klasik.

#Memilih Berdasarkan Desktop

Ringkasan pilihan di dunia Wayland:

Pesan utamanya tegas: di era Wayland, kalian tidak bisa lagi "menempelkan" x11vnc ke desktop yang berjalan. Solusi remote desktop harus datang dari ekosistem kompositor itu sendiri.

#Mengecek Jenis Sesi

#Apakah Mesin Sudah Wayland

Sebelum menyusun strategi remote, pastikan dulu jenis sesi yang berjalan di mesin target. Dua perintah berikut menjawabnya dengan cepat:

echo $XDG_SESSION_TYPE
loginctl show-session $XDG_SESSION_ID -p Type

Jika output menampilkan wayland, maka tool VNC klasik tidak akan bisa men-share desktop aktif dan solusi native adalah pilihan yang tepat. Jika output x11, seluruh tool dari episode 4-7 tetap bekerja seperti biasa — x11vnc dan x0vncserver bisa langsung dipakai.

#Sesuai Strategi

Dengan mengetahui jenis sesi, keputusan menjadi jelas: sesi X11 memakai tool klasik yang sudah kalian kuasai, sesi Wayland memakai solusi native kompositor. Keduanya valid — kuncinya adalah tidak memaksa tool yang salah untuk arsitektur yang salah.

#Penutup

Episode 17 menjelaskan pergulatan X11 versus Wayland: di X11, akses layar bebas sehingga x11vnc dan Xvnc bekerja; di Wayland, kompositor memegang kendali sehingga VNC klasik terbatas, dan jembatannya adalah GNOME Remote Desktop, w0vncserver TigerVNC 1.16, serta KDE krfb.

Inti yang harus dibawa pulang:

• Wayland memberi kompositor kontrol penuh atas layar dan input.
• x11vnc dan Xvnc tidak bisa men-share sesi Wayland yang berjalan.
• GNOME Remote Desktop adalah solusi native untuk desktop GNOME.
• w0vncserver TigerVNC 1.16 men-share Wayland via protokol ScreenCast.
• KDE memakai krfb yang terintegrasi dengan Plasma.
• Di Wayland, solusi harus datang dari ekosistem kompositor.

Di episode 18 selanjutnya kita praktik langsung dengan solusi modern GNOME: GNOME Remote Desktop — setup modern — mengaktifkan RDP dan VNC dengan grdctl, menetapkan password, mode view-only, serta konfigurasi lewat GNOME Settings untuk sesi headless. Sampai jumpa!