2026'da sonunda Wayland kullanabilecek miyiz?

 (michael.stapelberg.ch)
2 puan yazan GN⁺ 2026-01-05 | 1 yorum | WhatsApp'ta paylaş
  • Wayland, X11'in halefi grafik yığını olarak 2008'de başladı, ancak yazar 18 yıl boyunca kendi sisteminde onu düzgün şekilde kullanamadığını değerlendiriyor
  • 2025 itibarıyla nVidia sürücüsünde GBM ve explicit sync desteği sayesinde temel çalıştırma mümkün hale geldi, ancak 8K monitör TILE desteğinin hâlâ olmaması gibi nedenlerle tam geçiş zor
  • Sway 1.11 ve wlroots 0.19.0 ile önemli teknik ilerlemeler sağlandı, ancak giriş gecikmesi, grafik glitch'leri ve Xwayland ölçeklendirme sorunları gibi günlük kullanım engelleri hâlâ çok sayıda
  • Başlıca uygulamalar olan Chrome ve Emacs hâlâ performans düşüşü, render farkları ve donanım hızlandırmada kararsızlık gibi sorunlar gösteriyor
  • Genel olarak Wayland için "artık günlük kullanıma yaklaşmış durumda" denebilir, ancak gündelik iş akışı açısından X11/i3 kombinasyonu hâlâ daha kararlı sonucuna varılıyor

Wayland'in tarihsel arka planı

  • Wayland, 2008'de başlatılan X sunucusunun (X11, Xorg) halef projesi ve yazar 2009'da X11 için döşemeli pencere yöneticisi i3'ü geliştirdi
  • İlk dönemde yalnızca Weston demo compositör çalıştırılabiliyordu; 2014'te GNOME, sonrasında ise KDE Wayland desteği sunmaya başladı
  • Firefox, Chrome, Emacs gibi başlıca uygulamalar Wayland'i yalnızca deneysel bayraklarla kullanabiliyordu
  • nVidia GPU'lar uzun süre Wayland üzerinde ya hiç çalışmadı ya da grafik hataları üretti; 8K monitör uyumluluğu sorunları da sürdü
  • Son dönemde Fedora, RHEL, Asahi Linux gibi başlıca dağıtımların Wayland'i varsayılan ya da tek masaüstü yığını olarak benimsemesi geçiş baskısını artırdı

Wayland çalışma ortamının kurulumu

  • Test sistemi olarak nVidia RTX 4070 Ti (dizüstü) ve RTX 3060 Ti (ana PC) kullanıldı
  • nVidia sürücüsü 495 (2021) ile GBM desteği eklendi ve explicit sync özelliği Sway 1.11 (2025) ile wlroots 0.19.0 içinde hayata geçirildi
  • Ancak 8K Dell UP3218K monitörde TILE özelliğinin desteklenmemesi nedeniyle Sway'de ekran ikiye bölünmüş şekilde görünüyor
    • EBADBEEF yaması ve Claude Code analizi sayesinde SRC_X DRM özelliği hatası bulundu ve bir geçici çözüm yamasıyla tam ekran görüntüleme başarıldı
  • GNOME TILE'ı destekliyor, ancak ekranın ortasında ciddi tearing oluşuyor
  • NixOS 25.11 ortamında GDM, GNOME ve Sway birlikte yapılandırıldı; ayrıca foot, fuzzel, wayland-utils gibi Wayland'e özgü araçlar eklendi

Deney sonuçları: Sway ortamı

  • Sway, i3 yapılandırmasıyla büyük ölçüde uyumlu ve yazar NEO klavye düzeniyle giriş/çıkış ayarlarını uyarladı
  • Başlıca sorunlar:
    • Fare işaretçisinde gecikme ve akıcı olmayan hareket (nVidia donanım imleci desteğinin olmamasından şüpheleniliyor)
    • Xwayland uygulamalarında ölçeklendirme yapılamaması nedeniyle bulanık ya da iki kez büyütülmüş görüntü
    • Bazı kısayolların çift çalışması (ghost key press)
  • GTK uygulamalarında başlangıçtaki aşırı büyük yazı tipi sorunu gsettings reset ile çözüldü
  • GTK3 yalnızca dconf ayarlarını kullandığı için render tutarlılığı adına font-name dconf üzerinden ayarlanmalı
  • swaylock, i3lock'tan farklı olarak kapanışta "kırmızı ekran" durumuna geçiyor ve yalnızca SIGUSR1 ile kaldırılabiliyor
  • i3 IPC tabanlı otomasyon araçları, soket yolu farkı, süreçlerin artakalan durumu ve yerleşim geri yükleme desteğinin olmaması nedeniyle kısmi uyumluluk sunuyor

Başlıca uygulama testleri

  • foot terminali hafif olsa da bazı renk farkları, Ctrl+Enter işleme, URL seçimi ve screen renk sorunu tespit edildi
  • Emacs'ın varsayılan sürümü Xwayland üzerinde çalıştığı için bulanık görünüyor; pgtk sürümünde ise giriş gecikmesi ve harf aralığı farkları var
  • Chrome'da GPU süreci çökmesi nedeniyle donanım hızlandırma duruyor ve pencere geri yüklemede önceki çalışma alanı bilgisi korunmuyor
  • Ekran paylaşımı xdg-desktop-portal-wlr üzerinden mümkün, ancak pencere bazlı paylaşım desteği yok ve düşük çözünürlüklü aktarım sorunu mevcut
  • Çıkış ölçeklendirme etkinleştirildiğinde pencere içeriğinin anlık kayması veya bulanıklaşması şeklinde glitch'ler oluşuyor
  • dunst bildirimleri ve rofi (2.0.0 ve sonrası) düzgün çalışıyor; grim ekran görüntüsü aracıysa pencere seçimi açısından kullanışsız

Sonuç: 2026'da Wayland kullanımı mümkün mü?

  • Wayland/Sway oturumu ilk kez gerçek kullanıma yaklaşmış durumda, ancak hâlâ çok sayıda kusur var
  • X11/i3 ortamı 763μs düzeyinde düşük giriş gecikmesi ve kusursuz kararlılık sağlıyor
  • Wayland'e geçildiğinde grafik glitch'leri, giriş gecikmesi ve başlıca uygulamalarda performans düşüşü yaşanıyor
  • Günlük kullanım için gereken koşullar:
    • Sway'deki çift tuş girişi ve geçiş glitch'lerinin çözülmesi
    • Chrome donanım hızlandırmasının kararlı hale gelmesi ve pencere geri yükleme desteği
    • Emacs (pgtk) için giriş gecikmesi ve render iyileştirmeleri
  • Sonuç olarak Wayland günlük iş kullanımı için henüz hazır değil ve yazar X11/i3 kullanmayı sürdürmeyi planlıyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-01-05
Hacker News görüşleri
  • Wayland aslında sadece bir protokol, bu yüzden birden fazla uygulaması var (GNOME, KDE, wlroots vb.)
    Xorg’da masaüstü tek bir sağlam temel üzerine kuruluydu, ancak Wayland’da her masaüstü adeta tekerleği yeniden icat ediyor.
    Weston referans için iyi ama günlük kullanım için uygun değil.
    Bence tüm masaüstlerinin ortak kullanabileceği bir standart kütüphane gerekli. wlroots bu rolü hedefliyor ama GNOME ya da KDE’nin yakında oraya geçeceğini sanmıyorum
    • Bence X.org doğru soyutlama seviyesini yakalamıştı. WM’nin girdi ya da çıktı işlemesini doğrudan ele alması gerekmiyordu; bu da sadelik ve enerji verimliliği sağlıyordu. Wayland bu açıdan X11’in derslerini öğrenemedi
    • Sway, Hyprland ve şu an niri kullandım. wlroots tabanlı Sway ve niri oldukça iyi, ama hâlâ çok fazla rastgele hata var. Wine uygulamalarında işaretçi sorunları, ekran paylaşımı çökmeleri, 10 bit renk sorunları vb. Belki 2027 civarında oturur ama 20 yıllık geliştirme için verimsiz hissettiriyor
    • KDE ve GNOME’un ayrı ayrı xdg-desktop-portal uygulamaları var, bu da uyumluluk sorunları yaratıyor. wlroots tabanlıysa xdg-desktop-portal-wlr, Hyprland ise xdg-desktop-portal-hyprland kullanmak gerekiyor.
      Wayland’ın yapısı resmi mimari belgesinde olduğu gibi teoride iyi görünüyor, ama pratikte protokol seviyesinde eksik pek çok özellik var
    • Aslında X de bir protokoldü, ama X.org adlı tek bir uygulama olduğu için daha az karmaşa vardı. wlroots seviyesinde standartlaştırılmış tek bir kütüphane bulundurmak teknik olarak imkânsız değil
    • Wayland geliştiricileri bunu başta yalnızca ekran odaklı bir protokol olarak tasarladı. Girdi ya da pencere yönetimi protokollerini ayrı grupların yapmasını beklediler, ama bu pek gerçekleşmedi.
      Bugün Wayland’ın yerine bir şey koymaya çalışmak, aslında zaten olgunlaşmış kısımları tekrar üretmek gibi bir israf olabilir
  • Hâlâ Wayland kullanmak için bir neden göremiyorum. Xorg kararlı ve sorun çözüm yazılarının çoğu da “Wayland kullanıyorsan Xorg’a geri dön” diye başlıyor.
    Muhtemelen systemd’de olduğu gibi dağıtımlar bunu varsayılan olarak dayatınca asıl benimsenme artacak
    • Sıradan kullanıcı için özellikle geçmek gerekmiyor. Ama Wayland, X11’in zayıf kaldığı çoklu ekran ölçeklendirme gibi şeyleri iyi ele alıyor.
      GNOME ve KDE açısından asıl motivasyon, X11’i sürdürme yükünü azaltmak için Wayland’a geçmek.
      Bence bu yılın hedefi, “dezavantajı kalmamış” bir seviyeye ulaşmak
    • Wayland daha akıcı bir performans veriyormuş gibi hissettiriyor ama bazı uygulamalar yüzünden Xorg kullanmak zorundayım.
      Arch ve Ubuntu’daki GNOME 49 zaten Xorg’u varsayılandan çıkardı, KDE de yakında bunu takip edecek. Xorg dönemi sona eriyor
    • Eskiden xorg.conf dosyasını elle düzenlemek gerekirdi; Ubuntu’da Wayland’ı deneysel olarak kullandıktan sonra ise tamamen geçtim. AMD GPU sayesinde sanırım sorunsuz ve pürüzsüz
    • Wayland’ın artısı fractional scaling
    • Ben x2x, xev, xdotool gibi araçları kullanmak zorundayım; Wayland’ın güvenlik modeli nedeniyle bunlar mümkün değil, bu yüzden Xorg’da kalıyorum
  • Nvidia’nın Wayland’ın GBM API’sini reddettiği iddiası yanlış. GBM, Mesa içindeki gayriresmî bir API olduğu için Nvidia bunu doğrudan uygulayamazdı.
    Bu yüzden EGLStreams adlı satıcıdan bağımsız bir alternatif önerdi.
    Asıl sorun, freedesktop tarafının Nvidia sürücüsünün çalışabileceği bir yapı sunmamasıydı
    • Ama açık kaynak bir proje olan Mesa’nın nasıl olup da kapalı bir API’ye bağımlı olabildiğini merak ediyorum
  • Yıllardır Gnome’da Wayland kullanıyorum ve hiçbir sorun yaşamadım.
    Elbette bunda Nvidia yerine daha basit donanım kullanmamın da payı olabilir ama Wayland’ın sorunsuz çalışabildiğini vurgulamak isterim
    • Ben de aynı şekilde Sway (2016) ve KDE Plasma 6’da kusursuz kullanıyorum. Sadece Steam oyunlarını XWayland ile çalıştırıyorum. AMD/Intel kombinasyonu çok daha kararlı
    • Nvidia donanımında da son zamanlarda oldukça akıcı çalışıyor. Eskiden takılıyordu ama şimdi Xorg’dan daha iyi hissettiriyor.
      Yalnız pencere konumu kontrolü ya da başka uygulamalar arasında gezinme gibi şeyler için Gnome Shell Extension ile dolanmak gerekiyor
    • Eskiden CRT monitör titremesini fark etmeme hikâyesinde olduğu gibi, Wayland’daki ince giriş hissi ya da yazı tipi farkları gibi küçük rahatsızlıklar kişiden kişiye farklı algılanabilir
  • Yıllardır wlroots/swaywm tabanlı Wayland kullanıyorum ve eGPU bile kusursuz çalışıyor.
    Ama bu belki de AMD donanımı kullandığım içindir. Hayat, Nvidia sorunlarıyla heba edilemeyecek kadar kısa
    • Buna karşılık Intel dahili grafikte sway sık sık çöküyor, ben de i3+Xorg’a dönüyorum
    • Nvidia’yı 23 yıldır kullanıyorum ama büyük bir sorun yaşamadım. Yine de bunun biraz tercih meselesi olduğunu düşünüyorum
    • Eskiden Nvidia’da da gayet iyi kullanıyordum, TILE yamasıyla 5K ekran da iyiydi.
      Çoklu çıkış ölçeklendirme desteği yüzünden Wayland’a geçip sonra geri döndüğüm de oldu
  • Son Windows sorunları yüzünden Linux’a geçtim; eskiden fractional scaling eksikliği yüzünden bu mümkün değildi.
    Wayland sayesinde bu çözüldü ve büyük bir iyileşme oldu. Ama her dağıtım varsayılan olarak Wayland kullanmadığı için Ubuntu’yu seçtim.
    Snap Firefox’un donanım hızlandırma kullanmaması biraz can sıkıcıydı
    • Bence Linux’ta en büyük eksik hâlâ fractional scaling.
      MacOS’ta “1440p gibi görünsün” ayarı bile kusursuz, Windows’ta biraz bulanık.
      Linux’ta ise X11 yavaş, Wayland’da da hâlâ performans gecikmesi var
  • Ben de i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotool kombinasyonunu kullanıyorum.
    Kusursuz çalışan bu yapıyı Sway ile değiştirmek kazançtan çok kayıp olur.
    Michael’ın bunu deneyip belgelemiş olması bence etkileyici
    • Gerçek sorunları özenle kaydetmiş olması etkileyici
  • Kullandığım pencere yöneticisi (WM) Wayland’ı desteklemeden geçmeyi düşünmüyorum.
    Wayland’ın en büyük sorunu, çeşitli WM projelerinin insan kaynağı eksikliği yüzünden geçiş yapamaması.
    XWayland ile dolaşmak mümkün ama zaten kusursuz çalışan bir ortama gereksiz yere katman eklemek istemiyorum
    • StumpWM kullanıyorsanız, Wayland sürümü olan Mahogany aktif olarak geliştiriliyor.
      Ayrıca Wayback, tüm X11 masaüstünü Wayland üzerinde çalıştıran bir proje
  • Framework dizüstünde Wayland kullanıyorum ve kusursuz çalışıyor.
    4K monitör, tek ekran arasında geçiş, fractional scaling; hepsi sorunsuz.
    Eski bir Chromebook’ta bile ekran yırtılması ortadan kalktı ve akıcı çalışıyor.
    Henüz bir dezavantaj görmedim; hatta tek dezavantaj, bana sürekli “yanlış” denmesi gibi geliyor
    • Eğer sende iyi çalışıyorsa güzel ama bunun tersine çalışmayan insanlar da olduğunu kabul etmek gerek
    • Sorun yaşamamış olman, sırf şanslı olduğun için dezavantaj olmadığı anlamına gelmez
  • Benim için Wayland’ın yalnızca dezavantajları var, avantajı yok. Karmaşıklığı başka katmanlara iten yapısının hatalı olduğunu düşünüyorum.
    Bundan sonra da Xorg ve Openbox kullanacağım
    • Karmaşıklığın tek bir yerden alınıp birçok yere dağıtılması anlaşılmaz bir karar
    • Yine de Xorg’un bakımı azalıyor ve ana geliştiriciler Wayland’a geçiyor.
      Sonunda aktif olarak sürdürülen tek seçenek Wayland olacak