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

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

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

GNE>Хмм... Перезапуск устройства можно сделать из USER-mode. Вот фрагмент кода из SniffUSB:

GNE>//начало кода//
GNE>HDEVINFO m_devInfo;
GNE>SP_DEVINFO_DATA m_devInfoData;
GNE>int m_nDevIndex;

GNE>// ..............
GNE>// здесь вы находите m_devInfo — устройства, которые удовлетворяют вашим требованиям
GNE>// m_devInfo = SetupDiGetClassDevs (...
GNE>//
GNE>//m_nDevIndex — индекс устройства в m_devInfo.
GNE>// ..............


GNE>SP_PROPCHANGE_PARAMS params;

GNE>memset(&params, 0, sizeof(SP_PROPCHANGE_PARAMS));

GNE>params.ClassInstallHeader.cbSize = sizeof(SP_CLASSINSTALL_HEADER);
GNE>params.ClassInstallHeader.InstallFunction = DIF_PROPERTYCHANGE;

GNE>params.StateChange = DICS_PROPCHANGE;
GNE>params.Scope = DICS_FLAG_CONFIGSPECIFIC;
GNE>params.HwProfile = 0; // current profile

GNE>if(!SetupDiSetClassInstallParams(m_devInfo, &m_devInfoData,
GNE> (PSP_CLASSINSTALL_HEADER) &params,
GNE> sizeof(SP_PROPCHANGE_PARAMS)))
GNE> {
GNE> TRACE("in RestartDevice(): couldn't set the install parameters!");
GNE> TRACE(" error: %u\n", GetLastError());
GNE> return FALSE;
GNE> }

GNE>// restart the device
GNE>if(!SetupDiCallClassInstaller(DIF_PROPERTYCHANGE, m_devInfo, &m_devInfoData))
GNE>{
GNE> TRACE("in RestartDevice(): call to class installer (STOP) failed!");
GNE> TRACE(" error: %u\n", GetLastError() );
GNE> return FALSE;
GNE>}
GNE>//конец кода//


GNE>А вообще, стоит посмотреть DevCon от Microsoft — консольный аналог Менеджера Устройств. Исходники есть в XP DDK. Он позволяет удалять усройства, рестартовать, проверять, нет ли новых подключенных и т.д.

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

Любое устройство при конфигурации возвращает номер порта при запросе от своего драйвера
Подробнее об адресации:
More About Device Addressing
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.

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