Нужна помощь в реверс-инжиниринге USB устройства

может стоит назвать девайс?

Вообще, всё украдено до нас, после хамоватого отлупа техподдержки тоби, народ самостоятельно расковырял эту железяку и даже были истории успеха https://github.com/Eitol/tobii_eye_tracker_linux_installer

как оно сейчас не в курсе, не интересовался.

Это Tobii Eye Tracker 5. А по ссылке 4C. Их совместимость вызывает большие вопросы т.к. даже официально разные программные пакеты требуются. Попробую софт от 4C для 5, если совсем ничего не получится сделать.

ну никто не обещал что будет просто. Тем паче, что история двух лет назад. Если действительно есть необходимость, можно связаться с парнями из проекта(по ссылке выше) и покумекать вопрос о твоей проблеме. Раз они сумели её решить тогда, то есть вероятность что они её решили и сейчас, ну или могут решить.

Тут нет простых путей, если квалификация позволяет, её(железяку) можно ведь и тупо хакнуть. Бывали истории когда народ видеокарты нвидии перепрошивал из офисной затычки в топ-10, а тут какой-то юсб-свисток с апломбом. Было б желание.

Скорее всего ответ на первоначальный запрос к эндпоинту 0x05 (OUT) — это и есть посылка с эндпоинта 0x83 (IN). Попробуй вместо чтения «пустого ответа» из эндпоинта 0x05 читать ответ из 0x83. То есть, сначала посылаешь то, что в первом фрейме, а потом сразу читаешь ep 0x83.

https://www.tobiipro.com/product-listing/eye-tracker-manager/

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

из деб пакета описание:

Free software to help manage your screen-based eye tracker. The Tobii Pro Eye Tracker Manager is a new configuration and setting utility that helps you manage your connected eye trackers. It is available free of charge and greatly increases efficiency for users of either the Tobii Pro SDK or Tobii Pro Lab.

сам пакет - https://s3-eu-west-1.amazonaws.com/tobiipro.eyetracker.manager/tobiipro.etm.l...

версия блоба V8, и на самом сайте есть новые прошивки.

Вот для разработчика - http://www.developer.tobiipro.com/

там полноценный(?) SDK, т.е. можно девайс самостоятельно интегрировать во что-то своё.

PS. и он таки умеет в tobii eye tracker 5 . По крайней мере они об этом пишут(в описании SDK)

Да, выглядит так, что запрос делаю на один эндпоинт, а ответ приходит из другого. Однако libusb_bulk_transfer работает так, что, вне зависимости от направления передачи данных, это всегда выглядит как запрос-ответ. А в моём случае в третьем фрейме ответ как бы приходит без запроса. Возможно, libusb слишком выскооуровен для того, что я хочу сделать.

Спасибо. Однако не вижу упоминания про Tobii Eye Tracker 5. Поддерживаемые девайсы перечислены в http://www.developer.tobiipro.com/tobiiprosdk/supportedeyetrackers.html, а мой в их линейку не входит.

Ну есть ещё асинхронный API. Может как-то можно через него попробовать?

Поддерживаемые девайсы перечислены

https://developer.tobii.com/community/forums/topic/tobii-eye-tracker-5-sdk/

Хоть речь в топике и про оффтопик, но т.к. кишки у SDK одни и те же, то и поддерживает он девайсы те же что и оффтопик.

Мне не понятно - тоби шашечки, али таки ихать?

SDK есть, пакет есть - что сложного поставить и проверить, не хочешь ставить в систему, поставь в песочницу, или вообще не ставь, распечатай архив, пропиши PATH и запусти, он всё с собой таскает, ему не нужно волшебных плясок с бубной.

Да, выглядит так, что запрос делаю на один эндпоинт, а ответ приходит из другого. Однако libusb_bulk_transfer работает так, что, вне зависимости от направления передачи данных, это всегда выглядит как запрос-ответ.

Здесь 2 запроса - один типа bulk out на 5-й эндоинт, и один типа bulk in на 3-й. Пакеты #1 и #2 это 1-й запрос и ответ грубо говоря типа «ок» на него, #3 и #4 - 2й.

Так что здесь нет каких-либо противоречий.

Возможно, libusb слишком выскооуровен для того, что я хочу сделать.

Вот, как это же самое выглядит с точки зрения libusb:

   int bytes_transferred;
   char cmd[] = { 0x00, 0x00, 0x00, 0x00, 0x2c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x51, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0xc4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x05, 0x00, 0x17, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00 },
   libusb_bulk_transfer(dev_handle, 0x05 | LIBUSB_ENDPOINT_OUT, cmd, sizeof(cmd), &bytes_transferred, 0);

   char buf[64];
   libusb_bulk_transfer(dev_handle, 0x03 | LIBUSB_ENDPOINT_IN, buf, sizeof(buf), &bytes_transferred, 0);

Если на 2-м bulk transfer-е Вы все равно получаете ошибку то это только потому, что девайс по каким-то причинам заранее не подготовил ответ.

А асинхронное API libusb здесь не нужно. Но можно, если так удобнее.

Пакеты #1 и #2 это 1-й запрос и ответ грубо говоря типа «ок» на него, #3 и #4 - 2й.

Но в Wireshark я вижу, что #4-й пакет имеет Response in: 17. Т.е. он является запросом, а ответ на него пришёл в #17-ом пакете. Тогда непонятно, кому принадлежит #3.

Код получился похожим - https://pastebin.com/dfVe9z7z. Если посмотреть через Wireshark, что он делает, то будет видно четыре пакета. По 2 на каждый вызов libusb_bulk_transfer. А каждый вызов это один пакет host->device и другой device->host. Игрался с параметрами, но не получалось сделать так, чтобы libusb_bulk_transfer превращался в один пакет device->host. Асинхронное API тоже не дало результатов.

Что-нибудь выгорело с 5?