Board.KolibriOS.org

Поддержка автоповтора клавиш на 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 в монопольном режиме.

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

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

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

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

CleverMouse wrote:IOCTL interface is not supported

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

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

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

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

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

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

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

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

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

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

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

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