Log for Ubuntu 台灣社群
AMD Is Finally Fixing HDMI 2.1 On Linux
https://www.youtube.com/watch?v=g-dvzJ2GIYA
https://www.youtube.com/watch?v=g-dvzJ2GIYA
HDMI 2.1 顯示串流壓縮（Display Stream Compression，DSC）支援已就緒，可納入 AMDGPU Linux 驅動程式 （★ 57 分）
AMD 已將 HDMI 2.1 的 FRL（Fixed Rate Link，固定速率連線）支援修補程式擴充到 DSC（Display Stream Compression，顯示串流壓縮）功能，準備導入開放原始碼的 AMDGPU Linux 驅動程式。DSC 是一種低延遲、視覺上近乎無損的壓縮技術，可提升頻寬效率，讓 HDMI 2.1 在更高解析度與更新率下運作，例如 4K 240Hz 或 8K 120Hz。
Phoronix 指出，AMD 先前才送出 HDMI 2.1 FRL 支援，現在又加入 FRL DSC，代表 AMD 正朝完整 HDMI 2.1 實作推進。過去 HDMI Forum（HDMI 標準制定組織）被認為阻擋開放原始碼實作 HDMI 2.1，這次 AMD 為何能釋出相關程式碼仍不明朗；外界猜測可能與 Valve 參與協調或找到折衷方案有關。最新修補程式預計會隨下一批 AMDGPU Display Core（DC，顯示核心元件）修補程式送入，並很可能在 Linux 7.2 週期進入主線 Linux 核心。
Hacker News 討論聚焦在 HDMI 2.1 長期的授權與開放原始碼限制。多位留言者認為，這項進展不只對一般 Linux 桌機重要，也可能有助於 SteamOS 或未來 Steam Machine 類裝置透過 HDMI 達到 4K 120Hz。也有人批評 HDMI Forum 對開放實作態度保守，並指出 HDMI 牽涉 HDCP（High-bandwidth Digital Content Protection，高頻寬數位內容保護）與 DRM（Digital Rights Management，數位版權管理）等機制，可能是標準組織不願開放的背景之一。
也有留言者主張「改用 DisplayPort（DP，顯示連接埠）」可避開 HDMI 的法律與授權問題，但其他人補充，現實上多數電視沒有 DP，許多顯示器也只有一個 DP 輸入，筆電或切換多台電腦時仍常需要 HDMI。DP 轉 HDMI 2.1 轉接器也不是完美替代品：高解析度、高更新率、HDR（High Dynamic Range，高動態範圍）、VRR（Variable Refresh Rate，可變更新率）與 10-bit 色彩同時啟用時，可能遇到握手時間變長、無法連線、隨機黑畫面或 HDR 無法啟用等問題；部分晶片方案甚至需要刷入特定韌體，VRR 仍可能不穩。
針對 4K 240Hz 的必要性，討論中出現分歧：有人質疑電視或一般使用情境是否需要這麼高的更新率；也有人指出，若標準已能承載 8K 60Hz，理論上同等資料量的 4K 240Hz 不應被刻意封鎖。實際使用者則表示，120Hz 到 240Hz 的差異仍可感受到，但邊際效益明顯低於 60Hz 升到 120Hz。整體來看，社群普遍把 AMDGPU 即將取得完整 HDMI 2.1 能力視為 Linux 圖形堆疊的重要補強，尤其對客廳遊戲、電視輸出與高階顯示器使用者意義重大。
👥 33 則討論、評論 💬
https://news.ycombinator.com/item?id=48105874
AMD 已將 HDMI 2.1 的 FRL（Fixed Rate Link，固定速率連線）支援修補程式擴充到 DSC（Display Stream Compression，顯示串流壓縮）功能，準備導入開放原始碼的 AMDGPU Linux 驅動程式。DSC 是一種低延遲、視覺上近乎無損的壓縮技術，可提升頻寬效率，讓 HDMI 2.1 在更高解析度與更新率下運作，例如 4K 240Hz 或 8K 120Hz。
Phoronix 指出，AMD 先前才送出 HDMI 2.1 FRL 支援，現在又加入 FRL DSC，代表 AMD 正朝完整 HDMI 2.1 實作推進。過去 HDMI Forum（HDMI 標準制定組織）被認為阻擋開放原始碼實作 HDMI 2.1，這次 AMD 為何能釋出相關程式碼仍不明朗；外界猜測可能與 Valve 參與協調或找到折衷方案有關。最新修補程式預計會隨下一批 AMDGPU Display Core（DC，顯示核心元件）修補程式送入，並很可能在 Linux 7.2 週期進入主線 Linux 核心。
Hacker News 討論聚焦在 HDMI 2.1 長期的授權與開放原始碼限制。多位留言者認為，這項進展不只對一般 Linux 桌機重要，也可能有助於 SteamOS 或未來 Steam Machine 類裝置透過 HDMI 達到 4K 120Hz。也有人批評 HDMI Forum 對開放實作態度保守，並指出 HDMI 牽涉 HDCP（High-bandwidth Digital Content Protection，高頻寬數位內容保護）與 DRM（Digital Rights Management，數位版權管理）等機制，可能是標準組織不願開放的背景之一。
也有留言者主張「改用 DisplayPort（DP，顯示連接埠）」可避開 HDMI 的法律與授權問題，但其他人補充，現實上多數電視沒有 DP，許多顯示器也只有一個 DP 輸入，筆電或切換多台電腦時仍常需要 HDMI。DP 轉 HDMI 2.1 轉接器也不是完美替代品：高解析度、高更新率、HDR（High Dynamic Range，高動態範圍）、VRR（Variable Refresh Rate，可變更新率）與 10-bit 色彩同時啟用時，可能遇到握手時間變長、無法連線、隨機黑畫面或 HDR 無法啟用等問題；部分晶片方案甚至需要刷入特定韌體，VRR 仍可能不穩。
針對 4K 240Hz 的必要性，討論中出現分歧：有人質疑電視或一般使用情境是否需要這麼高的更新率；也有人指出，若標準已能承載 8K 60Hz，理論上同等資料量的 4K 240Hz 不應被刻意封鎖。實際使用者則表示，120Hz 到 240Hz 的差異仍可感受到，但邊際效益明顯低於 60Hz 升到 120Hz。整體來看，社群普遍把 AMDGPU 即將取得完整 HDMI 2.1 能力視為 Linux 圖形堆疊的重要補強，尤其對客廳遊戲、電視輸出與高階顯示器使用者意義重大。
👥 33 則討論、評論 💬
https://news.ycombinator.com/item?id=48105874
當「閒置」其實不閒置：Linux 核心的一項最佳化如何變成 QUIC 缺陷 （★ 101 分）
Cloudflare 的文章追蹤了其開源 QUIC（常用於 HTTP/3 的 UDP 基礎傳輸協定；UDP 是 User Datagram Protocol，使用者資料包協定）實作 quiche 中的一個 CUBIC 缺陷。CUBIC 是 Linux 預設的壅塞控制演算法（CCA, Congestion Control Algorithm），用壅塞視窗（cwnd, congestion window）限制同一時間已送出但尚未確認的資料量，並在偵測到封包遺失時降低傳送速率、網路穩定時逐步升高。Cloudflare 在本機 HTTP/3 下載測試中設定 10 MB 檔案、RTT（Round-Trip Time，往返延遲）10 ms、前 2 秒隨機遺失 30% 封包，之後完全停止遺失；下載原本應在 4 到 5 秒完成，卻有約 60% 在 10 秒逾時前無法完成。
透過 qlog（QUIC 連線記錄格式）分析後，團隊發現封包遺失在第 2 秒後已歸零，但 cwnd 仍卡在 2700 位元組，也就是兩個完整封包；壅塞狀態在恢復期與壅塞避免期之間於約 6.7 秒內切換 999 次，週期約 14 ms，接近連線 RTT。這表示問題不是網路仍在掉包，而是每輪 ACK（Acknowledgement，接收端確認封包）到達後，bytes_in_flight 會降到 0，伺服器再送出下一批兩個封包，讓 CUBIC 狀態機在 ACK 節奏下自我觸發。相同情境改用 Reno（另一種以封包遺失判斷壅塞的控制演算法）時成功率為 100%，也確認這是 CUBIC 特有問題。
根本原因來自 2017 年 Linux 核心為 CUBIC 加入的「閒置期間調整」：應用程式停止傳送一段時間後，不應讓 CUBIC 的 epoch（成長曲線的時間基準）累積過大的時間差，否則 cwnd 會被不合理地拉高；正確作法是把時間基準往後平移。quiche 在 2020 年移植這段邏輯時，少了 Linux 隨後補上的保護；又因 QUIC 在使用者空間執行，沒有 TCP（Transmission Control Protocol，傳輸控制協定）核心層的傳送開始事件，只能在送封包時用 bytes_in_flight == 0 判斷是否閒置。當 cwnd 降到兩個封包的底限，每個 ACK 都會讓 bytes_in_flight 短暫歸零，但這其實是壅塞受限而非閒置；舊邏輯把 now - last_sent_time、約一個 RTT 的間隔誤算成閒置時間，把恢復起點推到未來，使 CUBIC 認定自己一直在恢復期並跳過 cwnd 成長。
修正方式是新增 last_ack_time，ACK 到達時更新它；送封包且 bytes_in_flight 為 0 時，改以 last_ack_time 與 last_sent_time 中較晚者作為真正的閒置起點，避免把整個 RTT 當成閒置時間。修正後，恢復邊界不再追著下一次送出時間跑，cwnd 會沿著預期的 CUBIC 曲線成長，100 次測試恢復全數成功，下載約 4 到 5 秒完成。Cloudflare 的結論是，「閒置」在小視窗與 ACK 節奏下不容易定義，最小 cwnd 是容易被忽略的角落案例；這次排查花了大量 qlog 儀表化與視覺化分析，但最後只改了很少的程式碼。文章也提到 quiche 持續用模組化設計調校 BBRv3（Bottleneck Bandwidth and Round-trip propagation time v3，估算瓶頸頻寬與延遲的模型式壅塞控制）。
Hacker News 討論的主要反應偏向工程流程檢討：高分留言認為這更像是「把 Linux 核心程式碼搬進 quiche，卻沒有完整理解並追上後續修補」的教訓；也有人指出，自行維護使用者空間實作時，必須更密切追蹤上游核心變更，因為這類實作的審視者通常少於 Linux 核心。另有讀者質疑 Cloudflare 為何 CUBIC 仍是 quiche 預設，認為在資料中心大頻寬環境下，CUBIC 從嚴重壅塞恢復太慢，BBR 類方法可能更合適；但也有人補充 quiche 並不是從既有 Linux QUIC 改寫而來，因為 quiche 約 2018 年就開始，Linux 核心 QUIC 實作到 2025 年才出現，較早的核心層 QUIC 例子主要是 Microsoft 的 MsQuic。其他討論則指出原文未定義 CCA、部分段落有明顯 AI 風格，並提出若短時間反覆退避，演算法是否應自動降低退避幅度與成長速度，以追求更高總傳輸量。
👥 12 則討論、評論 💬
https://news.ycombinator.com/item?id=48116064
Cloudflare 的文章追蹤了其開源 QUIC（常用於 HTTP/3 的 UDP 基礎傳輸協定；UDP 是 User Datagram Protocol，使用者資料包協定）實作 quiche 中的一個 CUBIC 缺陷。CUBIC 是 Linux 預設的壅塞控制演算法（CCA, Congestion Control Algorithm），用壅塞視窗（cwnd, congestion window）限制同一時間已送出但尚未確認的資料量，並在偵測到封包遺失時降低傳送速率、網路穩定時逐步升高。Cloudflare 在本機 HTTP/3 下載測試中設定 10 MB 檔案、RTT（Round-Trip Time，往返延遲）10 ms、前 2 秒隨機遺失 30% 封包，之後完全停止遺失；下載原本應在 4 到 5 秒完成，卻有約 60% 在 10 秒逾時前無法完成。
透過 qlog（QUIC 連線記錄格式）分析後，團隊發現封包遺失在第 2 秒後已歸零，但 cwnd 仍卡在 2700 位元組，也就是兩個完整封包；壅塞狀態在恢復期與壅塞避免期之間於約 6.7 秒內切換 999 次，週期約 14 ms，接近連線 RTT。這表示問題不是網路仍在掉包，而是每輪 ACK（Acknowledgement，接收端確認封包）到達後，bytes_in_flight 會降到 0，伺服器再送出下一批兩個封包，讓 CUBIC 狀態機在 ACK 節奏下自我觸發。相同情境改用 Reno（另一種以封包遺失判斷壅塞的控制演算法）時成功率為 100%，也確認這是 CUBIC 特有問題。
根本原因來自 2017 年 Linux 核心為 CUBIC 加入的「閒置期間調整」：應用程式停止傳送一段時間後，不應讓 CUBIC 的 epoch（成長曲線的時間基準）累積過大的時間差，否則 cwnd 會被不合理地拉高；正確作法是把時間基準往後平移。quiche 在 2020 年移植這段邏輯時，少了 Linux 隨後補上的保護；又因 QUIC 在使用者空間執行，沒有 TCP（Transmission Control Protocol，傳輸控制協定）核心層的傳送開始事件，只能在送封包時用 bytes_in_flight == 0 判斷是否閒置。當 cwnd 降到兩個封包的底限，每個 ACK 都會讓 bytes_in_flight 短暫歸零，但這其實是壅塞受限而非閒置；舊邏輯把 now - last_sent_time、約一個 RTT 的間隔誤算成閒置時間，把恢復起點推到未來，使 CUBIC 認定自己一直在恢復期並跳過 cwnd 成長。
修正方式是新增 last_ack_time，ACK 到達時更新它；送封包且 bytes_in_flight 為 0 時，改以 last_ack_time 與 last_sent_time 中較晚者作為真正的閒置起點，避免把整個 RTT 當成閒置時間。修正後，恢復邊界不再追著下一次送出時間跑，cwnd 會沿著預期的 CUBIC 曲線成長，100 次測試恢復全數成功，下載約 4 到 5 秒完成。Cloudflare 的結論是，「閒置」在小視窗與 ACK 節奏下不容易定義，最小 cwnd 是容易被忽略的角落案例；這次排查花了大量 qlog 儀表化與視覺化分析，但最後只改了很少的程式碼。文章也提到 quiche 持續用模組化設計調校 BBRv3（Bottleneck Bandwidth and Round-trip propagation time v3，估算瓶頸頻寬與延遲的模型式壅塞控制）。
Hacker News 討論的主要反應偏向工程流程檢討：高分留言認為這更像是「把 Linux 核心程式碼搬進 quiche，卻沒有完整理解並追上後續修補」的教訓；也有人指出，自行維護使用者空間實作時，必須更密切追蹤上游核心變更，因為這類實作的審視者通常少於 Linux 核心。另有讀者質疑 Cloudflare 為何 CUBIC 仍是 quiche 預設，認為在資料中心大頻寬環境下，CUBIC 從嚴重壅塞恢復太慢，BBR 類方法可能更合適；但也有人補充 quiche 並不是從既有 Linux QUIC 改寫而來，因為 quiche 約 2018 年就開始，Linux 核心 QUIC 實作到 2025 年才出現，較早的核心層 QUIC 例子主要是 Microsoft 的 MsQuic。其他討論則指出原文未定義 CCA、部分段落有明顯 AI 風格，並提出若短時間反覆退避，演算法是否應自動降低退避幅度與成長速度，以追求更高總傳輸量。
👥 12 則討論、評論 💬
https://news.ycombinator.com/item?id=48116064
沒這個 CVE 我還真不知道記事本有支援 markdown XD
https://www.cve.org/CVERecord?id=CVE-2026-20841
https://www.cve.org/CVERecord?id=CVE-2026-20841