Xfwl4 – โรดแมปคอมโพสิตเตอร์ Wayland สำหรับ Xfce

 (alexxcons.github.io)
1 คะแนน โดย GN⁺ 2026-01-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทีม Xfce เปิดเผยแผนพัฒนา คอมโพสิตเตอร์ Wayland ใหม่ ‘xfwl4’ โดยใช้เงินบริจาคจากชุมชน และมี Brian Tarricone นักพัฒนาหลักเป็นผู้นำโครงการ
  • ตั้งเป้าให้มี ฟังก์ชันและประสบการณ์ผู้ใช้แบบเดียวกับ xfwm4 เดิม พร้อมนำกล่องโต้ตอบการตั้งค่าและการกำหนดค่า xfconf กลับมาใช้ เพื่อให้การเปลี่ยนผ่านต่อเนื่อง
  • เขียนขึ้นใหม่ทั้งหมดบนพื้นฐานของ Rust และเฟรมเวิร์ก smithay มอบทั้งความปลอดภัยด้านหน่วยความจำและไปป์ไลน์กราฟิก·อินพุตที่ปรับแต่งได้
  • ขอบเขตโครงการครอบคลุม การเปลี่ยนโครงสร้างการจัดการเซสชัน, การรองรับ XWayland และ xdg-session-management, การปรับปรุงระบบ CI build
  • เป็น การลงทุนสำคัญเพื่อการเปลี่ยนผ่านสู่ Wayland ของ Xfce โดยมีกำหนดเผยแพร่รุ่นพัฒนาตัวแรกภายในปีนี้

แผนคอมโพสิตเตอร์ Wayland ใหม่ของ Xfce

  • ทีม Xfce เริ่มพัฒนา คอมโพสิตเตอร์ Wayland ใหม่ ‘xfwl4’ โดยใช้เงินบริจาคจากชุมชน
    • การพัฒนาดูแลโดย Brian Tarricone ผู้มีส่วนร่วมหลักมายาวนาน
    • เงินทุนโครงการส่วนใหญ่จะถูกนำมาใช้กับการพัฒนานี้
  • เป้าหมายคือทำให้ มีฟังก์ชันและการทำงานแบบเดียวกับ xfwm4 บนสภาพแวดล้อม Wayland
    • ใช้งาน กล่องโต้ตอบการตั้งค่า xfwm4 และการตั้งค่า xfconf เดิม ต่อไป เพื่อรักษาความสม่ำเสมอของประสบการณ์ผู้ใช้
  • xfwl4 ไม่ได้อิงจากโค้ด xfwm4 เดิม แต่เขียนใหม่ทั้งหมดด้วย Rust
    • สร้างขึ้นบนไลบรารี smithay

เหตุผลที่เลือกเขียนใหม่แทนการนำโค้ดเดิมกลับมาใช้

  • ในช่วงแรกมีแนวคิดจะแก้ไขโค้ด xfwm4 เพื่อรองรับทั้ง X11 และ Wayland ควบคู่กัน แต่ตัดสินว่าไม่เหมาะด้วยหลายเหตุผล
    • โครงสร้างของ xfwm4 ผูกกับ X11 มากเกินไป ทำให้ยากต่อการสร้างอินเทอร์เฟซแบบทั่วไป
    • การรีแฟกเตอร์มี ความเสี่ยงสูงที่จะทำให้เกิดบั๊กบน X11
    • มี แนวคิดของ X11 ที่ Wayland ไม่รองรับ ทำให้การคงโค้ดเดิมไว้ซับซ้อน
    • หากใช้โค้ดเดิมจะต้องพึ่งพา ภาษา C และ wlroots
  • การพัฒนาเป็นโค้ดเบสแยกจะช่วยให้ รักษาเสถียรภาพของ xfwm4 และเดินหน้าพัฒนา Wayland เชิงทดลองไปพร้อมกันได้

เหตุผลที่เลือก smithay

  • Brian Tarricone ประเมินเปรียบเทียบ wlroots กับ smithay ก่อนเลือก smithay
    • smithay รองรับ ส่วนขยายโปรโตคอล Wayland อย่างเป็นทางการส่วนใหญ่ รวมถึง โปรโตคอลของ wlroots และ KDE
    • ไม่มี abstraction ระดับสูง จึง ควบคุมไปป์ไลน์กราฟิก·อินพุตได้อย่างละเอียด
    • มีเอกสารที่ดี และการใช้ Rust ช่วย ลดความเสี่ยงของบั๊กและการล่มที่เกี่ยวกับหน่วยความจำ
    • นักพัฒนา ชื่นชอบ Rust
    • wlroots เขียนด้วย C ทำให้ การเขียน Rust bindings ทำได้ยาก

ขอบเขตโครงการและความท้าทายทางเทคนิค

  • นอกจาก การทำให้ฟังก์ชันเทียบเท่า xfwm4 แล้ว ยังมีงานต่อไปนี้รวมอยู่ด้วย
    • ในสภาพแวดล้อม Wayland คอมโพสิตเตอร์ต้องเป็นรากของเซสชัน จึง จำเป็นต้องเปลี่ยนโครงสร้างการเริ่มเซสชัน
    • เพิ่มการรองรับ โปรโตคอล xdg-session-management
    • รวม การรองรับ XWayland
    • อัปเกรด ระบบ build คอนเทนเนอร์ CI เป็นแบบ meson ที่สามารถ build โค้ด Rust ได้
  • Brian Tarricone เริ่มพัฒนาแล้ว และ มีกำหนดเผยแพร่รุ่นพัฒนาตัวแรกภายในปีนี้

ชุมชนและผู้สนับสนุน

  • โครงการนี้เกิดขึ้นได้จาก เงินบริจาคของผู้สนับสนุนผ่าน Open Collective US และ EU
  • สามารถติดตามความคืบหน้าการพัฒนาและรายละเอียดทางเทคนิคได้ใน GitLab issue ของ xfwl4 และซอร์สโค้ดรีโพซิทอรี
  • สอบถามเพิ่มเติมได้ผ่าน ช่อง Matrix #xfce-dev

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

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

 
GN⁺ 2026-01-29
ความคิดเห็นบน Hacker News

  • ได้ยินมาว่า xfwl4 ตั้งเป้าให้มี ฟีเจอร์และพฤติกรรมแบบเดียวกัน กับ xfwm4
    แต่เมื่อพิจารณาความต่างเชิงสถาปัตยกรรมระหว่าง X11 กับ Wayland ก็สงสัยว่าการตีความคำว่า “พฤติกรรม” จะเคร่งครัดแค่ไหน
    ตัวอย่างเช่น การป้องกันการขโมยโฟกัส ใน X11 ต้องอาศัย heuristic ที่ซับซ้อนและการตรวจสอบ timestamp แต่ใน Wayland คอมโพสิตเตอร์ควบคุมโฟกัสได้ทั้งหมด
    สุดท้ายจึงมีโจทย์ว่าจะออกแบบนโยบายใหม่อย่างไรให้ยังคงความรู้สึกแบบ heuristic เดิมไว้ แต่ก็สอดคล้องกับโมเดลสิทธิ์ของ Wayland
    อีกประเด็นที่สนใจคือ latency จากการบังคับใช้ compositing ว่าจะให้ความตอบสนองได้เท่ากับโหมด non-compositing ของ X11 บนฮาร์ดแวร์สเปกต่ำหรือไม่

    • ผมเป็นนักพัฒนา xfwl4 ครับ ข้อความ “ให้คล้ายที่สุดเท่าที่ทำได้” ก็ตรงตามนั้นเลย ไม่อาจเหมือนกันทุกอย่างได้ แต่จะทำให้ใกล้เคียงที่สุด
      เรื่องการป้องกันการขโมยโฟกัสนั้น ฝั่ง Wayland อาจให้ พฤติกรรมที่สม่ำเสมอ กว่าด้วยซ้ำ Xfwm4 ใช้ heuristic เลยมีพลาดบ้างเป็นบางครั้ง แต่โมเดล xdg-activation ของ Wayland ชัดเจนกว่ามาก
      ในแง่ประสิทธิภาพ บนฮาร์ดแวร์สมัยใหม่คงแทบไม่ต่างกันมาก แต่กับ อุปกรณ์ที่เก่ามากจริงๆ ก็อาจมีภาระเพิ่มขึ้น ซึ่งคงต้องทดสอบอีกมากถึงจะรู้
    • เมื่อก่อนผมเคยรันคอมโพสิตเตอร์ของ xfwm บน Pentium II 400MHz + GeForce 2 ก็ไม่มีปัญหาอะไร
      ภาระของ compositing แทบจะมีแค่ เวลาในการรอ vsync เท่านั้น ถ้าไม่ใช่ระดับ Pentium classic ก็น่าจะไหว
    • ชอบที่อธิบายเหตุผลกันอย่างตรงไปตรงมา แม้การ นำ Rust มาใช้ แบบเป็นเกาะภาษาอาจสร้างแรงเสียดทานกับ build tooling หรือการผสานเข้ากับ ecosystem บ้าง แต่ถึงอย่างนั้น XFCE ก็ยังน่าใช้สำหรับผมมากกว่า GNOME อยู่ดี
    • compositing ไม่จำเป็นต้องทำคู่กับ vsync เสมอไป จะรีเฟรชหน้าจอทันทีที่ไคลเอนต์ส่งคอนเทนต์ใหม่มาก็ได้
    • ทุกวันนี้แม้แต่ Intel GPU ระดับล่าง ก็แทบไม่เจอปัญหาเรื่อง overhead ของคอมโพสิตเตอร์แล้ว ยกเว้นแต่คนที่ยังใช้โน้ตบุ๊กอายุ 20 ปีเท่านั้น

  • หวังว่า XFCE จะยังคงเป็น เดสก์ท็อปที่เบา ต่อไป
    ผมชอบ KDE แต่คงเรียกว่าเบาได้ไม่เต็มปาก
    มองทั้ง Wayland และ Rust ในแง่บวก โดยคิดว่า Wayland คือทิศทางของอนาคต และ Rust ช่วยเรื่อง ป้องกันการแครช ได้
    เพียงแต่ฐานผู้ใช้ดั้งเดิมของ XFCE ค่อนข้างอนุรักษนิยม จึงอาจระแวงเทคโนโลยีใหม่ๆ อยู่บ้าง

    • ในฐานะคนที่ใช้ XFCE มาตั้งแต่ปี 2007 ผู้ใช้ไม่ได้สนภาษาไหนหรือเทคโนโลยีอะไรนักหรอก สิ่งที่ต้องการคือ “มันต้องใช้งานได้ดี”
      การย้ายไป Wayland เป็นสิ่งที่หลีกเลี่ยงไม่ได้ จะมีเสียงบ่นบ้างเล็กน้อยแต่ก็คงผ่านไปได้โดยไม่มีปัญหาใหญ่
      คนที่ยึดติดกับ X11 สุดท้ายก็จะเหลือเป็นคนกลุ่มน้อย ผมเชื่อมั่นทีม XFCE
    • ไม่เข้าใจว่า Wayland ทำไมถึง “ให้ความรู้สึกว่าเป็นอนาคต” เลย สำหรับผมมันกลับดูเหมือน การถอยหลังของฟีเจอร์ มากกว่า
      ทั้งที่มี GUI ที่ทำงานได้ดีอยู่แล้ว แต่ Wayland กลับสร้างความซับซ้อนและปัญหาความเข้ากันได้ที่ไม่จำเป็น
      โปรโตคอลที่เรียบง่ายมักอยู่รอดได้นาน แต่ Wayland กลับเป็นไปในทางตรงข้าม
    • ผมอยู่ฝั่ง “อย่าซ่อมสิ่งที่ไม่ได้เสีย”
      XFCE นั้นทั้งเร็วและเสถียรอยู่แล้ว ถ้าย้ายไป Wayland แล้วช้าลง ก็เท่ากับเสีย ข้อดีที่สำคัญที่สุด ไป
    • มองว่าการย้าย XFCE ไป Wayland จะ ใช้เวลาอีกนาน
      เพราะเป็นชุมชนที่ให้ความสำคัญกับเสถียรภาพ จึงน่าจะคง X11 เป็นค่าเริ่มต้นไว้ก่อน แล้วค่อยไป Wayland เมื่อได้ความเท่าเทียมของฟีเจอร์อย่างสมบูรณ์
    • ในฐานะผู้ใช้ XFCE มานาน ผมมองการเปลี่ยนแปลงครั้งนี้ในแง่บวก ตราบใดที่ยังไม่รีบทิ้ง X11
      หวังว่าเมื่อถึงวันที่จำเป็นต้องย้ายไป Wayland ผมจะยังใช้ XFCE ต่อได้

  • ผมคิดว่าตัวโครงการนี้เองแสดงให้เห็นว่า Wayland เป็นทิศทางที่ถูกต้อง
    Xorg เป็น implementation เดี่ยว แต่ Wayland ทำให้เกิด ecosystem ของไลบรารี ที่หลากหลายขึ้นมา เช่น wlroots, Smithay เป็นต้น
    ด้วยเหตุนี้ แม้แต่โปรเจ็กต์ที่มีคนทำเพียงคนเดียวก็ยังออก developer preview ได้ภายในไม่กี่เดือน
    การแข่งขันลักษณะนี้จะช่วยผลักดัน ecosystem โอเพนซอร์สให้ก้าวหน้า

    • เพราะ Wayland มีแต่ฟังก์ชันระดับล่าง จึงต้องรีบสร้าง อินเทอร์เฟซเดสก์ท็อปร่วมกัน ขึ้นมา
      แต่กระบวนการนี้เร่งเกินไปจนขาดความเป็นเอกภาพ ผมคิดว่ากว่าจะมี Linux desktop API ที่สมบูรณ์จริงๆ คงต้องใช้เวลา อีก 10 ปี
    • การมีหลาย implementation ทำให้เกิดการแข่งขันก็จริง แต่ก็อาจเกิดฟีเจอร์ขาดตกหล่นและภาวะหมดไฟจาก การขาดคนดูแลรักษา
      ผมคิดว่าการไม่มี libcompositor คือความผิดพลาดใหญ่ที่สุดของ Wayland
    • โค้ดที่ซ้ำกันคงเพิ่มขึ้น แต่ในทางกลับกันแต่ละทีมก็จะได้ทำ implementation ที่สอดคล้องกับปรัชญา ของตัวเอง
      ผมรอดูอยู่ว่าทีม XFCE จะทำอะไรออกมา
    • ตรรกะนี้ทำให้นึกถึงยุคที่ Rails ถูกใช้พร่ำเพรื่อ
      แม้สแตกจะสะดวก แต่สุดท้ายก็อาจกลายเป็น โครงสร้างที่แก้ลึกๆ ได้ยาก
    • แก่นสำคัญของ Wayland คือให้เคอร์เนลช่วยรับภาระงานไปมาก
      X นั้นแทบจะทำงานเหมือน เคอร์เนลตัวที่สอง แต่ Wayland ใช้ abstraction สมัยใหม่ในเคอร์เนลอย่าง GEM, DMA-BUF, KMS
      จึงมีทางพัฒนาไปสู่โครงสร้างที่สะอาดและมีประสิทธิภาพกว่ามาก

  • ผมใช้ XFCE เป็นเดสก์ท็อปหลักมามากกว่า 10 ปีแล้ว
    ดีใจที่มีข่าวรองรับ Wayland
    ถ้าเขียนด้วย Rust ก็น่าจะช่วยเรื่อง ดึงผู้ร่วมพัฒนาใหม่ๆ ได้ด้วย
    ถ้าต้องการสนับสนุน แนะนำให้บริจาคที่ Open Collective และ xfce-eu

    • ผมใช้ XFCE มา 5 ปีแล้ว และเพิ่งเริ่มสนับสนุนรายเดือนเมื่อไม่นานมานี้ ดีใจที่ได้ยินข่าวดีแบบนี้

  • ผมคิดว่าการเปลี่ยนจาก X11 ไป Wayland คือ การเปลี่ยนผ่านที่เจ็บปวดที่สุดในประวัติศาสตร์ลินุกซ์

    • ตอนเปลี่ยนจากเคอร์เนล 2.4 ไป 2.6 ก็หนักพอสมควรเหมือนกัน โมเดลการพัฒนาเปลี่ยนไปหมด และยุคก่อน git ก็ค่อนข้างโกลาหล
      ช่วง KDE4 ก็เป็นยุคมืดเหมือนกัน
    • สำหรับผม การเปลี่ยนจาก GNOME 2 → GNOME 3 ทรมานที่สุด สุดท้ายก็ย้ายไปใช้ WM อื่น
    • สำหรับผม การย้ายจาก X11 ไป Wayland นั้น ลื่นไหลมาก สุดท้ายมันก็ขึ้นอยู่กับความต้องการของแต่ละคน
    • อีก 8 ปี Wayland ก็คงเก่าเท่า X11 แล้ว และอาจได้เห็น Wayland 2 ก็ได้
    • การย้ายไป systemd ก็ไม่ได้ง่ายเลยเหมือนกัน

  • ผมเคยลองใช้ client toolkit ของ Smithay ที่เขียนด้วย Rust แต่พบว่า ความปลอดภัยด้านเธรด ยังไม่สมบูรณ์
    ต่อให้ห่อด้วย Arc<> แล้ว เวลาเรียกข้ามหลายเธรดก็ยังเกิดแครชแปลกๆ
    ผมอยากเรียนรู้วิธีลงลึกกับ Wayland API โดยตรงเพื่อใช้งานให้ปลอดภัย

  • ตอนนี้ก็ยังใช้ XFCE ได้บน คอมโพสิตเตอร์ที่อิง wlroots ส่วนใหญ่
    ผมใช้ชุด Hyprland + XFCE บน Gentoo อยู่
    การตั้งค่าอยู่ในรีโพนี้

    • ชอบธีมย้อนยุคดี
      แต่อยากรู้ว่าทำไมถึงเรียกชุด Hyprland + XFCE4 ว่าเป็น “การจับคู่ต้องสาป” น่าจะเกี่ยวกับเหตุผลที่ XFCE ตัดสินใจทำคอมโพสิตเตอร์ของตัวเองก็ได้

  • ครั้งหนึ่งผมเคยต่อต้าน Wayland แต่พอเห็น ประสิทธิภาพบนฮาร์ดแวร์เก่า ก็เปลี่ยนใจ
    บน Thinkpad รุ่นเก่า Firefox เลื่อนหน้าจอได้ลื่นกว่า X11 มาก
    แถมยังได้ gesture ของทัชแพดเพิ่มมาด้วย แม้การตั้งค่าจะยุ่งยากไปบ้าง แต่ก็เป็น trade-off ที่คุ้มค่า

  • สงสัยว่า Wayland ทำงานบน ระบบที่ไม่ใช่ลินุกซ์ ได้หรือไม่ เช่นบน BSD หรือ macOS จะสามารถเปิดหน้าต่างระยะไกลแบบ XQuartz ได้ไหม?

    • บน FreeBSD ใช้งานได้ค่อนข้างดี และบน OpenBSD ก็มีคอมโพสิตเตอร์ที่อิง wlroots บางตัวทำงานได้
      ยังมี Wayland compositor สำหรับ Mac ด้วย และ Brodie Robertson ก็เคยทำวิดีโอเกี่ยวกับเรื่องนี้ไว้
    • การรวม GUI ของ WSL2 ของ Microsoft ก็อิงกับ Wayland และ XWayland เช่นกัน
      ถ้าดู โปรเจ็กต์ WSLg จะเห็นว่า Weston ถูกเรนเดอร์ผ่าน RDP ทำให้แสดงหน้าต่างข้ามแพลตฟอร์มได้
      และยังคงมี GPU acceleration อยู่ด้วย ซึ่งผมคิดว่าดีกว่า X11 forwarding
    • Wayland ไม่มี network transparency ดังนั้นการส่งต่อแบบรีโมตจึงซับซ้อน สถานะบน Mac ก็ยังไม่แน่ชัด
    • ในคู่มือทางการของ FreeBSD ก็มีวิธีตั้งค่า Wayland อยู่
      FreeBSD Handbook Wayland
    • บน OpenBSD ก็มีการทดลองผ่านเอกสาร Wayland_on_OpenBSD

  • ทุกวันนี้พอได้ยินคำว่า “rewrite ด้วย Rust” ผมมักตีความว่าไม่มีคนดูแลรักษาแล้ว
    ดูเหมือนจะไม่มีใครคอยแพตช์ xfwm4 เลยต้องเขียนใหม่
    นี่อาจเป็นสัญญาณของการเปลี่ยนผ่านระหว่างรุ่นก็ได้ — นักพัฒนาใหม่ๆ อยากจัดโครงสร้างใหม่ให้ เรียบง่ายและปลอดภัย กว่าเดิม
    Wayland เรียบง่ายกว่า X11 และ Rust ก็ช่วยลดความผิดพลาดได้ จึงเป็นพัฒนาการที่เป็นธรรมชาติ
    แต่ราคาที่ต้องจ่ายอาจเป็น network transparency, ประสิทธิภาพ, และเสถียรภาพ ที่ลดลง ซึ่งก็คงต้องยอมรับว่าเป็นไปตามยุคสมัย