Здравствуйте, iGNER, Вы писали:

GNE>Здравствуйте, XorNeT, Вы писали:

Cyr>>>>Появилась такая задача — работа с USBшной камерой...
Cyr>>>>иногда камера входит в непонятный режим, что требует ее перезапуска...
Cyr>>>>самый простой вариант — это сбросить питание, благо питается по USB...
Cyr>>>>Вопрос такой — как это сделать?

GNE>>>У меня вот другой вопрос возник: как сделать рестарт девайса из kernel-mode (из фильтр драйвера). Например, повесить такой фильтр где-то на USB и отслеживать контролы к конкретному USB устройству, и ежели встречается IOCTL_INTERNAL_USB_CYCLE_PORT, отрубить питание самому а потом врубить. Только вот проблема, если фильтр будет висеть на самом устройстве, он выгрузиться (насколько я понял) при отключении питания и некому будет оное включить. Так что мне сдаеться, надо чтоб фильтр висел на USB hub-ах и если на одном его порту висит мое устройство и к этому устройству идет IOCTL_INTERNAL_USB_CYCLE_PORT, вырубить/врубить питание на порт.
GNE>>>Что в свою очередь пробуждает вопросы:
GNE>>>Как USB hub может узнать, на каком порту висит мое устройство?
GNE>>>Как USB hub может отловить, пришло ли к моему устройству IOCTL_INTERNAL_USB_CYCLE_PORT?
GNE>>>И наконец, как вообще отрубается питание в kernel-mode?

GNE>>>Regards,
GNE>>>iGNER

XNT>>Любое устройство при конфигурации возвращает номер порта при запросе от своего драйвера
XNT>>Подробнее об адресации:
XNT>>More About Device Addressing
XNT>>The previous text says that all configured devices receive the electrical signals associated with every transaction. This is almost true, but a true renaissance programmer should know another detail. When a USB device first comes on line, it responds to a default address (which happens to be numerically 0, but you don’t need to know that). Certain electrical signalling occurs to alert the host bus driver that a new device has arrived on the scene, whereupon the bus driver assigns a device address and sends a control transaction to tell “device number 0” what its real address is. From then on, the device answers only to the real address.

XNT>>Стать фильтром к ЮСБ хабу ничего не даст т. урбы идут хитрым образом минуя FDO хаба к HCD. Т.к они приходят на ПДО твоего устройства (которое с ФДО хаба на одном уровне). А шобы вернуть устройство к жизни после остановки достаточно послать IOCTL_INTERNAL_USB_RESET_PORT.

GNE>Тааак.. Я подозревал, что фильтр хаба не принесет плодов
GNE>Я слабо в этом разбираюсь, поэтому не подскажете ли Вы, как остановить устройство чтобы смог его пробудить IOCTL_INTERNAL_USB_RESET_PORT? Задать ему питание PowerDeviceD3? Или моя мысль неверна? Где можно откопать что-то по этим вопросам (откл/вкл питания на USB device)?

GNE>Зарание благодарен,
GNE>iGNER

При ошибке ЮСБ устройство входит в состояние STALL — для возвращения его к нормальной работе и используется IOCTL_INTERNAL_USB_RESET_PORT. Т.к ЮСБ драйвера как правило пнпшные то они обрабатывают системные IRP когда необходимо изменить свое состояние в плане питания. Соответственно проделав эту работу самостоятельно можно жобиться аналогичных результатов. Подробнее об этом почитать можно в книге Walter Oney "Programing WDM"