HID device up 0001 u 0002: разбор сообщения и диагностика устройства

Запись вида hid device up 0001 u 0002 появляется в системных журналах и отчётах об ошибках, когда операционная система обрабатывает событие HID-устройства, но не может корректно сопоставить его с драйвером или приложением. Чаще всего она встречается в выводе dmesg, журналах Windows или логах отладки при подключении клавиатур, мышей, геймпадов и нестандартных контроллеров. Сама по себе строка — не код ошибки, а служебная запись, однако её появление на фоне неработающего устройства указывает на проблему сопоставления Usage Page и Usage ID.

В этой статье разберём, что означают числа в записи, как устроен стек HID, почему устройство «видно» системе, но не работает, и какие проверки можно безопасно выполнить на Linux и Windows. Отдельно рассмотрим ситуации с самодельными устройствами на микроконтроллерах — там подобная запись появляется особенно часто из-за ошибок в дескрипторах.

Что означают поля up 0001 u 0002

HID (Human Interface Device) описывает функциональность устройства через иерархию «страниц использования» и конкретных «использований». В записи up 0001 u 0002 фрагмент up расшифровывается как Usage Page, а u — как Usage. Числа заданы в шестнадцатеричном виде.

Страница 0x0001 в спецификации USB HID — это Generic Desktop Controls, то есть стандартные указательные устройства: мыши, клавиатуры, джойстики. Usage 0x0002 на этой странице соответствует классическому указателю — Mouse. Таким образом, запись чаще всего означает: система обнаружила HID-устройство, которое заявляет себя как мышь или указатель общего назначения.

Похожие пары, которые можно встретить рядом в логах:

• 🖱️ up 0001 u 0002 — мышь или указатель (Generic Desktop / Mouse);
• ⌨️ up 0001 u 0006 — клавиатура (Generic Desktop / Keyboard);
• 🎮 up 0001 u 0004 или u 0005 — джойстик или геймпад;
• 🔧 up FFxx u xxxx — vendor-defined страница, устройство с фирменным протоколом.

Как устроен стек HID и где возникает сбой

При подключении устройства хост сначала выполняет стандартное USB-перечисление: запрашивает device descriptor, конфигурацию, строковые дескрипторы. Затем HID-драйвер запрашивает report descriptor — бинарное описание того, какие данные устройство будет отправлять. Именно из этого дескриптора извлекаются пары Usage Page / Usage.

Сбой может произойти на любом из этапов. Устройство корректно отвечает на базовые запросы, поэтому в лог попадает запись об обнаружении, но дальше возникает одна из типичных проблем:

• ⚡ report descriptor содержит ошибку, и парсер отбрасывает часть полей;
• 🔌 драйвер не находит подходящий обработчик для заявленного Usage;
• 📦 устройство отправляет репорты не того размера, который объявлен в дескрипторе;
• 🧩 конфликт с другим драйвером, уже захватившим интерфейс.

⚠️ Внимание: не путайте запись в логе с причиной неисправности. Сообщение об обнаружении HID-устройства появляется и при полностью рабочей мыши. Диагностировать нужно не саму строку, а отсутствие событий ввода после неё.

Диагностика на Linux

Начните с просмотра журнала ядра сразу после подключения устройства:

dmesg -w

Подключите устройство и посмотрите, какие строки появляются после записи о HID. Если дальше следуют ошибки парсинга дескриптора или таймауты — проблема на уровне обмена данными. Если сообщений больше нет, но устройство не работает, проверьте, создался ли файл события:

cat /proc/bus/input/devices

В этом списке устройство должно присутствовать с привязкой к обработчику вида eventX. Далее можно проверить сами события ввода утилитой evtest (если она установлена в вашем дистрибутиве) или чтением /dev/input/eventX. Отсутствие событий при движении мыши означает, что репорты не доходят или отбрасываются.

Для просмотра сырого дескриптора используйте:

lsusb -v -d VID:PID

Здесь VID:PID — идентификаторы вашего устройства из вывода lsusb. В разделе HID-дескриптора видно заявленные Usage Page и Usage, а также длину report descriptor. Если дескриптор обрывается или содержит явно невалидные значения — вероятна ошибка прошивки устройства.

Диагностика на Windows

В Windows аналогичную информацию даёт Диспетчер устройств. Откройте его и найдите устройство в разделах «Устройства HID» или «Мыши и иные указательные устройства». Жёлтый восклицательный знак и код в свойствах устройства подскажут направление: сбой дескриптора, отказ драйвера или проблема питания порта.

Полезные действия, которые не требуют стороннего ПО:

• 🔄 удалить устройство в диспетчере и переподключить, чтобы система заново выполнила перечисление;
• 🔌 попробовать другой USB-порт, желательно напрямую, без хаба;
• 🖥️ проверить устройство на другом компьютере — это сразу отделяет проблему ОС от проблемы железа;
• 📋 посмотреть журнал событий в разделе «Система» на предмет ошибок источника hid или usb в момент подключения.

Если устройство определяется, но ввод не работает, проверьте вкладку «События» в свойствах устройства: там фиксируется, какой драйвер был загружен и завершилась ли установка успешно.

Самодельные устройства: ошибки в дескрипторах

Разработчики HID-устройств на микроконтроллерах (STM32, ATmega32U4, RP2040 и других) видят подобные записи при каждой отладке. Типичный сценарий: устройство перечисляется, хост пишет в лог обнаружение указателя, но данные не приходят. Наиболее частые причины — несоответствие между дескриптором и реальными репортами.

Проверьте следующие моменты в прошивке:

• 📏 длина репорта, отправляемого устройством, совпадает с объявленной в report descriptor (с учётом Report ID, если он используется);
• 🔢 поля Report Size и Report Count дают суммарную длину, кратную байту, либо есть выравнивание;
• 🧭 Logical Minimum/Maximum соответствуют реальному диапазону значений (например, относительные координаты мыши должны быть знаковыми);
• 🆔 если используется несколько репортов, каждый начинается с корректного Report ID.

⚠️ Внимание: изменение дескриптора без смены VID/PID или серийного номера может привести к тому, что ОС закэширует старое описание устройства. После правок прошивки удаляйте устройство из системы или меняйте идентификатор, иначе будете отлаживать старый дескриптор.

Почему мышь определяется, но курсор не двигается

Классическая причина — координаты в репорте объявлены как беззнаковые (Logical Minimum = 0), а устройство отправляет отрицательные смещения. Хост отбрасывает или неверно интерпретирует такие значения. Для относительных осей X/Y мыши диапазон должен быть знаковым, например от -127 до 127, а Usage должен быть помечен как Relative.

Типичные сценарии и их различия

Одна и та же запись в логе сопровождает разные ситуации. Сводная таблица поможет сориентироваться:

Симптом	Вероятная причина	Первое действие
Запись есть, устройство работает	Нормальное поведение, запись информационная	Ничего, ошибки нет
Запись есть, ввода нет	Несоответствие репортов дескриптору	Проверить evtest / другое устройство
Ошибка парсинга дескриптора	Повреждённый или невалидный report descriptor	Снять дескриптор через lsusb -v
Устройство отваливается после подключения	Питание, кабель, хаб	Другой порт, короткий кабель
Работает на одном ПК, не работает на другом	Драйвер, кэш дескриптора, права доступа	Удалить устройство и переподключить

Отдельно стоит ситуация с виртуальными машинами и пробросом USB: гипервизор может перехватывать HID-устройство раньше гостевой системы, и в госте появляется запись об обнаружении без реальных событий. Проверьте настройки проброса USB-контроллера и правила udev на хосте.

Чего делать не стоит

При виде незнакомой записи в логе пользователи иногда начинают с рискованных действий. Перечислим, от чего лучше воздержаться без чёткого понимания причины:

• 🚫 не редактируйте системные правила udev и не отключайте hid-generic, не убедившись, что проблема именно в привязке драйвера;
• 🚫 не прошивайте устройство «на всякий случай» — при ошибке дескриптора прошивка не поможет, а при неудачном обновлении устройство можно вывести из строя;
• 🚫 не устанавливайте сторонние «драйвер-паки» — стандартные HID-драйверы уже есть в ОС, и подмена их редко что-то исправляет;
• 🚫 не разбирайте устройство до завершения программной диагностики — большинство подобных проблем решается без вскрытия.

⚠️ Внимание: если устройство — самодельное и подключено к питанию от USB-порта, убедитесь, что схема не превышает допустимое потребление. Перегрузка порта может проявляться как раз периодическими переподключениями и странными записями в логе.

Часто задаваемые вопросы

Является ли запись hid device up 0001 u 0002 признаком вируса?

Нет. Это стандартная служебная запись, которую ОС генерирует при обнаружении любого HID-устройства, заявляющего себя как указатель. Она появляется при подключении обычных мышей и тачпадов. Поводом для беспокойства может быть только неизвестное физическое устройство, которое вы не подключали.

Почему устройство видно в системе, но не работает?

Наиболее вероятные причины: несоответствие отправляемых репортов объявленному дескриптору, захват интерфейса другим драйвером или проблемы с питанием порта. Проверку начинайте с чтения событий ввода (evtest в Linux) и просмотра журнала на предмет ошибок после строки обнаружения.

Как посмотреть полный дескриптор HID-устройства?

В Linux — командой lsusb -v -d VID:PID, где идентификаторы берутся из вывода lsusb. Также существуют утилиты для чтения именно report descriptor через интерфейс hidraw. В Windows аналогичную информацию показывают сторонние USB-анализаторы.

Можно ли исправить ошибку дескриптора без перепрошивки устройства?

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

Запись появляется циклически, устройство переподключается — что это?

Циклические подключения и отключения обычно указывают на аппаратную проблему: нестабильное питание, повреждённый кабель или разъём, либо перезагрузку прошивки устройства из-за ошибки. Проверьте другой кабель и порт, исключите USB-хаб из цепочки.