Тестируем поддержку USB

Fri Aug 26, 2011 7:41 pm

Поддержка автоповтора клавиш на USB-клавиатурах: http://ftp.kolibrios.org/users/CleverMo ... kernel.mnt и http://ftp.kolibrios.org/users/CleverMo ... usbhid.obj . Интервалы следующие: 250 мс от нажатия клавиши до начала автоповтора, 50 мс в процессе автоповтора. В идеале интервалы, конечно, должны быть настраиваемыми, но сейчас я не располагаю силами ни на реализацию API для настройки, ни на реализацию пользовательского приложения для этого - тем более, что для PS/2-клавиатур этим тоже никто не занимался. Вероятно, usbhid дальше меняться уже не будет до коммита в trunk, так что исходный текст для любопытных лежит рядом на ftp.
Тестировалось на реальной клавиатуре, подключённой к VMWare в монопольном режиме.

Fri Aug 26, 2011 8:13 pm

Это общий код для OHCI и UHCI?

Fri Aug 26, 2011 8:19 pm

Да, драйверу USB-устройства должно быть безразлично, какой именно контроллер используется - за возможным исключением минорных различий в поведении usb1 и usb2.

Fri Aug 26, 2011 8:21 pm

Если точнее, то я спрашивал про само тестовое ядро или в нем уже оба типа контроллера обрабатываются?

Fri Aug 26, 2011 8:23 pm

В ядре оба обрабатываются.

Fri Aug 26, 2011 9:46 pm

CleverMouse wrote:IOCTL interface is not supported

Ещё один рецепт в сборник "Убей ядро из user-mode" ?

Fri Aug 26, 2011 10:16 pm

Serge, естественно, вместе с введением функции reg_usb_driver, разрешающей нулевой ioctl-обработчик, в srv_handler[Ex] должна быть добавлена проверка на нулевой ioctl-обработчик. В trunk вся эта часть пока не залита.

Fri Aug 26, 2011 10:23 pm

Раз уж ядро экспортирует специальные функции для usb почему не добавить ещё один вызов вместо использования reg_service не по назначению ? У нас не C++ с перегрузкой операторов и функций.

Fri Aug 26, 2011 10:43 pm

Не совсем в тему, но обработка таймеров в osloop неудачная идея. С одной стороны никакая точность срабатывания, с другой угроза длительного блокирования ключевых функций. Надо переходить к выполнению сложных сервисов в самостоятельных потоках. Тогда можно задействовать систему событий. Точности при нынешнем планировщике это скорее всего не прибавит, но блокировки позволит избежать.

Fri Aug 26, 2011 10:49 pm

Чтобы не заставлять драйвер вызывать две функции, вызов каждой из которых обязателен - reg_service обязательно, чтобы его можно было потом найти при повторной необходимости, и регистрация как usb обязательна, потому что это всё же usb-драйвер.

Fri Aug 26, 2011 10:54 pm

В документации прямо рекомендуется не ставить в качестве таймеров долгие процессы, для них рекомендуется именно создание потоков. USB, к слову, создаёт отдельный ядерный поток; поскольку родителем для него всегда является основной процесс ядра, то для этого достаточно нескольких строчек в taskman.inc.

Fri Aug 26, 2011 10:58 pm

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

Fri Aug 26, 2011 11:01 pm

В чём подпорка или костыль? Почему драйвер должен трактовать вызовы ядра не так, как ядро?

Fri Aug 26, 2011 11:03 pm

CleverMouse wrote:В документации прямо рекомендуется не ставить в качестве таймеров долгие процессы

Если бы этим рекомендациям ещё следовали программисты. Сама же нарушаешь существующее API для драйверов и ожидаешь что остальные будут следовать рекомендациям ?

Update.
В документации ничего не говорится о последствиях вызова блокировок из таймерных функций.
Раз драйвер usb работает в своём потоке лучше сразу использовать события, пока не стало поздно.

Fri Aug 26, 2011 11:13 pm

С reg_service извиняюсь, невнимательно посмотрел исходники. Хотя отсутствие поддержки IOCTL нарушает существующую драйверную модель.

Тестируем поддержку USB

Who is online