Phoenix - เซิร์ฟเวอร์ X สมัยใหม่ที่เขียนขึ้นใหม่ทั้งหมดด้วย Zig

 (git.dec05eba.com)
2 คะแนน โดย GN⁺ 2025-12-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Phoenix คือ เซิร์ฟเวอร์ X แบบใหม่ที่เขียนขึ้นใหม่ทั้งหมดด้วยภาษา Zig โดยไม่ได้ fork มาจาก Xorg เดิม และมุ่งเป็นทางเลือกสมัยใหม่
  • ปัจจุบันสามารถรัน แอปพลิเคชันเรียบง่ายที่ใช้กราฟิก GLX, EGL, Vulkan แบบ nested ภายในเซิร์ฟเวอร์ X เดิมได้ แต่ยังไม่รองรับการรันแบบสแตนด์อโลน
  • เพื่อความเรียบง่าย จึงรองรับเฉพาะแอปพลิเคชันที่เขียนในช่วง 20 ปีหลังและฮาร์ดแวร์ในช่วง 15 ปีหลัง และทำงานได้โดยไม่มีอินเทอร์เฟซไดรเวอร์ฝั่งเซิร์ฟเวอร์
  • เสริม ความปลอดภัย ด้วยการแยกวิเคราะห์ข้อความโปรโตคอลอัตโนมัติ และจำกัดการเข้าถึงระหว่างแอปด้วย โครงสร้างแยกการทำงานแบบอิงการขอสิทธิ์
  • รองรับเทคโนโลยีสมัยใหม่อย่าง HDR, VRR, หลายจอ, คอมโพสิตเตอร์ในตัว และมีแผนรองรับความเข้ากันได้กับ Wayland รวมถึงส่วนขยายโปรโตคอล X11

ภาพรวมของ Phoenix

  • Phoenix เป็นเซิร์ฟเวอร์ X สมัยใหม่เพื่อใช้แทน Xorg โดยเป็น อิมพลีเมนเทชันที่เขียนขึ้นใหม่ทั้งหมดด้วยภาษา Zig
    • ไม่ใช่การ fork จาก Xorg และมุ่งไปที่ โครงสร้างที่เรียบง่ายและปลอดภัยกว่า
  • ขณะนี้ยังไม่อยู่ในระดับที่ใช้งานได้เต็มรูปแบบ และรองรับเฉพาะ การรันแบบ nested mode ภายในเซิร์ฟเวอร์ X เดิม
    • สามารถทำ การเรนเดอร์เร่งด้วยฮาร์ดแวร์ ที่อิง GLX, EGL, Vulkan ได้

เป้าหมาย

ความเรียบง่าย

  • เป็นเซิร์ฟเวอร์ที่เรียบง่ายกว่า Xorg โดย รองรับเพียงบางส่วนของโปรโตคอล X11
    • รวมเฉพาะฟีเจอร์ที่จำเป็นสำหรับแอปพลิเคชันที่เขียนในช่วง 20 ปีหลัง
  • มุ่งรองรับเฉพาะฮาร์ดแวร์ในช่วง 15 ปีหลังที่รองรับ Linux DRM และ Mesa GBM
  • ไม่ใช้อินเทอร์เฟซ ไดรเวอร์ฝั่งเซิร์ฟเวอร์ แยกต่างหากเหมือน Xorg
    • มีโครงสร้างคล้าย Wayland compositor

ความปลอดภัย

  • ทำให้ปลอดภัยขึ้นด้วย การแยกวิเคราะห์ข้อความโปรโตคอลอัตโนมัติ
    • ผ่านตัวเลือกบิลด์ ReleaseSafe ของ Zig ซึ่งช่วย ตรวจจับการทำงานที่ไม่ถูกต้องโดยอัตโนมัติ เช่น การเข้าถึงเกินขอบเขตของดัชนีอาร์เรย์
  • โดยค่าเริ่มต้น แอปพลิเคชันจะทำงานแบบ แยกจากกัน
    • การโต้ตอบกับแอปอื่นทำได้เฉพาะผ่าน การขอสิทธิ์ทาง GUI หรือ การให้สิทธิ์ล่วงหน้า เท่านั้น
    • ตัวอย่าง: แอปบันทึกหน้าจอจะบันทึกได้เฉพาะหน้าต่างที่ระบุ
  • เมื่อมีการจำกัดการเข้าถึง ไคลเอนต์จะได้รับ ข้อมูลจำลอง แทนข้อผิดพลาด
  • ปุ่มลัดแบบโกลบอล จะทำงานเมื่อมีปุ่ม modifier รวมอยู่ด้วย (เช่น ctrl, shift)
    • หากต้องการใช้ปุ่มลัดแบบโกลบอลโดยไม่มี modifier จะต้องมีสิทธิ์อย่างชัดเจน
  • สามารถสลับกลับไปเป็น พฤติกรรมแบบเดียวกับ Xorg ได้ผ่านตัวเลือก

การรองรับเทคโนโลยีสมัยใหม่

  • รองรับเทคโนโลยีจอภาพสมัยใหม่ เช่น หลายจอ, อัตรารีเฟรชต่างกัน, VRR, HDR
  • ประมวลผลแยกอิสระตามแต่ละจอ แทนการใช้ framebuffer เดียว

การปรับปรุงการประมวลผลกราฟิก

  • ให้ การเรนเดอร์แบบไม่มี tearing และ คอมโพสิตเตอร์ในตัว เป็นค่าเริ่มต้น
    • หากมีการรันคอมโพสิตเตอร์ภายนอก (เช่น picom) จะปิดการทำงานอัตโนมัติ
    • หากแอปแบบเต็มหน้าจอปิด vsync ระบบจะปรับให้เหมาะกับแอปนั้น
  • มีเป้าหมายเพื่อลด latency ของ vsync และคอมโพสิตเตอร์

มาตรฐานใหม่

  • กำหนดและจัดทำเอกสาร คุณสมบัติ DPI ต่อจอ (randr property)
    • เพื่อให้แอปพลิเคชันสามารถสเกลคอนเทนต์ตาม DPI ของแต่ละจอได้

ส่วนขยายโปรโตคอล X11

  • มีแผนจะขยายโปรโตคอล X11 เมื่อจำเป็นต่อ ฟีเจอร์ใหม่อย่าง HDR เป็นต้น

ความเข้ากันได้กับ Wayland

  • คำนึงถึงกรณีที่บางแอปอาจรองรับเฉพาะ Wayland
    • Phoenix อาจ รองรับ Wayland โดยตรง หรือรันผ่าน Wayland–X11 bridge (เช่น 12to11) ได้

เซิร์ฟเวอร์แสดงผลแบบ nested

  • สามารถ รันแบบ nested พร้อมการเร่งด้วยฮาร์ดแวร์ภายใน X11 หรือ Wayland ได้
    • มีประโยชน์ต่อการดีบัก Phoenix และ การทดสอบ window manager·compositor
    • สามารถใช้เป็น เซิร์ฟเวอร์ทางเลือกของ Xwayland ในสภาพแวดล้อม Wayland ได้

สิ่งที่ไม่ใช่เป้าหมาย (Non-goals)

  • การแทนที่เซิร์ฟเวอร์ Xorg อย่างสมบูรณ์ ไม่ใช่เป้าหมาย
    • Xorg จะยังคงรองรับฟีเจอร์ X11 ได้มากกว่าและฮาร์ดแวร์รุ่นเก่า
  • ไม่รองรับ หลาย X11 screens (รองรับเฉพาะหลายจอ)
  • การเรียก GrabServer จะไม่มีผล
  • เรื่อง ไคลเอนต์/เซิร์ฟเวอร์แบบ endian swap จะพิจารณาใหม่เมื่อจำเป็น
  • ไม่รองรับ indirect GLX (การเรนเดอร์ระยะไกล)
    • มีความซับซ้อนสูง และการสตรีมระยะไกลมีประสิทธิภาพมากกว่า
    • หากจำเป็น สามารถทำการเรนเดอร์ระยะไกลผ่าน GLX proxy ได้

ความแตกต่างจากโปรโตคอล X11

  • บางส่วนของโปรโตคอลแกนหลัก X11 ยังไม่ได้อิมพลีเมนต์ เช่น ฟีเจอร์เกี่ยวกับฟอนต์
  • การเข้ารหัสสตริงใช้ UTF-8 เป็นค่าเริ่มต้น
    • อย่างไรก็ตาม หากโปรโตคอลระบุเป็น ISO Latin-1 อย่างชัดเจนจะเป็นข้อยกเว้น

การติดตั้งและการบิลด์

  • คำสั่งติดตั้ง: 
    zig build -Doptimize=ReleaseSafe
sudo zig build install -p /usr/local -Doptimize=ReleaseSafe
  • การถอนการติดตั้งต้องลบ /usr/local/bin/phoenix ด้วยตนเอง
  • บิลด์สำหรับการพัฒนา: 
    zig build
    • ไบนารีที่ได้: ./zig-out/bin/phoenix
    • สามารถรันและบิลด์พร้อมกันได้ด้วย: zig build run

การสร้างเอกสารโปรโตคอล X11

  • คำสั่ง: zig build -Dgenerate-docs=true
    • ผลลัพธ์: สร้างไฟล์ .txt ใน ./zig-out/protocol/
    • เป็นเอกสารที่สร้างอัตโนมัติในรูปแบบสไตล์เอกสารทางการ และ ยังเป็นฟีเจอร์ที่กำลังดำเนินการอยู่

การพึ่งพา

  • Zig 0.14.1
  • x11 (xcb) — สำหรับโหมด nested ของ X11 (-Dbackends=x11)
  • wayland (wayland-client, wayland-egl) — สำหรับโหมด nested ของ Wayland (-Dbackends=wayland, ยังไม่รองรับในปัจจุบัน)
  • drm (libdrm, gbm) — สำหรับการรันแบบสแตนด์อโลน (-Dbackends=drm, ยังไม่รองรับในปัจจุบัน)
  • OpenGL (libglvnd) — ให้ gl และ egl

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

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

 
GN⁺ 2025-12-25
ความคิดเห็นบน Hacker News

  • แนวทางที่จะปรับโครงสร้าง X server ใหม่ใน สไตล์ Wayland น่าสนใจมาก
    การรวม display server กับ compositor เข้าด้วยกันเป็นพื้นฐาน, แยกแอปออกจากกันโดยปริยาย, ตัดความสามารถรีโมตของ GLX ออก, และกล้าทิ้งโปรโตคอลรุ่นเก่า เป็นสิ่งที่น่าประทับใจ
    ไม่แน่ใจว่าใครบ้างที่จะต้องการสิ่งนี้ แต่ตัวเลือกนี้ก็ดูสมเหตุสมผลไม่น้อย

    • สำหรับคนที่ยังจำเป็นต้องใช้ X11 มันดูเป็นตัวเลือกที่ดีกว่า XLibre
    • ยังไม่ได้ลองใช้เอง แต่ถ้าตัดฟีเจอร์เดิมออกไป สุดท้ายก็คงกลายเป็นสถานการณ์คล้าย Wayland
      ถ้าอย่างนั้นก็ไม่แน่ใจว่าความต่างคืออะไร อาจเป็นเพราะการวิเคราะห์ของฉัน ยังไม่ครบถ้วน
    • ถ้าสิ่งนี้ออกมาตั้งแต่ก่อนหน้านี้กว่านี้ หลายคนน่าจะเลือกมันแทน Wayland
      ยิ่งถ้ารันแอป Wayland ได้ด้วย ก็อาจมีผู้ใช้เลือกมันมากกว่าเดิมจริง ๆ

  • ชื่อ Phoenix ถูกใช้เยอะเกินไปแล้ว
    มีทั้ง Phoenix ในเฟรมเวิร์ก Elixir และก็จำได้ว่าเคยเห็นในโปรเจกต์อื่นอีกหลายครั้ง
    มันเป็นชื่อที่โหลพอ ๆ กับ ‘Apollo’ เลยคิดว่าถ้าจะทำโปรเจกต์ใหม่ควรค้นหาชื่อก่อน

    • Phoenix ใน ecosystem ของ Elixir กลับถือว่าสับสนน้อยกว่าด้วยซ้ำ
      ฝั่งนั้นมีชื่อแปลก ๆ เยอะอย่าง bandit, cowboy, thousand island, ranch, mint, finch
      แล้วก็ยังมี ชื่อซ้ำกัน แบบ ExThing, ThingEx, Thingx บ่อยจนงงว่าอะไรคือมาตรฐาน
    • แต่ก่อนผู้คนใช้ชื่อ Phoenix บ่อยในความหมายเชิงสัญลักษณ์ว่าเป็น โปรเจกต์ที่ฟื้นคืนจากเถ้าถ่าน
      จำได้ว่าแม้แต่ในยุค 1980s ก็มีการตั้งชื่อซอฟต์แวร์ใหม่แบบนี้
    • Firefox ก็เคยจะใช้ชื่อ Phoenix แต่โดนฟ้องเรื่อง เครื่องหมายการค้า
      ใน wxPython ก็มีโปรเจกต์ Phoenix เหมือนกัน เป็นชื่อที่เท่แต่ใช้กันเยอะเกินไป

  • โปรเจกต์นี้เจ๋งมาก
    ฉันชอบ Wayland แต่ก็ยังรู้สึกคาใจกับ portal protocol และกลไกส่วนขยาย
    เมื่อเทียบกับ Windows หรือ macOS ยังมีจุดที่ด้อยกว่าในแง่ productivity
    การเขียน X11 ใหม่โดยมีความปลอดภัยฝังมาในตัว เป็นแนวทางที่น่าคาดหวัง

    • ฉันคิดมานานแล้วว่าการทำ X เวอร์ชันที่ถูกจัดระเบียบใหม่แทน Wayland น่าจะดีกว่า
      ดูเป็นโปรเจกต์ที่มีประโยชน์ และหวังว่าจะพัฒนาไปได้ดี
    • คุณบอกว่า Wayland ด้อยด้าน productivity อยากรู้ว่า ขาดอะไรไปบ้าง
    • ผมกลับคิดว่า Windows หรือ macOS เองยัง จัดการหน้าต่าง ได้ไม่ดีด้วยซ้ำ
      เมื่อต้นทศวรรษ 2000 แค่ติดตั้งยังยาก และแทบเป็นไปไม่ได้เลยสำหรับผู้ใช้ทั่วไปที่จะติดตั้งเอง
      Linux distro ติดตั้งง่ายกว่ามาก และเหตุผลที่ Windows ช้าลงแล้วคนต้องซื้อ PC ใหม่ก็เพราะแบบนั้น
    • สำหรับฉันกลับไม่ได้รู้สึกว่า Wayland ขาดด้าน productivity
      ที่บริษัทก็ทำงานบน GNOME + Wayland ได้โดยไม่มีปัญหา

  • ยินดีที่ได้เห็น โปรเจกต์อนุรักษ์ X แบบนี้
    แม้จะชอบ Wayland มากกว่า แต่ก็ยังคิดว่ามีบางพื้นที่ที่ X ยังจำเป็นอยู่
    ทีมพัฒนาใหม่ควรมาช่วยแบ่งภาระ

    • แต่ก็มองว่าทางเลือกแบบนี้จะนำไปสู่ ความกระจัดกระจาย
      ถึงเวลาฝัง X11 ไปให้หมดและโฟกัสกับ display server เดียวแล้ว

  • ไม่รู้ว่าโปรเจกต์นี้จะทำงานได้ดีแค่ไหน แต่
    ท่ามกลางกระแสรวมศูนย์โดยองค์กร (เช่น Wayland, GNOME, KDE ที่มีนักพัฒนาได้เงินเดือน)
    ผมคิดว่าการมี โปรเจกต์คู่แข่ง เพิ่มขึ้นเป็นเรื่องดี
    และก็สงสัยว่าถ้าจะทำ Xorg ให้ทันสมัยต้องใช้เงินทุนมากแค่ไหน
    Wayland ออกมาตั้งแต่ปี 2008 แต่ผ่านมาเกือบ 20 ปีก็ยังตอบโจทย์ผู้ใช้ได้ไม่ครบ
    การพยายามทำให้ตรงกับสเปกแคบ ๆ ที่องค์กรต้องการทำให้เห็นข้อจำกัดชัดเจน

  • นักพัฒนาแอปสามารถระบุ release mode ใน build script เป็นรูปแบบ zig build --release ได้
    หรือผู้ใช้จะส่ง --release เองก็ได้
    ดูเหมือนผู้เขียน Phoenix จะเลือก โหมด ReleaseSafe เป็น release ทางการ
    อีกอย่าง Phoenix ก็เป็นชื่อบ้านเกิดของผมด้วย

  • gpu-screen-recorder ที่ผู้เขียนคนเดียวกันทำ
    คือ โปรแกรมอัดหน้าจอที่ดีที่สุด ที่ผมเคยใช้บน Wayland
    อัด 4K 60fps ได้ทันทีแทบไม่ต้องตั้งค่าอะไร

  • สงสัยว่า แอป X11 รุ่นเก่า อย่าง xterm, emacs, xfig, ghostview จะใช้งานได้ไหม

    • โปรแกรม X11 เก่า ๆ ส่วนใหญ่พึ่งพา X11 drawing API
      จึงมีโอกาสสูงว่าจะทำงานได้ไม่สมบูรณ์ แต่ตัว implementation เองไม่ได้ซับซ้อน

  • เห็นว่าระบุว่าไม่ตั้งเป้ารองรับหลายหน้าจอ
    งั้นก็สงสัยว่าจะใช้กับ window manager ที่รองรับ virtual desktop (อย่าง i3) ไม่ได้หรือเปล่า

    • ใน X11 คำว่า “screen” มีความหมายเฉพาะ ดังนั้นถึงจะรองรับแค่ single screen
      ก็ไม่ได้มีปัญหากับการใช้หลายจอหรือ virtual desktop
    • โครงสร้างแบบนี้สามารถเพิ่มความสามารถมัลติมอนิเตอร์ต่อเนื่องอย่าง Xinerama ได้ ไม่ยากในภายหลัง

  • น่าสนใจที่มันไม่ได้ใช้ XML protocol spec เพื่อ generate โค้ดแบบเดียวกับ Xorg