Комментарии 9
Разве ида умеет автоматом JNI распознавать?
Огромное спасибо!
В свое время тоже пытался его исследовать, но терпения не хватило.
В свое время тоже пытался его исследовать, но терпения не хватило.
А HID там не совсем неправильный и его вполне можно завести с родным драйвером.
Краткая теория: HID предусматривает два варианта обмена — через EP0 control transfer (это и делают HidD_SetOutputReport/HidD_GetInputReport), либо через отдельные interrupt endpoints (посредством ReadFile/WriteFile с тем же самым device handle). Причём ОС опрашивают мыши/клавиатуры через interrupt transfers (более оптимальное использование шины), соответственно разработчики железа часто уделяют этому способу больше внимания.
Китайцы видимо вообще не стали реализовывать работу через control transfer, сделав только interrupt. Сами пакеты — вполне нормальный HID (первый байт — Report ID, второй — длина, дальше — данные этой длины. Лишние данные, добивающие пакет до endpoint MaxPacketSize, как бы даже не часть стандарта).
Это не единичный случай, когда-то натыкался на такое поведение у мышек A4Tech Bloody, тоже обескуражило.
Краткая теория: HID предусматривает два варианта обмена — через EP0 control transfer (это и делают HidD_SetOutputReport/HidD_GetInputReport), либо через отдельные interrupt endpoints (посредством ReadFile/WriteFile с тем же самым device handle). Причём ОС опрашивают мыши/клавиатуры через interrupt transfers (более оптимальное использование шины), соответственно разработчики железа часто уделяют этому способу больше внимания.
Китайцы видимо вообще не стали реализовывать работу через control transfer, сделав только interrupt. Сами пакеты — вполне нормальный HID (первый байт — Report ID, второй — длина, дальше — данные этой длины. Лишние данные, добивающие пакет до endpoint MaxPacketSize, как бы даже не часть стандарта).
Это не единичный случай, когда-то натыкался на такое поведение у мышек A4Tech Bloody, тоже обескуражило.
Хм я пробовал и через WriteFile — результат был аналогичный HidD_SetOutputReport — т.е. никаких результатов. Дойдут руки — перепроверю, но врятли заработает. А еще с HID драйвером когда вытаскиваешь девайс из разъема — до драйвера доходило только секунд через 5. WinUsb драйвер реагирует мгновенно.
Проверил — WriteFile дает ERROR_GEN_FAILURE, как и HidD_SetOutputReport. Так что если нет какой-то хитрой настройки, без которой не работает, это таки неправильный HID. Возможно китайцы сначала сделали нормальный HID, но не смогли с ним работать под андроидом и переделали на BulkTransfer.
Скорее они изначально работали через bulk transfer, а где-то в HID-дескрипторах (которыми сами и не пользуются) допустили ошибки и HID-драйвер сходит с ума на попытке понять конфигурацию устройства (задержка обнаружения отсоединения опять же намекает). С корректно реализованным HID вполне можно было бы общаться и через bulk transfer без переделок (interrupt endpoint нормально понимает bulk пакеты, на уровне шины токены те же).
Ну да у вас и так всё работает же, замена драйвера — мелочи.
А внутрь устройства не заглядывали? Немного загадочно что приём такой слабый. Типовой трёхногий ИК-приёмник должен бы одинаково хорошо работать что в телевизоре, что в таком девайсе. Его там «глазом» вовнутрь не поставили часом?
Ну да у вас и так всё работает же, замена драйвера — мелочи.
А внутрь устройства не заглядывали? Немного загадочно что приём такой слабый. Типовой трёхногий ИК-приёмник должен бы одинаково хорошо работать что в телевизоре, что в таком девайсе. Его там «глазом» вовнутрь не поставили часом?
Внутрь не заглядывал и сомневаюсь что его можно разобрать не разломав — зацепиться не за что, визуально девайс хрупкий, скорее всего на клею или защелках, которые сломаются при попытке разбора.
Дальность приемника для него по видимому нормальная — родная софтина при захвате пишет чтоб поднесли пульт на 10 см.
Дальность приемника для него по видимому нормальная — родная софтина при захвате пишет чтоб поднесли пульт на 10 см.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реверс-инжениринг протокола китайского USB ИК трансивера