Полигон-2

Известно, что протокол обмена USB сложен уже сам по себе. Однако в случае клавиатур, мышей и пр. поверх него накладывается ещё один слой, под названием USB HID. Если в двух словах, в чём его особенность - в данном случае при работе гаджета уже речь не идёт о том, что это явно "клавиатура на 105 клавишей", или "мышь стандартная трёхкнопочная". В большей степени говорится о том, что "есть некое устройство, у него есть одна функция, сообщающая положение определённого количества координатных крутилок, в качестве которых могут быть координаты мыши, или колёсико скроллера, или регулятор громкости...да что угодно, на самом деле. И ещё другая функция, сообщающая состояние такого-то количества кнопок". Для каждого из передаваемых параметров девайс должен рассказать хосту о формате передаваемых данных, возможном диапазоне изменения этих данных (например, "крутилка №1 меняет своё положение от -32767 до 32767"), даже о характере их изменения (например, по линейной или логарифмической кривой) и много чего другое. И для девайсов это замечательно, поскольку не нужно привязываться к функциональным ограничениям, заложенным когда-то давным давно, когда даже 300 DPI для мыши считалось шикарно. Не нужно городить новые расширения протокола и прочие "костыли" чтобы ввести поддержку новых функций (как примерно это было с курсорными клавишами и колёсиком на PS/2 интерфейсе). Но для хоста вся эта универсальность...вырастает в сущий ад! Поскольку если по-честному, хост должен уметь как минимум всё это развёрнутое описание принять, адекватно интерпретировать и принять данные именно в таком виде, в каком этого желает неведомый разработчик конкретно подключенной модели мыши.
Впрочем, составители протокола прекрасно понимали, что в определённых ситуациях это может стать серьёзной проблемой. В частности, для производителей BIOS, когда они захотят добавить поддержку USB клавиатуры в свой продукт. До эпохи "4K видео" и навороченных графических UEFI-менюшек почти с операционную систему размером было ещё далеко, и ёмкости ПЗУ могло элементарно не хватить на всё про всё, даже если бы программисты осилили поддержку. Поэтому специально для клавиатур и мышей ввели в стандарт некий "режим совместимости", в который хост может перевести устройство относительно просто. В данном режиме функционал и формат данных чётко оговорён стандартом. Для мыши, в частности, две координаты 8-битной точности (даже если в "полноценном" режиме мышь умеет точнее) и три кнопки. А раз формат данных оговорён - хост сразу может принимать данные, и код его поддержки значительно упрощается. Именно в этом режиме и работает данный переходник с USB мышью.

Merchant*RU написал:

[q]

зачем всё это нужно компьютеру класса

[/q]

цель не такая, Fe. Цель - максимально универсализировать переходник. Чтобы на том же 286 любая многокнопочная и многоколёсиковая мышь работала как МЫШЬ в первую очередь. Что не ясно то?

xoiss, с одним "но": комп с линуксом не влезает внутрь разъёма, а mcu влезает...

Merchant*RU задача тривиальна: есть старые компы. Вполне ещё рабочие. А вот устройства ввода, которые к ним возможно подключить, если и остались с "тех" времён, то работают весьма паршиво. Поэтому и изыскиваются способы, как прикрутить несовместимое.
xoiss да, так порой делают. Берётся, скажем, Raspberry, и через GPIO-порты прикручивается практически куда угодно. Выглядит довольно громоздко, но в целом работоспособно. Другое дело, что я в программировании под линуксы, мягко говоря, не силён...а вот arm-ы, это уже другое дело. Присматриваюсь к возможностям STM-овского HAL-а, быть может, оно умеет больше, чем LUFA?

А пока была провдена проверка довольно большого количества мышей. И вот что у нас вышло:
Razer Copperhead, уже весьма старый, но тем не менее вполне геймерский гаджет. boot-протокол не поддерживает и стеком переходника не опознаётся. Ещё пример: комплект Logitech 660 Deluxe, а также пара китайских конвертеров PS/2 клава+мышь -> USB - с аналогичным результатом.
Так или иначе, в подавляющем большинстве мышей boot-протокол был обнаружен. Однако его реализация...в значительной мере напомнила мне ситуацию с поддержкой редко используемых режимов работы в PS/2 мышах (режим "read mode", который задействовался в первом поколении переходников PS/2 -> COM). Стандарт обязывает, чтобы его поддержка была, но не раскрывает, в каком именно виде поддержка должна быть. В результате у подавляющего большинства мышей (например, серия Genius NetScroll и практически весь китайский ноунейм) скорость перемещения в режиме boot-протокола резко падает относительно нормальной - приблизительно до уровня шариковой мыши. Чего впрочем, в досовском экране Norton Commander-а достаточно. Некоторые же мыши скорость не снижают и работают почти так же быстро и хорошо, как в прямом USB подключении к компу. Пример - беспроводная Genius traveller 9000, Logitech-овская RX 250 (к слову, весьма добротное, "олдскульное" изделие на контроллере от Cypress, поддерживающее как USB, так и PS/2 через пассивный адаптер) и...как ни странно, китайский ноунейм за 80р из Aliexpress. В аутсайдерах же у нас Ritmix RMW-110, в обычном режиме нормально работающая, однако в boot-протоколе ползающая лишь по оси X!
И в заключении, как уже упоминалось, при вращении скроллера практически все мыши передают пустые пакеты данных (перемещение по нулям, и кнопки не нажаты), несмотря на то, что в boot-протоколе скроллер не поддерживается. Исключение среди проверенных мышей - уже упоминавшаяся RX 250, которая никаких пустых пакетов не отправляет.