Постараюсь сразу к делу::

Есть WinDriver.
Работает так (в моём понимании):
При инициализации я задаю размер буфера для IN пакетов, он может быть хоть гигабайт.
Ядрёная (kernel) часть драйвера выгребает заданный BULK ендпойнт САМА, без пинков от медленной юзерской программы.
А когда я в юзерской программе делаю чтение, то оно происходит уже из ядрёного буфера.

Есть libusb.
Работает так (в моём понимании):
Когда я вызываю чтение, то только тогда на шине инициируется IN-транзакция. Никаких буферов нет.
Поэтому когда прога работает, а я давлю "обновить" в браузере на каком-нить тяжёлом сайте,
то чтение прекращается на сотню миллисекунд, и не слишком длинный буфер в моём устройстве переполняется.

Вопросы::
- верно ли я понимаю ситуацию?
- может быть я неправильно использую libusb?
- может быть надо использовать libusbK или ещё что? Пробовать все существующие дрова самому в облом.

Виндрайвер использовать не хочется.
Хоть он и хорошо работает, но у юзеров инсталится и деинсталится с проблемами.
Тот же libusb в этом смысле образцовый.

Не так. Если бы было так, как вы описали, то при открытии чтения из юзерской программы вы бы получали данные, выгребенные из устройства полчаса назад.
При открытии чтения драйвер (или цепочка драйверов) выделяет буфера и строит цепочку дескрипторов на заявленную длину чтения (которая может быть много больше размера эндпойнта), после чего практически не участвует в чтении (разве что обрабатывает прерывания) - обработку транзакций и слив данных в буфера производит USB-контроллер аппаратно, посредством DMA-механизма, согласно цепочке дескрипторов обмена.

Насколько я понимаю, libusb также опирается на kernel-драйвер, только расположенный ниже по иерархии, который предоставляет generic-доступ к устройству, то есть на уровне "осуществить bulk-чтение" в размере конечной точки. Поэтому, чтобы выгрести приличный объем данных, libusb вынуждена много раз "слазить" на уровень kernel и обратно, что довольно затратно для системы, ну и другие процессы тоже могут "перебивать" эту неспешную процедуру.

В Windriver оно ровно так и происходит. Насколько хватит заданного мной буфера.



Да это и эжу понятно, что какой-то кернел есть.
Вопрос в том, как быть. Может эта коряга работать так как виндрайвер или нет. И если нет, то какую корягу взять.

libusb именно и сделан как юзерспейс подсистема, полностью выносящая обслуживание USB устройств из ядра (kernel часть реализуется внутри libusb, а внаружу торчит только юзерспейс). И сделано это так, чтобы не зависеть от операционной системы где это используется (т.е. именно скрыть детали kernel особенностей).
На libusb на сегодня реализованы десятки, точнее сотни проприетарных и фирменных подсистем поддержки самого разнообразного USB-оборудования (фотоаппараты, диктофоны, видеокамеры и мн. мн. другое). Если им все оно годилось, то не думаю что у вас что-то такое "военное" , что вам оно будет "в облом".

P.S. И чуть-чуть по поводу терминологии...
libusb - это серьёзно проработанный и массово используемый проект. Поэтому вряд ли к нему применим термин "коряга".
А "коряга" - это что-то такое, что вы будете писать, возможно используя libusb, а возможно и нет

Рыбята, давайте так.
Кто знает по теме ещё меньше меня — не пишите сюда, ладно?
Не надо мне втирать тут банальшину, тем более ложную.

Раз уж речь идет о USB в Windows, то почему у вас не фигурирует WinUSB (как Microsoft'овский аналог libusb, родной для OS)? OpenOCD, например, уже давно на него перешел для сборок под Windows/Cygwin.

Меньше знать трудно.

Как-то неудобно было даже упоминать его.
Пробовал.
Такой же примитив, как libusb, с той же проблемой что я описал, только ещё хуже.
К тому же, нельзя подключить одновременно более одного устройства.
А ещё libusb удобнее компилить, для WinUSB же нужно или SDK ставить, или массу всякого SDKшного мусора к себе в прожект перетаскивать.
Визард у libusb удобный, опять же.
Кароче, о юзере-то позаботились, тока вот драйвер нормальный написать не смогли.
Тем же СвинДрайвером пользоваться гораздо НЕудобнее, но данные качает он так что от зубов отскакивает.


Но тебе-то удалось.

Ну это не так! Подключать можно много устройств и со всеми можно работать...
Ограничение лишь в монопольном доступе, т.е. только одно приложение сможет открыть устройство и работать с ним, в момент времени.
А если устройство еще и WCID, то и дровишки будут автоматически устанавливаться.
В win7 драйвер поставится c сервера обновлений (при наличии сети), а в win10 он уже встроен,
и даже подписывать драйвер не требуется.


Ну это тоже не так, вся работа заключена в одной winusb.dll
Если линковать статически, то да, нужен будет *.lib файл из SDK (хотя его можно и сгенерить самому).
Никакого мусора в проект там не перетаскивается, чистые winAPI функции.

Ну и немного добавлю про libusb
Она добавляет куда больше мусора в проект ибо является надстройкой над WinUsb

Но именно это нормальный человек и подразумевает под одновременным подключением.


Ну и не верно. Нужно подписывать.
Если только вы не взяли уже подписанный cat от другого устройства и заюзали его с его же видом-пидом и всем остальным.


Да? Можете предъявить пример такого прожекта, который компилится без сдк и без выдранного из него мусора, если даже в доке на винусб об этом сказано? Мне не удалось.

Да и вообще проблема не в этих мелочах.

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


Но у меня же работает (со своими VID-PID!), причем коммерческий проект... все дело в WCID


Откройте исходник libusb, в чем проблема?
libusb-1.0.21.zip\libusb-1.0.21\libusb\os\windows_winusb.c; windows_winusb.h
пожалуйста, динамическая линковка winusb, так что даже родной winusb.lib не нужен...
а в windows_winusb.h определение функций и структур, так что даже родной winusb.h не нужен...

То есть подписанный cat вам вообще не нужен?

По поводу всего остального — да не важно это всё, важно найти ответ главную проблему, описанную в первом посте.

не нужен... на win8 и выше драйвер вообще будет не нужен... (он уже есть в системе начиная с win8)
воткнули устройство драйвер автоматом установился...
Более старые системы (win7 и ниже), после подключения устройства, попытаются подгрузить драйвер с microsoft update,
если этого еще не было сделано ранее, при отсутствии же коннекта тогда понадобится драйвер (для оффлайн установки)
(он уже ставится даже без подписанного cat, конечно будет предупреждение о не подписанном драйвере)
Минус только один, при автоматической установке драйвера, устройство будет отображаться как WinUSB Device в диспетчере устройств.

более подробно про WCID, можно почитать тут:
https://github.com/pbatard/libwdi/wiki/WCID-Devices


По поводу вашей проблемы, сложно что-либо сказать... все зависит от реализации...
У себя с устройством на HS проблем не замечал...
У меня так, отдельный тред постоянно слушает устройство и пишет данные в буфер... софтина уже оттуда все забирает...