Подсветка экрана в Linux
Jan. 23rd, 2015 07:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
techquisitorЕсть очень распространённый класс проблем, возникающих на ноутбуках с Linux. А именно различные нюансы с подсветкой экрана. При этом принято ругать плохое качество поддержки железа в Linux, что далеко не всегда соответствует действительности. Выглядеть со стороны пользователя это может по-разному. У кого-то не работает подсветка вообще. У других — с крайне большими задержками яркость всё же меняется. На моём Dell Precision M4800 была именно вторая проблема. Проявлялась забавно, кстати. Яркость увеличивалась, но с лагом в 2-3 секунды. Если же яркость надо было уменьшить, лаг возрастал до 10-15 секунд. Обычно, народ на форумах лечит данную проблему прописыванием в параметры ядра опции acpi_backlight=vendor.
У меня, например, всё отлично заработало после внесения данного параметра в настройки ядра. Но после прописывания и успешного тестирования, мне стало интересно с чем это связано.
Выяснилось любопытное в итоге. На очень многих современных нотбуках используется два типа управления яркостью. Стандартным является управление через ACPI. Вторым — т.н. vendor-specific. И вот с такими аппаратами возникает проблема. Если не прописать принудительное отключение управление яркостью через ACPI, то при посылке запроса на изменение яркости, подсистемы очень долго могут думать кому выполнять данную команду. Убрав конкурента в лице ACPI, мы получаем корректную работу подсветки. В моём случае, получается, что я указал использовать DELL specific метод управления яркостью. Аналогичное, кстати, наблюдаю на ноутбуках компании Samsung. Причём там ситуация ещё хуже порой.
У меня, например, всё отлично заработало после внесения данного параметра в настройки ядра. Но после прописывания и успешного тестирования, мне стало интересно с чем это связано.
Выяснилось любопытное в итоге. На очень многих современных нотбуках используется два типа управления яркостью. Стандартным является управление через ACPI. Вторым — т.н. vendor-specific. И вот с такими аппаратами возникает проблема. Если не прописать принудительное отключение управление яркостью через ACPI, то при посылке запроса на изменение яркости, подсистемы очень долго могут думать кому выполнять данную команду. Убрав конкурента в лице ACPI, мы получаем корректную работу подсветки. В моём случае, получается, что я указал использовать DELL specific метод управления яркостью. Аналогичное, кстати, наблюдаю на ноутбуках компании Samsung. Причём там ситуация ещё хуже порой.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-01-23 04:39 pm (UTC)Вот за что я люблю старые thinkpads...
no subject
Date: 2015-01-23 04:48 pm (UTC)no subject
Date: 2015-01-23 07:32 pm (UTC)no subject
Date: 2015-01-23 08:12 pm (UTC)You are not authorized to access bug #1168012. To see this bug, you must first log in to an account with the appropriate permissions.
no subject
Date: 2015-01-24 12:02 am (UTC)Description of problem:
Brightness is zero if laptop lid is closed and then open. Pressing a brightless control button returns it back to normal.
Version-Release number of selected component (if applicable):
2.6.32-504
How reproducible:
Always
Steps to Reproduce:
1. Boot 2.6.32-504 system into X11 on Thinkpad T61 with GM965
2. Close laptop lid
3. Open laptop lid
Actual results:
Screen is black. Pressing Fn+Home (brightness up) brings it to normal.
Expected results:
Screen has normal brightness immediately when the lid is open.
Additional info:
It is a kernel-dependant regression. If I load previous kernel, 2.6.32-431, problem disappears.