ในปี 2026 ในที่สุดเราจะใช้ Wayland ได้หรือยัง?

 (michael.stapelberg.ch)
2 คะแนน โดย GN⁺ 2026-01-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Wayland เป็นกราฟิกสแตกตัวสืบทอดของ X11 ที่เริ่มต้นในปี 2008 แต่ผู้เขียนประเมินว่าตลอด 18 ปีที่ผ่านมา ยังไม่สามารถใช้งานได้อย่างเหมาะสมบนระบบของตน
  • ณ ปี 2025 ด้วย การรองรับ GBM และ explicit sync ของไดรเวอร์ nVidia ทำให้สามารถเริ่มใช้งานได้เป็นพื้นฐานแล้ว แต่ก็ยังเปลี่ยนผ่านได้ไม่สมบูรณ์เพราะยังมีปัญหาอย่าง ไม่รองรับ TILE ของจอ 8K
  • มีความคืบหน้าทางเทคนิคสำคัญใน Sway 1.11 และ wlroots 0.19.0 แต่ยังมีอุปสรรคต่อการใช้งานจริงจำนวนมาก เช่น input lag, กราฟิก glitch และปัญหา scaling ของ Xwayland
  • แอปหลักอย่าง Chrome และ Emacs ยังแสดงปัญหาเรื่องประสิทธิภาพลดลง ความแตกต่างในการเรนเดอร์ และความไม่เสถียรของ hardware acceleration
  • โดยรวมแล้ว Wayland นั้น “เพิ่งเริ่มมองเห็นความเป็นไปได้ในการใช้งานจริง” แต่สำหรับงานประจำวัน ชุด X11/i3 ยังเสถียรกว่า

ภูมิหลังทางประวัติศาสตร์ของ Wayland

  • Wayland เป็น โครงการตัวสืบทอดของ X server (X11, Xorg) ที่เริ่มในปี 2008 และผู้เขียนได้พัฒนาไทลิงวินโดว์แมเนเจอร์สำหรับ X11 อย่าง i3 ตั้งแต่ปี 2009
  • ในช่วงแรกสามารถรันได้เพียงเดโมคอมโพสิตเตอร์ Weston เท่านั้น และ GNOME เริ่มรองรับ Wayland ในปี 2014 ตามมาด้วย KDE
  • แอปหลักอย่าง Firefox, Chrome, Emacs สามารถใช้ Wayland ได้ผ่าน experimental flag เท่านั้น
  • nVidia GPU ไม่สามารถทำงานบน Wayland ได้เป็นเวลานานหรือก่อให้เกิดกราฟิกผิดพลาด และปัญหาความเข้ากันได้กับจอ 8K ก็ยังคงอยู่
  • เมื่อไม่นานมานี้ ดิสโทรหลักอย่าง Fedora, RHEL, Asahi Linux เริ่มนำ Wayland มาใช้เป็นเดสก์ท็อปสแตกเริ่มต้นหรือสแตกเดียว ส่งผลให้แรงกดดันในการย้ายเพิ่มขึ้น

การตั้งค่าสภาพแวดล้อมสำหรับรัน Wayland

  • ระบบทดสอบใช้ nVidia RTX 4070 Ti (เครื่องพกพา) และ RTX 3060 Ti (เครื่องหลัก)
  • มีการเพิ่มการรองรับ GBM ตั้งแต่ ไดรเวอร์ nVidia 495 (2021) และฟีเจอร์ explicit sync ถูกนำมาใช้ใน Sway 1.11 (2025) และ wlroots 0.19.0
  • อย่างไรก็ตาม เนื่องจาก ไม่รองรับคุณสมบัติ TILE ของจอ 8K Dell UP3218K ทำให้ใน Sway หน้าจอถูกแสดงแยกเป็นสองส่วน
    • ด้วยแพตช์ของ EBADBEEF และการวิเคราะห์ของ Claude Code จึงค้นพบบั๊กของ คุณสมบัติ SRC_X DRM และสามารถแสดงผลเต็มหน้าจอได้สำเร็จด้วยแพตช์เลี่ยงปัญหา
  • GNOME รองรับ TILE แต่เกิด tearing อย่างรุนแรงบริเวณกึ่งกลางจอ
  • ในสภาพแวดล้อม NixOS 25.11 มีการตั้งค่า GDM, GNOME และ Sway ควบคู่กัน พร้อมเพิ่มเครื่องมือเฉพาะ Wayland อย่าง foot, fuzzel, wayland-utils

ผลการทดลอง: สภาพแวดล้อม Sway

  • Sway เข้ากันได้กับการตั้งค่า i3 เป็นส่วนใหญ่ และผู้เขียนได้ปรับเลย์เอาต์คีย์บอร์ด NEO รวมถึงการตั้งค่า input/output
  • ปัญหาหลัก:
    • เมาส์พอยน์เตอร์มีอาการหน่วงและการเคลื่อนไหวไม่ลื่นไหล (คาดว่าเพราะ nVidia ไม่รองรับ hardware cursor)
    • ไม่สามารถ scaling แอป Xwayland ได้ ทำให้ภาพเบลอหรือเกิดการขยายซ้อนสองชั้น
    • บางคีย์ลัดเกิดอาการ สั่งงานซ้ำสองครั้ง (ghost key press)
  • แอป GTK มีปัญหาขนาดฟอนต์เริ่มต้นใหญ่เกินไปในช่วงแรก แต่แก้ได้ด้วย gsettings reset
  • เนื่องจาก GTK3 ใช้เฉพาะการตั้งค่าจาก dconf จึงต้องกำหนด font-name ใน dconf เพื่อให้การเรนเดอร์ตรงกัน
  • swaylock ต่างจาก i3lock ตรงที่เมื่อปิดจะเข้าสู่สถานะ “หน้าจอแดง” และปลดได้ด้วย SIGUSR1 เท่านั้น
  • เครื่องมืออัตโนมัติที่อิงกับ i3 IPC ยังเข้ากันได้เพียงบางส่วน เนื่องจากมีความต่างของพาธซ็อกเก็ต การค้างของโปรเซส และการไม่รองรับการกู้คืนเลย์เอาต์

การทดสอบแอปหลัก

  • เทอร์มินัล foot มีน้ำหนักเบา แต่พบความต่างของสีบางส่วน การจัดการ Ctrl+Enter การเลือก URL และปัญหาสีของ screen
  • Emacs เวอร์ชันพื้นฐานรันผ่าน Xwayland จึงแสดงผลเบลอ ส่วนเวอร์ชัน pgtk มีทั้ง input lag และความต่างของระยะห่างตัวอักษร
  • Chrome มีปัญหา GPU process ล่มจน hardware acceleration หยุดทำงาน และเมื่อกู้คืนหน้าต่างจะ ไม่เก็บข้อมูล workspace ก่อนหน้า
  • การแชร์หน้าจอ ทำได้ผ่าน xdg-desktop-portal-wlr แต่ยังมีปัญหา ไม่รองรับการแชร์ระดับหน้าต่าง และ ส่งภาพด้วยความละเอียดต่ำ
  • เมื่อ เปิดใช้ output scaling จะเกิด glitch ที่ทำให้เนื้อหาหน้าต่างขยับชั่วคราวหรือเบลอ
  • การแจ้งเตือน dunst และ rofi (2.0.0 ขึ้นไป) ทำงานได้ปกติ ส่วนเครื่องมือจับภาพหน้าจอ grim มีฟังก์ชันเลือกหน้าต่างที่ใช้งานไม่สะดวก

บทสรุป: ความเป็นไปได้ของการใช้ Wayland ในปี 2026

  • เซสชัน Wayland/Sway เข้าใกล้ระดับใช้งานจริงเป็นครั้งแรก แต่ก็ยังมีข้อบกพร่องจำนวนมาก
  • สภาพแวดล้อม X11/i3 ให้ input lag ต่ำระดับ 763μs และความเสถียรสมบูรณ์แบบ
  • เมื่อย้ายไป Wayland จะเกิด กราฟิก glitch, input lag และประสิทธิภาพของแอปหลักลดลง
  • เงื่อนไขที่จำเป็นสำหรับการใช้งานประจำวัน:
    • ต้องแก้ปัญหา การกดคีย์ซ้ำและ glitch ตอนสลับ ของ Sway
    • ต้องทำให้ hardware acceleration ของ Chrome เสถียรและรองรับการกู้คืนหน้าต่าง
    • ต้องปรับปรุง input lag และการเรนเดอร์ของ Emacs (pgtk)
  • โดยสรุปแล้ว Wayland ยังไม่พร้อมสำหรับงานประจำวัน และผู้เขียนมีแผนจะ ใช้ X11/i3 ต่อไป

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-05
ความคิดเห็นจาก Hacker News
  • Wayland เป็นเพียงแค่ โปรโตคอล เท่านั้น จึงมีหลาย implementation (GNOME, KDE, wlroots ฯลฯ)
    Xorg มีโครงสร้างที่เดสก์ท็อปต่าง ๆ วางอยู่บนฐานที่แข็งแรงเพียงชุดเดียว แต่ Wayland กลายเป็นว่าแต่ละเดสก์ท็อปต้องมาประดิษฐ์ล้อใหม่กันเอง
    Weston เหมาะสำหรับใช้อ้างอิง แต่ไม่เหมาะกับการใช้งานประจำวัน
    คิดว่าจำเป็นต้องมี standard library ที่ทุกเดสก์ท็อปใช้ร่วมกันได้ แม้ wlroots จะพยายามรับบทนั้น แต่ก็ดูไม่เหมือนว่า GNOME หรือ KDE จะย้ายมาใช้ในเร็ว ๆ นี้
    • คิดว่า X.org จับ ระดับของ abstraction ได้เหมาะสมแล้ว WM ไม่จำเป็นต้องจัดการ input หรือ output ด้วยตัวเอง ซึ่งช่วยให้มีความเรียบง่ายและประหยัดพลังงาน Wayland เหมือนไม่ได้เรียนรู้บทเรียนจาก X11
    • ฉันเคยใช้ Sway กับ Hyprland และตอนนี้ใช้ niri อยู่ Sway กับ niri ที่อิง wlroots ถือว่าค่อนข้างดี แต่ก็ยังมี บั๊กสุ่ม ๆ เยอะอยู่ เช่น ปัญหา pointer ในแอป Wine, การแครชตอนแชร์หน้าจอ, ปัญหาสี 10-bit เป็นต้น อาจจะเสถียรในปี 2027 ก็ได้ แต่ถ้านับว่าใช้เวลาพัฒนามา 20 ปี ก็รู้สึกว่าไม่มีประสิทธิภาพนัก
    • KDE และ GNOME ต่างก็มี implementation ของ xdg-desktop-portal เป็นของตัวเอง ทำให้เกิดปัญหาความเข้ากันได้ ถ้าใช้ระบบที่อิง wlroots ก็ต้องใช้ xdg-desktop-portal-wlr ถ้าเป็น Hyprland ก็ต้องใช้ xdg-desktop-portal-hyprland
      โครงสร้างของ Wayland เองตาม เอกสารสถาปัตยกรรมอย่างเป็นทางการ ก็ดูดีในเชิงทฤษฎี แต่ในทางปฏิบัติยังมีความสามารถที่ขาดไปอีกมากในระดับโปรโตคอล
    • จริง ๆ แล้ว X ก็เป็นโปรโตคอลเหมือนกัน แต่มี implementation เดียว คือ X.org จึงมีความสับสนน้อยกว่า การมีไลบรารีมาตรฐานแบบเดียวกับ wlroots สักตัวหนึ่งนั้น ไม่ใช่ว่าจะเป็นไปไม่ได้ในทางเทคนิค
    • เดิมทีนักพัฒนา Wayland ออกแบบมันให้เป็น โปรโตคอลสำหรับการแสดงผลเท่านั้น โดยคาดหวังว่ากลุ่มอื่นจะไปสร้างโปรโตคอลสำหรับ input และการจัดการหน้าต่างแยกต่างหาก แต่สิ่งนั้นไม่เกิดขึ้นอย่างที่หวัง
      ตอนนี้ความพยายามที่จะมาแทนที่ Wayland อาจกลายเป็นการเสียแรงไปกับการทำสิ่งที่ส่วนที่สุกงอมแล้วต้องมาทำใหม่
  • ยังไม่รู้ว่าทำไมถึงต้องใช้ Wayland Xorg นั้น เสถียร และบทความแก้ปัญหาส่วนใหญ่ก็มักเริ่มต้นด้วยคำว่า “ถ้าใช้ Wayland ก็ให้กลับไปใช้ Xorg”
    น่าจะต้องรอจนดิสโทรต่าง ๆ เปลี่ยนค่าเริ่มต้นแบบบังคับเหมือน systemd การยอมรับใช้งานอย่างจริงจังถึงจะเพิ่มขึ้น
    • ผู้ใช้ทั่วไปไม่ได้มีเหตุผลจำเป็นต้องเปลี่ยน แต่ Wayland จัดการจุดที่ X11 ทำได้ไม่ดีอย่าง การสเกลหลายจอ ได้ดี
      ในมุมของ GNOME และ KDE แรงผลักดันสำคัญคืออยากลดภาระในการบำรุงรักษา X11 ต่อไป
      คิดว่าเป้าหมายของปีนี้คือทำให้มันไปถึงระดับที่ “ไม่มีข้อเสีย”
    • รู้สึกว่า Wayland ให้ ประสิทธิภาพที่ลื่นไหลกว่า แต่ก็ยังต้องใช้ Xorg เพราะบางแอป
      ตอนนี้ GNOME 49 ของ Arch และ Ubuntu เอา Xorg ออกจากค่าเริ่มต้นไปแล้ว และ KDE ก็น่าจะตามมาเร็ว ๆ นี้ ยุคของ Xorg กำลังจะจบลง
    • เมื่อก่อนต้องแก้ xorg.conf เอง แต่หลังจากลองใช้ Wayland แบบ experimental บน Ubuntu ก็ย้ายมาใช้เต็มตัวเลย เพราะใช้ AMD GPU เลยลื่นและไม่มีปัญหา
    • ข้อดีของ Wayland คือ fractional scaling
    • ฉันจำเป็นต้องใช้เครื่องมืออย่าง x2x, xev, xdotool และด้วย โมเดลความปลอดภัย ของ Wayland มันเป็นไปไม่ได้ จึงยังอยู่กับ Xorg
  • ที่บอกว่า Nvidia ปฏิเสธ GBM API ของ Wayland นั้นเป็นความเข้าใจผิด GBM เป็น API ที่ไม่เป็นทางการ ภายใน Mesa ทำให้ Nvidia ไม่สามารถ implement เองได้โดยตรง
    เพราะอย่างนั้นจึงเสนอทางเลือกที่เป็นกลางต่อผู้ผลิตอย่าง EGLStreams ขึ้นมา
    ปัญหาจริง ๆ กลับเป็นฝั่ง freedesktop ที่ไม่ได้จัดเตรียมโครงสร้างให้ไดรเวอร์ Nvidia ทำงานได้
    • แต่ก็อดสงสัยไม่ได้ว่า Mesa ซึ่งเป็นโปรเจกต์โอเพนซอร์ส จะไปพึ่งพา API ที่ไม่เปิดเผย ได้อย่างไร
  • ฉันใช้ Wayland บน Gnome มาหลายปีแล้วและไม่มีปัญหาอะไรเลย
    แน่นอนว่าอาจเป็นเพราะใช้ฮาร์ดแวร์ธรรมดาและไม่ใช่ Nvidia ด้วย แต่ก็อยากย้ำว่า Wayland สามารถทำงานได้ดีจริง
    • ฉันก็เหมือนกัน ตอนนี้ใช้ได้สมบูรณ์แบบทั้งบน Sway (2016) และ KDE Plasma 6 เกม Steam เท่านั้นที่รันผ่าน XWayland คู่ AMD/Intel เสถียรกว่ามาก
    • แม้แต่บนฮาร์ดแวร์ Nvidia ช่วงหลังก็ ทำงานได้ลื่น พอสมควร เมื่อก่อนกระตุก แต่ตอนนี้กลับรู้สึกว่าดีกว่า Xorg
      เพียงแต่เรื่องอย่างการควบคุมตำแหน่งหน้าต่างหรือการสลับไปหาแอปอื่น ยังต้องอ้อมไปใช้ Gnome Shell Extension
    • เหมือนกับเรื่องเล่าว่าเมื่อก่อนบางคนไม่รู้สึกถึงการกะพริบของจอ CRT ความไม่สะดวกเล็ก ๆ อย่างสัมผัส input หรือความต่างของฟอนต์ใน Wayland ก็อาจเป็นสิ่งที่แต่ละคนรับรู้ไม่เหมือนกัน
  • ฉันใช้ Wayland ที่อิง wlroots/swaywm มาหลายปีแล้ว และแม้แต่ eGPU ก็ทำงานได้สมบูรณ์
    แต่ก็อาจเป็นเพราะใช้ ฮาร์ดแวร์ AMD ด้วย ชีวิตมันสั้นเกินกว่าจะเอาไปเสียกับปัญหา Nvidia
    • ในทางกลับกัน บน Intel integrated graphics นั้น sway แครช บ่อยจนต้องกลับไปใช้ i3+Xorg
    • ฉันใช้ Nvidia มา 23 ปีแล้วและไม่เคยมีปัญหาใหญ่ เพียงแต่คิดว่าเป็นเรื่องของการเลือกของแต่ละคน
    • เมื่อก่อนก็ใช้บน Nvidia ได้ดี และมี TILE patch เลยใช้จอ 5K ได้โอเค
      เคยย้ายไป Wayland เพราะรองรับการสเกลหลายเอาต์พุต แต่สุดท้ายก็ย้ายกลับมาอีก
  • ช่วงหลังย้ายจาก Windows มา Linux เพราะปัญหาของ Windows ซึ่งเมื่อก่อนทำไม่ได้เพราะไม่มี fractional scaling
    Wayland ช่วยแก้เรื่องนี้ได้ จึงถือว่าเป็นการปรับปรุงครั้งใหญ่ แต่ไม่ใช่ทุกดิสโทรจะใช้ Wayland เป็นค่าเริ่มต้น เลยเลือก Ubuntu
    Firefox แบบ Snap ไม่ใช้ hardware acceleration เลยค่อนข้างน่ารำคาญ
    • สำหรับฉัน fractional scaling คือจุดที่ขาดที่สุดของ Linux
      MacOS ตั้งให้ “ดูเหมือน 1440p” ได้อย่างสมบูรณ์ ส่วน Windows จะเบลอนิดหน่อย
      บน Linux นั้น X11 ช้า ส่วน Wayland ก็ยังมี ความหน่วงด้านประสิทธิภาพ อยู่
  • ฉันก็ใช้ชุด i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotool อยู่
    การเปลี่ยนสแต็กที่ทำงานได้สมบูรณ์แบบนี้ไปเป็น Sway มี เสียมากกว่าได้
    คิดว่า Michael น่าทึ่งมากที่ได้ลองทำและบันทึกไว้เป็นเอกสาร
    • ประทับใจที่เขาบันทึกปัญหาที่เกิดขึ้นจริงไว้อย่างละเอียดรอบคอบ
  • ฉันคงไม่ย้ายจนกว่า window manager (WM) ที่ใช้อยู่จะรองรับ Wayland
    ปัญหาใหญ่ที่สุดของ Wayland คือโปรเจกต์ WM จำนวนมากยัง ขาดคนทำ จึงย้ายไม่ได้
    แม้จะอ้อมด้วย XWayland ได้ แต่ก็ไม่อยากเพิ่มอีกเลเยอร์ให้กับสภาพแวดล้อมที่ตอนนี้ทำงานได้สมบูรณ์อยู่แล้ว
    • ถ้าคุณใช้ StumpWM อยู่ ตอนนี้ Mahogany ซึ่งเป็นเวอร์ชัน Wayland ก็กำลังพัฒนาอย่างคึกคัก
      อีกทั้ง Wayback ก็เป็นโปรเจกต์ที่รันเดสก์ท็อป X11 ทั้งชุดบน Wayland
  • ฉันใช้ Wayland บนโน้ตบุ๊ก Framework และมันทำงานได้สมบูรณ์แบบ
    ทั้งจอ 4K, การสลับไปใช้จอเดี่ยว, fractional scaling ทุกอย่างไม่มีปัญหา
    แม้แต่บน Chromebook เก่า อาการ ภาพฉีก ก็หายไปและใช้งานได้ลื่น
    ยังไม่รู้สึกถึงข้อเสียใด ๆ เลย ข้อเสียอย่างเดียวกลับเป็นการโดนคนบอกว่า “มันผิด”
    • ถ้ามันทำงานได้ดีก็ดีแล้ว แต่ในทางกลับกันก็ควรยอมรับด้วยว่า มีคนที่ใช้ไม่ได้ อยู่จริง
    • แค่โชคดีไม่เจอปัญหา ก็ไม่ได้แปลว่ามันไม่มีข้อเสีย
  • สำหรับฉัน Wayland มีแต่ ข้อเสียและไม่มีข้อดีเลย โครงสร้างที่ผลักความซับซ้อนไปให้เลเยอร์อื่นเป็นสิ่งที่ผิดตั้งแต่ต้น
    ต่อจากนี้ก็จะใช้ Xorg กับ Openbox ต่อไป
    • การกระจายความซับซ้อนจากจุดเดียวออกไปหลายจุดเป็นการตัดสินใจที่ เข้าใจไม่ได้
    • ถึงอย่างนั้น Xorg ก็ถูกลดการบำรุงรักษาลงเรื่อย ๆ และนักพัฒนาหลักก็ย้ายไปฝั่ง Wayland กันแล้ว
      สุดท้าย Wayland จะกลายเป็นตัวเลือกเดียวที่ยัง ได้รับการดูแลอย่างจริงจัง