哪一層在把你的螢幕調暗：硬體、軟體，還是都不是
兩個 App 都可以顯示「亮度 40%」，畫面卻可以完全不同。原因是亮度由不同的層承載，而其中只有一層碰得到背光。
四種狀態
一個能用的實作必須把這四種狀態顯式建模，因為整件事的關鍵就是「從硬體往下跳到軟體」。它們不能互相替換：
- 硬體——面板自己的背光透過 DDC/CI 回應。這是真正的亮度：畫素背後的光變少了，黑還是黑。
- 軟體——改寫伽馬表。畫面變暗，背光沒變。在 contrast 為 1 時它是純縮放，黑仍然是黑；一旦對比低於 1 就不是了——對比那一項繞 0.5 旋轉，把斜坡底部推到零以上，而那個才是讓黑變成深灰的原因，不是調光本身。
- 不可用——什麼都不行。誠實的做法是直接說出來，而不是假裝一個滑桿在起作用。
- 未知——還沒探測過。它和「不可用」是兩回事，這是有意的：一個是「我們問了，面板說不」，另一個是「我們還沒問」。
為什麼「未知」不能等於「不可用」
把這兩者合併，就是 App 在一塊它從未試過的顯示器上，提前告訴你「不支援」。分開它們只需要原始碼裡的一個詞，卻能避免一次錯誤診斷。
那些延遲是設計的一部分
回退不是「重試一次」。面板在喚醒之後需要一段時間才能重新回應 DDC/CI——在通知剛落地的那一刻重放，正是樸素喚醒處理會失敗的原因。一個真正的實作在喚醒後等 2.5 秒，然後按 1、2、4 秒退避重試。
為什麼這道階梯要保持可測試
重試階梯不依賴視窗工具包，也不依賴任何具體的 DDC 類型：呼叫方把寫入器和 sleeper 注入進來。這正是它能在「面板完全不支援 DDC/CI」的機器上被跑到的原因——而那恰恰是唯一一類否則永遠走不到這段程式的機器。
誠實的邊界
- 軟體調光不是「一樣但更便宜」。它改的是畫面，而且在低值時會明顯地把黑位抬起來。
- 這些具體延遲是某一個實作對著自己的硬體量出來的。它們不是規範，面板各不相同。
- 硬體控制也不是永遠更好：在一塊回應很慢的面板上，混合方案可能比乾淨的軟體調光更糟。