Linux и тормозная клава

Надо сразу сказать, что usb-клавиатура, о которой здесь речь, в общем-то не виновата. Вы же не станете винить какую-нибудь юную красотку, если она в ответ на философский вопрос о том, кто она такая на самом деле, поставит на вас круглые глаза и ничего не ответит? То-то и оно.

Дело в том, что система и usb-клавиатура взаимодействуют на двух уровнях. Первый – низкий – обычно не вызывает проблем. Показателем этого является тот факт, что на начальном этапе загрузки, в меню grub, мы можем, нажав определенную клавишу (работает!), выбрать нужный загрузочный пункт или войти в командную строку grub'a и много чего там сделать. Тут действует автономный протокол начальной загрузки (HIDBP), которому не интересны мультимедийные рюшечки или LED-контроллер нашей клавы. Это, образно выражаясь, мир инстинктов, животный уровень.

А вот дальше, когда grub инициализирует загрузочные механизмы операционной системы, вступает в игру высокий уровень, который так и называется – человеческий (Human Interface Device, или сокращенно HID). И наткнувшись на тот же LED-контроллер, система начинает задавать клаве всякие вопросы, на которые та, понятное дело, не умеет ответить. Возникает заминка на несколько секунд... Она проходит бесследно, и о ней никто бы и не вспомнил, если бы у нас не было мощных механизмов слежки за участниками событий – логов системы.

Посмотрим бегло на dmesg. Вот на третьей секунде загрузки появляется запись:

Вроде бы всё хорошо: usb-клавиатура опознана, определено ее место и опции работы с ней... На этом этапе загрузки у системы чертова уйма забот, опознаются разные устройства, им выделяются ресурсы, и всё это в бешеном темпе.

Но вот, через секунду-полторы (занимающих в dmesg'e около сотни строк) в этой запарке возникает пауза. По временнóй шкале происходящего она просто гигантская – порядка 8–10 секунд! Вот изобличающее свидетельство:

То есть, грубо и приблизительно говоря, система спросила клавиатуру о чем-то, подождала ответа, не дождалась и, пробормотав: "Ладно, проехали", продолжила загрузочную работу.

Как, наверное, многие юзеры, я не обращал на этот толстый нюанс особенного внимания, пока все мои системы стояли на HDD и время загрузки по dmesg'у составляло от 30 до 40 секунд и даже больше. Подумаешь, лишних 10 секунд, тем более что серьезной ошибки не возникает, клава продолжает нормально работать, и как правило находятся другие, гораздо более насущные проблемы.

Однако мое отношение к сабжу резко поменялось, как только я приобрел SSD и установил на него систему Linux Mint 17. На общем отрадном фоне сокращения времени загрузки в 2-2,5 раза десятисекундный таймаут начал выглядеть раздражающе и даже обидно: за что деньги-то плочены!?

Решение, хоть и не сразу, нашлось.

Суть его в том, чтобы запретить драйверу usbhid всякие посторонние шуры-муры с нашей usb-клавиатурой.

Лечение

Выясняем id производителя и id продукта клавиатуры. Для этого внимательно присмотримся к первому фрагменту dmesg:

В нем для наглядности я выделил синим нужные сведения, а следующие строки подтверждают, что речь идет действительно о нашей usb-клаве, произведенной фирмой BTC.

Те же данные можно узнать и другими способами, например, с помощью команды

Правда, в выводе придется покопаться, зато мы обнаружим там те же нужные нам сведения в еще более удобном виде:

Далее открываем от рута файл /etc/default/grub, находим в нем строку

и добавляем в нее параметр usbhid.quirks=0x046e:0x6000:0x20000000

Отредактированная строка будет выглядеть так:

Переконфигурируем grub командой

и перезагружаемся.

После этой нехитрой операции время загрузки по данным dmesg составило 10,5 секунд. Вот теперь я чувствую, что не зря потратился на новый диск