Linux: консоль становится белой

rsync в режиме демона просто дает вам способ отправлять / получать данные на сервер без использования других протоколов, таких как ssh. Он может быть полезным для ускорения передачи данных, например, или когда ssh или другие протоколы недоступны. Также посмотрите на "unison", мне кажется, что это может быть полезно в вашем случае.

1
15.03.2016, 01:17
2 ответа

Я поискал еще немного и нашел эту тему, которая показывает, что проблема может быть устранена с помощью параметра radeon backlight=0, который доступен на ядрах 3.18.* и новее.

У меня случайно оказалась 3.18.7, и она прекрасно работала с backlight0. Однако возникла новая проблема: это ядро сломало мой брандмауэр, что потребовало переконфигурации и перекомпиляции для исправления. Учитывая необходимость перекомпиляции, я обновил исходники до последней версии 3.18.28 перед перекомпиляцией. После этого брандмауэр был исправлен, но исправление блокировки консоли больше не работало. Теперь, при backlight=0, вся консоль постоянно становится темной, как только загружается radeon. Нет способа вернуть все обратно, кроме перезагрузки. Если я попробую backlight=1 вместо этого, консоль становится темной в первый раз, но впоследствии становится белой (как описано в приведенной выше теме).

Итак, это переросло в связанную проблему, которая требует дополнительного изучения.

1
27.01.2020, 23:35

Я провел дополнительное расследование. Сначала я посмотрел на все инкрементные патчи, начиная с версии 3.18.7 (гашение работало нормально с backlight = 0 ) до 3.18.28 (сломано). Самое подозрительное изменение было в патче с .22 на .23.

Итак, я скомпилировал 3.18.22, и он работал с backlight = 0 . Затем при переходе на 3.18.23 он действительно сломался: backlight = 0 снова приводит к постоянно черному экрану. Затем я удалил две подозрительные строчки из кода 3.18.23. Они находятся в файле drivers / gpu / drm / radeon / atombios_encoders.c и представляют собой идентичные вызовы:

atombios_set_backlight_level (radeon_encoder, dig-> backlight_level);

Если я закомментирую эти вызовы, и перекомпилируйте, все работает нормально. Я подозреваю, что на любом оборудовании, имеющем эту проблему, может потребоваться удалить только один из этих вызовов.

Наконец, я хочу отметить, что я пробовал более новое ядро, версию 4.4.5 от Slackware64 -current.Это хорошо работает с подсветкой = 0 , ничего взламывать не нужно.

1
27.01.2020, 23:35

Теги

Похожие вопросы