重要更新：
- 新版的ACPICA
- 修正 _WDG 的parsing錯誤
下載位置：
2012年4月27日 星期五
2012年4月18日 星期三
亮度熱鍵和消失的OSD
在這個cycle中，Hardware Enablement team 遇到了好幾款筆電的亮度熱鍵 bug；癥狀為亮度調整功能正常，但是亮度的 OSD 卻沒有出現。
看起來是個小 bug，但是因為牽涉到硬體、kernel 驅動程式和gnome之間行為的互動，而成了有點難解的問題。
主要的問題在於對於亮度鍵的行為在不同的硬體上並沒有統一，有些廠牌的筆電會直接送出 scancode，gnome-settings-daemon 收到 keycode 之後會再去對 driver 產生出來的 sysfs backlight 介面做存取，之後再由 driver 負責來調整亮度。gnome-settings-daemon 在收到 keycode 的同時也會產生 libnotify 的 dbus message，而 notify-osd 收到之後負責畫出 OSD。
但在一些其它的筆電，在按下亮度鍵時並不產生 scancode，而是透過 WMI 通知 OS，kernel driver 在收到後必須負責調整亮度。在這樣的情況下因為沒有 scancode 和 keycode，所以 gnome-settings-daemon不 會收到任何通知，所以也沒有 OSD。
當然我們也可以更改 driver 程式碼，讓 driver 在收到 WMI 時也同時產生 keycode，這樣的確可以讓 OSD 正確的出現；但是因為硬體已經調整了亮度，driver 產生的 keycode 會讓亮度再被調整一次，所以導致只按了一次卻調了兩格亮度的 bug。
一個比較好的解決方式是 gnome-settings-daemon 應該使用 uevent 而不是 keycode（至少在Linux平台上），如 Corentin Chary 在Gnome Bug 672380的comment：
Because what not how it *should be done*. Keys are not notifications at all. Keys are emitted if a user press something that should be interpreted by userspace as "in reponse to this key, please adjust the brightness".
In this case, what we get from the hardware is only a brightness change notification, and it's what we will relay to userspace. It's just how the Linux backlight class works. And, really, the OSD should only pop in response to backlight notification, and never in response to keys, keys should only be used to adjust the backlight (which will pop a notification by itself).
訂閱：
文章 (Atom)