Niri 26.04: คอมโพสิตเตอร์ Wayland แบบไทลิงเลื่อนต่อเนื่อง

 (github.com/niri-wm)
2 คะแนน โดย GN⁺ 3 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คอมโพสิตเตอร์ Wayland แบบไทลิงเลื่อนต่อเนื่อง ได้รับการปรับปรุงรอบด้านทั้งการเบลอพื้นหลัง การสกรีนแคสต์ การเรนเดอร์ และการจัดการอินพุต ทำให้ความสมบูรณ์ของระบบสูงขึ้น
  • การเบลอพื้นหลัง ถูกรวมเข้าเมนไลน์แล้ว ทำให้หน้าต่างและองค์ประกอบ layer-shell ที่รองรับ ext-background-effect สามารถขอใช้เอฟเฟ็กต์เบลอได้โดยไม่ต้องตั้งค่า niri เพิ่มเติม และยังสามารถบังคับใช้การเบลอด้วยกฎฝั่ง niri ได้ด้วย
  • การสกรีนแคสต์ ถูกปรับปรุงทั้งในเส้นทาง PipeWire และ wlr-screencopy ครอบคลุมตั้งแต่การจัดการเคอร์เซอร์ วิธีเริ่ม dynamic cast การตรวจสอบและบังคับยุติผ่าน IPC ตลอดจนปัญหาการคัดลอกหลายชุดและการคืนทรัพยากร
  • โครงสร้างการเรนเดอร์ ถูกปรับใหม่จากแบบอิง iterator เป็นแบบ push-based ทำให้การสร้างรายการเรนเดอร์เร็วขึ้น 2–3 เท่าบนเครื่องหลัก และเร็วขึ้น 8 เท่าบน Eee PC รุ่นเก่า พร้อมลดการใช้หน่วยความจำลง
  • ฮาร์ดแวร์รุ่นเก่าและสภาพแวดล้อมอินพุต ก็ได้รับการปรับแก้เช่นกัน ทำให้รองรับการใช้งานจริงได้กว้างขึ้น ทั้งการจับภาพหน้าจอและสกรีนแคสต์บนระบบ Intel เก่า ปัญหาชนกันของ IME กับป๊อปอัป GTK 4 เมาส์อัตรารีเฟรชสูงและการแมปแท็บเล็ต รวมถึงการเร่งความเร็ว DMA-BUF ของ niri แบบ nested

การเปลี่ยนแปลงหลัก

  • องค์กรบน GitHub ถูกย้ายจากบัญชีส่วนตัวไปยัง niri-wm และมีการจัดระเบียบโปรเจ็กต์ที่เกี่ยวข้องไปพร้อมกัน
    • awesome-niri: รายการโปรเจ็กต์ที่เกี่ยวข้อง
    • artwork: รวมแบดจ์และวอลเปเปอร์
  • มีการเปลี่ยนแปลงที่เกี่ยวข้องกับผู้จัดแพ็กเกจด้วย
    • Rust เวอร์ชันขั้นต่ำที่รองรับถูกยกขึ้นเป็น 1.85
    • niri.service ไม่ฮาร์ดโค้ดพาธ /usr/bin/ ของไบนารี niri อีกต่อไป
    • โครงสร้างไฟล์บริการ dinit เปลี่ยนไป: 3bfa4a7

การเบลอพื้นหลัง

  • การเบลอพื้นหลัง ถูกนำเข้าเมนไลน์แล้ว และหน้าต่างกับองค์ประกอบ layer-shell สามารถขอใช้การเบลอผ่านโปรโตคอล ext-background-effect
    • เชลล์และแอปหลายตัวใช้งานได้ทันทีโดยไม่ต้องตั้งค่า niri เพิ่มเติม
    • Dank Material Shell v1.4.5: เปิดใช้งานได้ในการตั้งค่า
    • Noctalia เชลล์: มีการตั้งค่าและเอกสาร
    • รองรับ launcher ของ Vicinae
    • foot v1.26: blur=true
    • kitty v0.46.2: background_blur 1
    • Ghostty: มีกำหนดรองรับใน v1.4
    • Quickshell: มีกำหนดรองรับใน v0.3
    • winit: มีกำหนดรองรับใน v0.31
  • แม้แอปจะยังไม่รองรับ ext-background-effect ก็ยังเปิด การเบลอ ได้จากฝั่ง niri ผ่าน window-rule และ layer-rule
    • รายละเอียดการตั้งค่าและข้อจำกัดถูกรวบรวมไว้ในเอกสาร Window Effects
    • การเบลอที่ตั้งค่าจาก niri ต้องใช้ geometry-corner-radius ที่ถูกต้อง
    • ไม่ทำงานกับ surface ที่มีรูปทรงซับซ้อน
  • มีทั้ง xray blur และ blur แบบทั่วไป โดยค่าเริ่มต้นคือ xray blur
    • xray blur จะคำนวณการเบลอวอลเปเปอร์เพียงครั้งเดียว แล้วนำกลับมาใช้ซ้ำเหมือนภาพนิ่ง จึงมีประสิทธิภาพสูงกว่ามาก
    • จะคำนวณใหม่เฉพาะตอนที่วอลเปเปอร์เปลี่ยนเท่านั้น
    • หากใช้วอลเปเปอร์แบบแอนิเมชัน ข้อได้เปรียบด้านประสิทธิภาพจะลดลง
    • ตัวจับคู่ layer ใหม่ช่วยให้เปลี่ยนไปใช้ blur แบบทั่วไปเฉพาะเลเยอร์อย่าง top หรือ overlay ได้
  • ฟีเจอร์เบลอนี้มีความซับซ้อนในการพัฒนาสูงจนต้อง เปลี่ยนโครงสร้างการเรนเดอร์
    • blur แบบทั่วไปต้องอ่านพิกเซลที่เรนเดอร์ไปแล้วกลับมาเบลอระหว่างเฟรม แล้วจึงเรนเดอร์ต่อ
    • xray blur ต้องส่งตำแหน่งหน้าต่างไปทั่วโค้ดเรนเดอร์เพื่อให้ตัดพื้นหลังได้อย่างถูกต้อง
    • ต้องรองรับ xray blur ใน Overview พร้อมคงคุณสมบัติที่ไม่ต้องเรนเดอร์ overview ซ้ำ
    • ต้องทำงานร่วมกับ หน้าต่างบล็อกการสกรีนแคสต์ ได้ด้วย
  • สามารถใช้ xray เพียงอย่างเดียวโดยไม่เปิด blur ได้ และยังใช้ noise เพื่อลดแถบสีจาก blur กับเอฟเฟ็กต์ saturation แยกกันได้ด้วย
  • บล็อก popups ใหม่ทำให้สามารถใช้ความโปร่งใสและเอฟเฟ็กต์พื้นหลังกับเมนูป๊อปอัปได้ใน window rule หรือ layer rule
    • หากไม่ใช่สี่เหลี่ยมมุมมน เช่น ป๊อปอัป GTK 4 ที่ has-arrow=true รูปร่างอาจดูแปลกตา
    • เว็บแอปหรือ Electron ไม่ใช้ป๊อปอัป Wayland จึงไม่สามารถให้ niri จัดการได้
    • ไคลเอนต์ที่ติดตั้ง ext-background-effect โดยตรงสามารถจัดการการเบลอในรูปทรงที่ซับซ้อนกว่าได้

include แบบเลือกได้

  • config include เพิ่ม include แบบเลือกได้
    • หากเขียนแบบ include optional=true "optional-config.kdl" ต่อให้ไม่มีไฟล์อยู่ ก็จะไม่ทำให้การโหลดคอนฟิกล้มเหลว
    • หากไม่มีไฟล์ จะมีการบันทึกคำเตือนทุกครั้งที่รีโหลดคอนฟิก แต่ยังโหลดคอนฟิกต่อไปได้
    • หากภายหลังมีไฟล์ถูกสร้างขึ้น การเปลี่ยนแปลงที่กำลังเฝ้าดูอยู่จะถูกตรวจพบและรีโหลดให้อัตโนมัติ
    • แต่ถ้าไฟล์มีอยู่แล้วและมีข้อผิดพลาดทางไวยากรณ์ ก็ยังถือว่าแยกวิเคราะห์ไม่สำเร็จเหมือนเดิม
  • ในพาธของ include จะมีการขยาย ~ เป็นโฮมไดเรกทอรี
    • ~/file.kdl จะถูกขยายเป็น /home/user/file.kdl

การวาร์ปพอยน์เตอร์และการเลื่อน

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

การปรับปรุงการสกรีนแคสต์

  • การสกรีนแคสต์ของ niri ได้รับการปรับปรุงทั้งในแบบ xdg-desktop-portal-gnome ผ่าน PipeWire และแบบผ่าน wlr-screencopy

  • การจัดการเคอร์เซอร์ในการสกรีนแคสต์หน้าต่าง

    • รองรับ metadata ของเคอร์เซอร์ บน PipeWire แล้ว แทนการวาดเคอร์เซอร์ลงในเฟรมวิดีโอโดยตรง
      • เฟรมวิดีโอจะไม่รวมเคอร์เซอร์ แต่จะส่งไอคอนเคอร์เซอร์และพิกัดไปในบัฟเฟอร์แยกต่างหาก
      • ฝั่งผู้ใช้ข้อมูลอย่าง OBS หรือเบราว์เซอร์จะเป็นผู้วาดเคอร์เซอร์เอง
    • ใช้งานได้ทั้งกับการจับภาพหน้าจอและการจับภาพหน้าต่าง
    • ในการจับภาพหน้าต่าง เคอร์เซอร์จะแสดง เฉพาะเมื่อชี้อยู่บนหน้าต่างนั้นหรือป๊อปอัปของมันจริง ๆ เท่านั้น
    • ไอคอน drag-and-drop จะถูกวาดไปด้วย
    • ระหว่างการพัฒนา ยังพบและแก้ไข ปัญหาหน่วยความจำเสียหาย ของ PipeWire ด้วย
    • ยังพบความไม่สอดคล้องกันระหว่างเจตนาการออกแบบของ PipeWire กับการทำงานฝั่งผู้ใช้ข้อมูล เช่น libwebrtc
    • ในสภาพแวดล้อมที่ทดสอบ ทำงานได้ตามปกติ
    • สามารถรวมตัวชี้ในภาพหน้าจอของหน้าต่างได้ด้วย screenshot-window show-pointer=true

  • เปลี่ยนวิธีเริ่มต้น Dynamic cast target

    • Dynamic cast target คือฟีเจอร์สำหรับสลับเป้าหมายการสกรีนแคสต์ได้ทันทีด้วยคีย์ไบน์ดิง
    • ก่อนหน้านี้จะเริ่มต้นด้วยสตรีมวิดีโอพิกเซลดำขนาด 1×1
    • ตอนนี้จะ หน่วงการเริ่มสตรีมวิดีโอไว้จนกว่าจะเลือกเป้าหมายจริงตัวแรก
    • ช่วยเลี่ยงปัญหาวิดีโอ 1×1 ชั่วขณะใน Microsoft Teams ได้

  • Cast IPC

    • ตอนนี้สามารถตรวจสอบการสกรีนแคสต์ที่กำลังทำงานอยู่ผ่าน IPC ได้
    • ดู cast ที่กำลังทำงานได้ด้วย niri msg casts
    • สามารถสมัครรับ cast events ได้จาก event stream
    • ออบเจ็กต์ Cast ให้ข้อมูลชนิด เป้าหมายปัจจุบัน และสถานะการทำงาน
    • การสกรีนแคสต์ผ่าน PipeWire ให้ค่า node ID ส่วน wlr-screencopy ให้ค่า client process ID
    • DankMaterialShell ใช้ IPC นี้เพื่อแสดงตัวบ่งชี้การสกรีนแคสต์อยู่แล้ว
    • สามารถบังคับหยุดการสกรีนแคสต์ผ่าน PipeWire ได้ด้วย niri msg action stop-cast --session-id <ID>

  • ข้อจำกัดและการแก้ไขที่เกี่ยวข้องกับ wlr-screencopy

    • wlr-screencopy ไม่มีวิธีแยกความต่างระหว่างการสกรีนแคสต์กับการจับภาพหน้าจออย่างมั่นคง จึงต้องอาศัย heuristic บางส่วน
    • xdg-desktop-portal-wlr จะคง wlr-screencopy manager object เดิมไว้ตลอด ทำให้รู้เวลาสิ้นสุดได้ยากในทันที
    • ปัญหาเหล่านี้ได้รับการแก้ในโปรโตคอลใหม่ ext-image-copy-capture แต่ niri ยังไม่ได้รองรับ

  • การแก้ไขการสกรีนแคสต์อื่น ๆ

    • แก้ปัญหาที่ระหว่างคัดลอก damage นั้น ไคลเอนต์ wlr-screencopy จะได้เคอร์เซอร์ติดมาด้วยเสมอแม้ไม่ต้องการ
    • แก้พฤติกรรมตอนร้องขอการคัดลอกหลายเฟรมที่มี damage พร้อมกัน
    • แก้ปัญหาที่ข้อมูล wlr-screencopy ของ niri ไม่ถูกปล่อยในบางกรณี เช่น เมื่อตัวไคลเอนต์ปิดตัวลง
    • ลดจำนวนบัฟเฟอร์สกรีนแคสต์ PipeWire เริ่มต้นจาก 16 เหลือ 8
    • ปรับลำดับฟิลด์ของ struct เพื่อหลีกเลี่ยงปัญหา use-after-free ใน pipewire-rs
    • แก้งานเรนเดอร์ที่ z-order ผิดอยู่หนึ่งเฟรมเมื่อสลับเป้าหมาย dynamic cast ไปเป็นหน้าต่าง

แอนิเมชันและการทำงานของหน้าต่าง

  • การซิงก์แอนิเมชัน มีความแม่นยำมากขึ้น
    • niri สามารถตั้งค่าแอนิเมชันแต่ละแบบแยกกันได้ แต่หากมีกรณีที่ต้องตรงกันอย่างแม่นยำ ก็จะซิงก์ให้ทำงานร่วมกัน
    • แอนิเมชันเปลี่ยนขนาดหน้าต่างจะถูกซิงก์กับแอนิเมชันเลื่อนมุมมองแนวนอนที่มันเป็นตัวกระตุ้น
    • แก้ปัญหาที่ตอนออกจาก fullscreen หรือ maximize ไม่มีการซิงก์การเลื่อนมุมมอง ทำให้หน้าต่างกลับมาทันทีแต่หน้าจอยังเลื่อนช้า ๆ
  • แก้ ปัญหาที่แอนิเมชันการเลื่อนแนวนอนของหน้าต่างแบบไทล์อื่นถูกข้ามไป ในบางเส้นทางการลาก
    • เป็นปัญหาที่เกิดเมื่อดึงหน้าต่างที่ maximize อยู่ให้ออกจากสถานะนั้น แล้วถ้าเดิมเป็นหน้าต่างลอยก็ให้กลับไปเป็น floating อีกครั้ง และ
    • เกิดร่วมกับตรรกะเลื่อน workspace ซ้ายขวาเมื่อมีการลากใกล้ขอบจอจนซ้อนทับกัน
    • คอมมิตที่แก้ไข: df3f3979e936ed6800b4fbd55843bb0fe2554f15
  • แก้ปัญหาที่เมื่อดึงคอลัมน์ซ้ายสุดของ workspace ออกมาแล้วปล่อยกลับ จะ ไปอยู่ทางขวาแทนที่จะกลับตำแหน่งเดิม
  • ระยะเวลาการแสดงการแจ้งเตือนข้อผิดพลาดของการตั้งค่า ถูกเปลี่ยนให้ ไม่รับผลจากการตั้งค่า slowdown/speedup ของแอนิเมชัน

IME และป๊อปอัป

  • แก้ปัญหาเก่าที่ ช่องกรอกข้อมูลในป๊อปอัปของ GTK 4 กับ IME ทำงานร่วมกันไม่ได้ ด้วยวิธีอ้อม
    • ก่อนหน้านี้ หากเปิด IME อย่าง Fcitx5 อยู่ จะไม่สามารถเปิดป๊อปอัปสำหรับกรอกข้อความได้
    • ป๊อปอัปจะจับ grab ของพอยน์เตอร์และคีย์บอร์ด ขณะที่ IME ก็ใช้ keyboard grab เช่นกัน จึงเกิดการชนกัน
    • ทำให้ niri ทิ้ง popup grab และป๊อปอัปมักปิดทันที
    • มีการผ่อนเงื่อนไขการตรวจสอบบางส่วนเพื่อให้ทำงานได้ โดยไม่ต้องปรับโครงสร้างของ Smithay ทั้งหมด
    • ตอนนี้ผู้ใช้ IME สามารถทำงานอย่างการเปลี่ยนชื่อไฟล์ใน Nautilus ได้แล้ว

Drag-and-drop และอุปกรณ์ป้อนข้อมูล

  • ตอน drag-and-drop สามารถกด Escape เพื่อยกเลิกได้แล้ว
  • ยังมีการแก้ไขหลายอย่างในส่วนอุปกรณ์ป้อนข้อมูลโดยรวม
    • แก้ปัญหาที่ระบบช้าลงเรื่อย ๆ เมื่อใช้เมาส์ polling rate สูงร่วมกับ hide-after-inactive-ms หรือเดมอนตรวจจับ idle
    • ใน libwayland-server v1.23 ขึ้นไป จะเพิ่มขนาดบัฟเฟอร์ Wayland เพื่อลดโอกาสที่หน้าต่างจะแครชอย่างรวดเร็วเมื่อขยับเมาส์ polling rate สูงบนหน้าต่างที่ไม่ตอบสนอง
    • เพิ่มตัวเลือกแท็บเล็ต map-to-focused-output เพื่อแมปไปยังเอาต์พุตที่โฟกัสอยู่ในปัจจุบันแทนเอาต์พุตเดี่ยวที่กำหนดตายตัว
    • แก้ปัญหาที่เคอร์เซอร์ชี้ไปยังหน้าต่างที่ maximize ไม่ได้อย่างแม่นยำเสมอที่พิกเซลบนสุดของ workspace
    • แก้ปัญหาที่ Alt-Tab ตอบสนองต่ออินพุตเมาส์ก่อนจะแสดงบนหน้าจอ
    • การเลื่อนแบบ on-button-down ของ trackball ใช้งานใน overview ได้ด้วย
    • รักษาสถานะ Num Lock ไว้แม้หลังโหลด คีย์แมป .xkb แบบกำหนดเอง
    • แก้ปัญหาที่ไม่สามารถใช้อุปกรณ์ป้อนข้อมูลได้เลยเมื่อเริ่มจาก TTY อื่นผ่าน tmux
    • เปิดใช้งานการโหลด libinput plugins

การทำ GPU profiling และการเพิ่มประสิทธิภาพการเรนเดอร์

  • มีการเพิ่ม การผนวกรวม GPU profiling สำหรับ Tracy ที่ใช้ใน Smithay และ niri
    • มีการเพิ่มงานใน Smithay สำหรับส่ง GPU timestamp query, เก็บค่าที่เสร็จแล้ว และส่งต่อไปยัง Tracy: PR งานนี้
    • ตอนนี้สามารถทำเครื่องหมายช่วงเวลาได้ทั้งงาน GPU ภายใน Smithay และงาน GPU ของ compositor เอง
    • สามารถติดตามได้ว่าการเรนเดอร์ DRM buffer และการเรนเดอร์ PipeWire screencast buffer ซ้อนทับกันอย่างไรภายในเฟรมเดียว
    • ในระบบ multi-GPU ก็สามารถดูแทร็กแยกตาม GPU ได้
    • ทำให้ยืนยันได้ว่าประสิทธิภาพ blur ไม่ได้ช้ากว่าที่คาด และช่วยวิเคราะห์ dropped frame จากคอขวดในการเรนเดอร์ของ GPU ได้ง่ายขึ้น
  • วิธีประกอบ render list ถูกปรับโครงสร้างใหม่จากแบบอิง iterator ไปเป็นแบบ push
    • เดิมทีมีการประกอบ render element ในรูปแบบ -> impl Iterator<Item = ...>
    • มีความซับซ้อนหลายอย่าง เช่น เงื่อนไขการแตกแขนง, lifetime, การยืม &self, การชนกันกับ &mut Renderer, การจอง Vec ระหว่างทาง และปัญหาข้ามขอบเขต crate
    • โครงสร้างใหม่ใช้วิธีที่ฟังก์ชันเรนเดอร์รับ push: &mut dyn FnMut(Element) แล้วส่ง element เข้าไป
    • ฟังก์ชันชั้นกลางยังคงรักษา logic เดิมได้ด้วยคลोजเชอร์ที่ห่อ push ชั้นบนไว้อีกที
    • ทำให้ไม่ต้องมี Vec ชั่วคราว และปัญหา borrowing ก็หายไป
    • ใน niri ข้อดีเรื่องหยุด iterator ก่อนกำหนดนั้นไม่ได้จำเป็นในทางปฏิบัติ
  • รีแฟกเตอร์นี้ทำให้ ความเร็วในการประกอบ render list เพิ่มขึ้นมาก
    • บนเครื่องหลักเร็วขึ้น 2~3 เท่า
    • บน Eee PC รุ่นเก่าเร็วขึ้น 8 เท่า
    • การประกอบ render list ไม่ใช่เวลาเรนเดอร์บน GPU โดยตรง แต่เพราะมันถูกรันบ่อยแม้ไม่ต้องวาดหน้าจอใหม่ ผลของการปรับปรุงจึงมีมาก
    • การใช้หน่วยความจำก็ลดลง และการจัดสรรในเส้นทางใหม่ส่วนใหญ่เหลือแค่การขยาย output vector
    • ดูแรงจูงใจและ diff แบบละเอียดได้ใน PR

การรองรับฮาร์ดแวร์รุ่นเก่า

  • พบว่าสาเหตุที่ screenshot ล้มเหลวบนโน้ตบุ๊ก Intel รุ่นเก่ามาจาก ค่า OpenGL enum ที่ผิดใน Smithay และได้แก้ไขแล้ว: PR วิเคราะห์สาเหตุ
  • มีการปรับแต่ง shader ของ niri เล็กน้อย ทำให้แม้แต่บน GPU ที่มีข้อจำกัดของ ASUS Eee PC รุ่นเก่ามากก็สามารถใช้งาน
    • แอนิเมชันปรับขนาดหน้าต่าง
    • มุมโค้งของ compositor
    • ได้แล้ว

การปรับปรุงอื่น ๆ

  • แก้ปัญหา VRAM รั่ว ที่เกิดบนบางระบบหลังปิดแอปบางตัว
  • เพิ่มโปรโตคอล ext-foreign-toplevel-list ทำให้เครื่องมืออย่าง Quickshell เชื่อมโยงอ็อบเจ็กต์หน้าต่าง Wayland กับ niri IPC window ID ได้ง่ายขึ้น
  • หากมีข้อผิดพลาด bind ซ้ำในคอนฟิก จะแสดง ตำแหน่งที่ประกาศครั้งแรก ของ bind เดียวกันด้วย
  • แสดง grabbing cursor เมื่อทำการลากหน้าต่างด้วย Mod+LMB
  • เพิ่มอาร์กิวเมนต์ --path ให้กับ niri msg action load-config-file เพื่อสลับไปใช้ไฟล์คอนฟิกอื่นระหว่างรันไทม์ได้
  • เพิ่ม การรองรับ DMA-BUF ให้ nested niri ทำให้ hardware acceleration กลับมาทำงานได้อีกครั้งหลัง Mesa เลิกใช้ wl_drm
  • เอา padding ที่ niri เคยใส่ให้กับ layer-shell popup ใกล้ขอบจอออก
  • รวมการเปลี่ยนแปลงของคอนฟิกเริ่มต้นด้วย
    • Mod+M: maximize-window-to-edges
    • Mod+Shift+R: switch-preset-column-width-back
  • เพิ่มแฟล็กดีบัก force-disable-connectors-on-resume เพื่อบังคับให้หน้าจอเป็น blank ตอนสลับ TTY หรือกลับจากโหมดพักเครื่อง
  • แก้ให้มุมหน้าต่างในโหมด windowed fullscreen ถูกเรนเดอร์เป็น มุมฉาก อย่างถูกต้อง
  • แก้ปัญหาที่หน้าจอถูกวาดซ้ำต่อเนื่องขณะ overview เปิดอยู่
  • ปรับการเรนเดอร์ gradient border ของ relative-to=workspace-view เล็กน้อยระหว่างการลากแบบโต้ตอบ
  • ปรับแต่งการเรนเดอร์คีย์ลัด diaeresis ในกล่องโต้ตอบ Important Hotkeys
  • แก้คำอธิบาย expel-window-from-column ของ niri msg action ให้ตรงกับพฤติกรรมจริงว่าเป็น การไล่หน้าต่างด้านล่างออก
  • แก้ panic หลายกรณีที่อาจเกิดเมื่อไคลเอนต์พยายามใช้ output ที่เพิ่งถูกถอดออกไปล่าสุด
  • แก้ปัญหาการเรนเดอร์เสียหายเมื่อใช้ clip-to-geometry ร่วมกับไคลเอนต์ที่แนบ buffer แบบ y_invert
  • แก้การบิลด์บน OpenBSD
  • เปลี่ยนให้ nested niri ตั้งค่า app-id ของหน้าต่างตัวเอง
  • เมื่อมีการเสียบ GPU ใหม่ จะมีการประเมินค่าดีบัก ignore-drm-device ใหม่ ทำให้ใช้ symbolic link ใต้ /dev/dri/by-path/ ได้ด้วย

อัปเดตตาม Smithay

  • การอัปเดต Smithay ยังนำการปรับปรุงพื้นฐานหลายอย่างเข้ามาด้วย
    • ปรับปรุง การเลือก GPU อัตโนมัติ บนอุปกรณ์บางชนิด เช่น ARM Mac
    • Asahi และ Pinephone ใช้งานได้ทันทีโดยไม่ต้องตั้งค่า render-drm-device เอง
    • การทำงานของไคลเอนต์ layer-shell บางตัวอย่าง wl_shimeji ดีขึ้น
    • ปรับปรุงการรองรับ dock ที่โหลด EDID ของจอภาพล่าช้า
    • screenshot และ screencast ใช้งานได้บนระบบ Intel รุ่นเก่า
    • แก้ปัญหาที่ output เก่ายังค้างอยู่เมื่อถอด USB-C dock ระหว่างโหมดพักเครื่อง
    • แก้ panic ของ zxdg_exporter_v2 ในไคลเอนต์บางตัว
    • แก้ memory leak ของไคลเอนต์ที่ไม่ได้ทำลาย clipboard protocol อย่างชัดเจน
    • แก้ panic ที่เกี่ยวกับ text-input content hint และ purpose ซึ่งเริ่มเกิดใน GTK 4.23 รุ่นพัฒนา
    • ทั้ง drag-and-drop, IME text input, multi-GPU และประสิทธิภาพโดยรวมก็ได้รับการปรับปรุงด้วย

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

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

 
GN⁺ 3 일 전
ความคิดเห็นจาก Hacker News

  • ชอบ Niri มากจนย้ายมาใช้เมื่อราว 5 เดือนก่อน แล้วรู้สึกว่านี่เป็นหนึ่งในการตัดสินใจที่ดีที่สุดในช่วงหลายปีมานี้ที่ เลิกใช้ Windows
    รู้สึกขอบคุณผู้สร้างมากจริงๆ
    เดิมที dotfiles ของฉันมีสคริปต์ติดตั้งสำหรับตั้งค่าเครื่องมือ CLI, สลับธีม ฯลฯ และตอนนี้บนสาย Arch ก็รองรับ Niri แบบครบถ้วนแล้ว
    ถ้าอยากลองใช้เดสก์ท็อปสภาพแวดล้อมใหม่แบบเริ่มได้ไว https://github.com/nickjj/dotfiles เป็นจุดเริ่มต้นที่ดีมาก
    ตอนนี้ใช้ทั้งบนเดสก์ท็อปหลักและโน้ตบุ๊กที่พกเดินทาง

    • เหมือนกันเลย และชุด จอโค้ง ultrawide กับ Niri เข้ากันได้ดีมากเป็นพิเศษ
    • อยากให้ลองดู Nirimod ด้วย
      ไม่เป็นทางการ แต่ยอดเยี่ยมจริงๆ
    • Omarchy เพิ่ม สวิตช์โหมด scrollable แยกตาม workspace แบบนี้เข้ามา
      กด Win/Cmd + L เพื่อสลับระหว่าง tiling กับ scrolling และตอนนี้ฉันใช้บ่อยมาก

  • Niri ทำให้ฉันได้รู้จัก การจัดการหน้าต่างแบบอิงการเลื่อน เป็นครั้งแรก และเข้าใจแนวคิดได้ทันที
    ไม่นานมานี้ OmniWM บน Mac เพิ่มโหมดจำลอง Niri แบบเต็มต่อ workspace และโชคดีที่ใช้กับ Sequoia ได้ด้วย เลยกลายเป็น window manager หลักของฉันทันที
    [1] https://github.com/BarutSRB/OmniWM

    • Paneru เป็นเครื่องมือใหม่บน macOS ที่ทำมาเพื่อเลียนแบบ Niri โดยเฉพาะ
    • ฉันก็คล้ายกัน
      ตอนรู้จักแนวทางของ Niri ครั้งแรกก็ชอบมาก และคอยมองหาสิ่งที่คล้ายกันบน Mac มาตลอด
      นี่คือ implementation ที่ดีที่สุด เท่าที่เคยใช้มา และแม้จะมี quirks เล็กๆ น้อยๆ อยู่บ้าง แต่สำหรับฉันอย่างน้อยก็ใช้เป็น daily driver ได้สบาย
      โดยเฉพาะ tabbed columns ที่ดีมากจริงๆ
      ขอปรบมือให้ผู้ดูแลและผู้ร่วมพัฒนา

  • ถ้าใช้ Mac ฉันแนะนำ OmniWM
    มันไม่ได้มีแค่เลย์เอาต์สไตล์ Niri แต่ยังมีเลย์เอาต์ที่ใกล้กับ Hyprland มากกว่าอีกด้วย และทำให้การทำงานบน macOS สะดวกขึ้นมาก
    https://github.com/BarutSRB/OmniWM
    เคยโพสต์ถึงมันตอนเพิ่งเริ่มใช้เหมือนกัน แต่พอใช้ต่อเนื่องแล้วพบว่าดีจริง เลยแนะนำได้แบบหนักแน่น

    • ขอโทษนะ แต่วิดีโอเดโมนั้นคือ วิดีโอเดโมที่แย่ที่สุด เท่าที่ฉันเคยเห็นในชีวิต
      ดูแล้วไม่น่าจะมีใครอยากลองใช้ซอฟต์แวร์นี้ และต่อให้เป็นผู้ใช้อยู่แล้วก็คงอยากลบทิ้ง

  • ฉันใช้ PaperWM extension สำหรับ GNOME อยู่ และคิดว่า Niri ก็น่าจะได้แรงบันดาลใจจากตรงนี้
    มันเป็นรูปแบบการทำงานที่น่าสนใจแน่นอน แต่พอมีหน้าต่างเกิน 3 อันใน workspace เดียวก็เริ่มรู้สึกเกะกะ เลยยังไม่ถึงขั้นรักมันทั้งหมด
    ถึงอย่างนั้นก็ยังใช้งานจริงจังอยู่ และการที่มันเป็น GNOME extension ทำให้ยังใช้ GNOME DE ที่เหลือได้เหมือนเดิมโดยไม่ต้องตั้งค่าเยอะเกินไป ซึ่งเป็นข้อดี

    • ฉันอยากย้ายไป Niri มาสักพักแล้ว แต่ขั้นตอนตั้งค่า องค์ประกอบเสริม มักกินเวลาหลายวันเสมอ
      เพราะต้องจัดการทั้ง top bar, idle timeout, การแจ้งเตือน และอย่างอื่นทั้งหมด
      แต่ไม่นานมานี้ฉันเพิ่งรู้ว่ามี desktop shell สำหรับ Wayland อยู่ ซึ่งให้สิ่งที่คนคาดหวังจากสภาพแวดล้อมอย่าง GNOME ได้เกือบทั้งหมดโดยไม่ต้องลำบากมาก
      มีทั้งหน้าต่างตั้งค่า, app tray, การมอนิเตอร์ทรัพยากร, top bar ครบหมด
      ตอนนี้ฉันใช้ dank material shell และคิดว่าการเอา desktop shell กับ compositor มาผสมกันได้อย่างอิสระนี่เจ๋งมาก
    • ฉันก็เหมือนกัน ชอบตรงที่ PaperWM เป็น GNOME extension ที่ไม่รุกล้ำมาก
      นอกจาก workflow โดยรวมจะดีขึ้นแล้ว มันยังช่วยให้ฉันลบ extension อื่นอย่าง desktop grid ออกไปได้อีกสองสามตัวด้วย

  • ฉันชินกับการสลับระหว่าง workspace แบบ fullscreen หลายอันอย่างรวดเร็ว และกับ workflow ของ tiling WM ที่ จัดการหน้าต่างด้วยคีย์บอร์ดล้วน ไปแล้ว
    ปกติจะมีแอปหนึ่งตัวต่อ workspace หรือไม่ก็เทอร์มินัลหนึ่งหน้าต่างที่เปิด tmux อยู่ แล้วค่อยมีบางครั้งที่วางสองแอปเคียงกัน
    เลยอยากรู้มากว่าคนที่ย้ายไป Niri จาก workflow คล้ายๆ กันนั้น mental model เปลี่ยนไปอย่างไร

    • ฉันใช้ workspace แยกตามกิจกรรม/โปรเจกต์ มาตลอด ทั้งบน KDE, GNOME และ Niri
      เช่น workspace หนึ่งมี Steam กับวิกิเกม, อีกอันมี Emacs กับเบราว์เซอร์เอกสาร, อีกอันมี Godot กับแอปทำเกม
      ข้อดีของ Niri คือแทบไม่มีแรงกดดันว่าหน้าต่างเยอะเกินไปแล้วต้องปิดอะไรสักอย่าง
      มันแยกและจัดระเบียบได้ค่อนข้างง่าย
      ฉันไม่ค่อยเข้าใจว่าทำไมต้องมี workspace แยกตามแอป
      และก็ไม่ชอบที่ Firefox หนึ่งตัวมีทั้งแท็บงานและแท็บงานอดิเรกปนกัน
    • ฉันเป็น ผู้ใช้ tiling มาค่อนข้างนาน และการจัดวางก็คล้ายๆ กัน
      เคยใช้ awesome, qtile, xmonad ช่วงสั้นๆ จากนั้นก็ i3 แล้วพอย้ายไป Wayland ก็ใช้ sway และลอง hyprland อยู่นิดหน่อย
      สิ่งที่เจอเสมอคือพอมีหน้าต่างเกิน 3 อัน การจัดแนวนอนจะไม่ค่อยเวิร์ก และการแบ่งแนวตั้งก็เล็กเกินไป
      แต่ในขณะเดียวกันก็มีบ่อยครั้งที่อยากเปิดหน้าต่างใหม่ข้างสิ่งที่กำลังอ่านอยู่ หรือเปิดกราฟ ipython ข้างเทอร์มินัล
      ทุกครั้งก็ต้องจับไปกองใน stacked layout หรือย้ายไป workspace ใหม่ ทำให้เกิดแรงเสียดทานพอสมควร และ workflow มักสะดุดเพราะการจัดการหน้าต่าง
      ใน Niri แค่เปิดหน้าต่างใหม่ มันก็จะโผล่มาในตำแหน่งที่ต้องการ ส่วนหน้าต่างอื่นยังคงอยู่ทางซ้ายขวาให้เลื่อนไปหาได้
      ตอนนี้ workflow ของฉันดูรกกว่าเมื่อก่อนนิดหน่อย แต่กลับชอบแบบนั้น
      tiling WM แบบเดิมๆ ต้องการการจัดระเบียบและก็ช่วยให้ทำได้ง่าย แต่ใน Niri ไม่จำเป็นต้องจัดก็ได้
      ถ้าบางครั้งหาหน้าต่างไม่เจอ ฉันก็ใช้ overview และยังผูก การค้นหาหน้าต่าง เข้ากับ rofi ไว้ด้วย
      ตอนแรกฉันยังใช้ workspace แบบตั้งชื่อตามนิสัยจากสมัย sway แต่ตอนนี้ไม่ใช้แล้ว
    • ฉันย้ายมาจาก KDE ด้วย workflow ที่แทบเหมือนกัน
      workspace 1 เป็นเทอร์มินัล fullscreen ที่เปิด zellij, 2 เป็นเบราว์เซอร์, 3 มีแอปแชตราวสองตัว และสลับไปมาด้วยคีย์ลัด
      ตอนแรกใช้ Niri เพราะมันเบากว่า Plasma และให้ความรู้สึกต่างออกไป แต่ตอนนี้ workflow ก็เปลี่ยนไปนิดหน่อย
      หน้าต่างส่วนใหญ่ยังคงใช้ขนาดเต็มจอ โดย 1 คือพัฒนางาน, 2 คือเบราว์เซอร์และบางครั้งมีตัวอ่านเมล, 3 คือแอปแชต จัดคล้ายเดิม
      แต่เวลาอยากพิมพ์คำสั่งสั้นๆ หรือเปิดงานที่รันยาว ฉันเปิด หน้าต่างเทอร์มินัลใหม่ บ่อยขึ้นมาก
      บน KDE หน้าต่างเหล่านี้จะซ้อนอยู่ด้านหลัง แต่ตอนนี้มันมาอยู่เรียงกันใน workspace 1
      พอมองย้อนกลับไป วิธีสลับด้วย Alt-Tab รู้สึกอึดอัดมากแล้ว ส่วนการไล่ด้วย Super-hjkl เบากว่ามาก
      แน่นอนว่าคนเราต่างกัน แต่ความรู้สึกที่หน้าต่าง ถูกวางไว้ข้างกัน แทนที่จะซ้อนทับกัน ทำให้ workflow เบาขึ้นจริงๆ
    • อันนั้นจริงๆ ดูจะใกล้กับการใช้ fullscreen ร่วมกับ workspace มากกว่า tiling
      ถ้าใช้ manual tiling WM อย่าง i3 หรือ sway กับจอใหญ่ คุณสามารถแบ่งจอเป็นหลายโซนงาน แล้ววางหลายแอปตามบทบาทในแต่ละโซนเพื่อลดจำนวน workspace ได้
      scrolling คล้ายกันแต่ก็เป็น workflow อีกแบบ โดยเฉพาะเวลาต้องการความยืดหยุ่นบนหน้าจอเล็ก
    • ฉันมองว่า หนึ่งแอปต่อหนึ่ง workspace ไม่ค่อยมีความหมายใน tiling WM
      workflow แบบนั้นเหมาะกับ floating WM มากกว่า
      จุดแข็งจริงๆ ของ tiling WM คือการ tile หน้าต่างจริงๆ และสำหรับฉัน holy trinity ของเบราว์เซอร์, เอดิเตอร์, เทอร์มินัล ที่มองเห็นพร้อมกันคือหัวใจสำคัญ
      และต้องย้ายตำแหน่งเชิงพื้นที่ด้วย super+hjkl หรือปุ่มลูกศรได้
      เพราะงั้น workspace แยกตามโปรเจกต์จึงดูเป็นธรรมชาติกว่าและเป็น workflow แบบ tiling WM มากกว่า
      Niri ทำสิ่งนี้ได้ดีกว่ามาก เพราะมันเปิดหน้าต่างใหม่ไปทางขวาโดยไม่ทำลายเลย์เอาต์ปัจจุบัน
      เช่น ต่อให้เปิด PDF ก็ยังคงโครงเดิมไว้และขยับไปหน้าต่างใหม่ได้ง่าย

  • นี่คือลิงก์ที่เกี่ยวข้อง
    The dank case for scrolling window managers - https://news.ycombinator.com/item?id=46820468 - Jan 2026 (61 comments)
    Niri 25.11 released with alt-tab and other improvements - https://news.ycombinator.com/item?id=46097051 - Nov 2025 (1 comment)
    Niri – A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=45461500 - Oct 2025 (229 comments)
    The Future Is Niri - https://news.ycombinator.com/item?id=43342178 - March 2025 (216 comments)
    Niri: A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=37367687 - Sept 2023 (37 comments)

  • ถ้าอยากลอง NNN (Niri-Nix-Noctalia) dots ก็เอา flake ของฉันไปใช้ได้เลย
    https://github.com/MostlyKIGuess/nix-flake-public

    • ฉันใช้ window manager มาหลายปี แต่สุดท้ายก็กลับไปใช้เดสก์ท็อปสภาพแวดล้อมแบบครบชุด เพราะกำแพงของการต้องไปแตะ การตั้งค่านอกตัว WM เองทั้งหมด
      แค่เรื่องอย่างโหมดมืดก็ต้องลงแรงเยอะแล้ว และ Noctalia ก็ดูเหมือนจะไปในทิศทางที่ฉันต้องการพอดี
      ขอบคุณที่พูดถึงมัน

  • ฉันใช้ wl-only branch ของ mangowm (บน wlroots 0.20) อยู่
    มันใช้ทรัพยากรน้อยกว่ามาก มีเลย์เอาต์มากกว่า และมีปัญหาน้อยกว่า
    ฝั่ง Niri อาจดูมีลูกเล่นด้านภาพมากกว่า แต่ก็ถือว่าคุ้มค่าที่จะลอง
    ถ้าต้องการ HDR ยังต้องรอต่อไป
    https://github.com/mangowm/mango

    • อยากรู้ว่า ปัญหา ที่น้อยกว่านั้นหมายถึงอะไรบ้าง
      สำหรับฉัน Niri นิ่งมากจริงๆ

  • ฟังดูเหมือนมี อัจฉริยะชาวรัสเซีย คนหนึ่งทำสิ่งที่ดีกว่า Claude token มูลค่า 100 ล้านดอลลาร์ เสียอีก
    แน่นอนว่าไม่ได้เป็นอาการคลั่งหมู่เลยแม้แต่น้อย ทุกคนก็เลยควรไปซื้อ SPY กันสินะ

    • น่าจะเป็น อัจฉริยะ จริงๆ
      แค่อ่าน release notes ก็สวยงามในตัวมันเองแล้ว

  • ช่วงปลายปีที่แล้วฉันย้ายจาก i3 หลังใช้มานานกว่า 10 ปีมาเป็น Niri
    การเลื่อนแนวนอนที่ไม่ผูกกับขนาดจอ และจำนวน workspace ที่ไม่ผูกกับจำนวนคีย์ลัดที่ตั้งไว้ ให้ความรู้สึกเป็นอิสระมาก
    งานด้านกราฟิกก็ทำได้ดีด้วย
    แต่ข้อที่ยังค้างคาอยู่คือ compatibility layer สำหรับ X อย่าง xwayland-satellite ยังไม่รองรับ drag and drop ระหว่างแอป X กับแอป Wayland
    [1]: https://davidyat.es/2026/01/28/niri/
    [2]: https://github.com/Supreeeme/xwayland-satellite/issues/133

    • ฉันก็อยู่ในสถานการณ์คล้ายกัน
      เมื่อก่อนฉันมีนิสัยวางของเดิมๆ ไว้ใน workspace เดิมเสมอ เลยจำได้ง่าย แต่ตอนนี้การจัดวางมันกระจายไปทั่วมากขึ้น
      และก็คิดถึง scratch มากพอสมควร
      เหมือนถ้าขยันปรับแต่ง config เพิ่มอีกหน่อยก็น่าจะแก้ได้ แต่ตอนนี้ยังไม่ได้ลงเวลาไปกับมัน