Появилась такая задача — работа с USBшной камерой...
иногда камера входит в непонятный режим, что требует ее перезапуска...
самый простой вариант — это сбросить питание, благо питается по USB...
Вопрос такой — как это сделать?
Здравствуйте, Cyr, Вы писали:
Cyr>Появилась такая задача — работа с USBшной камерой...
Cyr>иногда камера входит в непонятный режим, что требует ее перезапуска...
Cyr>самый простой вариант — это сбросить питание, благо питается по USB...
Cyr>Вопрос такой — как это сделать?
Хмм... Перезапуск устройства можно сделать из USER-mode. Вот фрагмент кода из SniffUSB:
//начало кода//
HDEVINFO m_devInfo;
SP_DEVINFO_DATA m_devInfoData;
int m_nDevIndex;
// ..............
// здесь вы находите m_devInfo — устройства, которые удовлетворяют вашим требованиям
// m_devInfo = SetupDiGetClassDevs (...
//
//m_nDevIndex — индекс устройства в m_devInfo.
// ..............
SP_PROPCHANGE_PARAMS params;
memset(¶ms, 0, sizeof(SP_PROPCHANGE_PARAMS));
params.ClassInstallHeader.cbSize = sizeof(SP_CLASSINSTALL_HEADER);
params.ClassInstallHeader.InstallFunction = DIF_PROPERTYCHANGE;
params.StateChange = DICS_PROPCHANGE;
params.Scope = DICS_FLAG_CONFIGSPECIFIC;
params.HwProfile = 0; // current profile
if(!SetupDiSetClassInstallParams(m_devInfo, &m_devInfoData,
(PSP_CLASSINSTALL_HEADER) ¶ms,
sizeof(SP_PROPCHANGE_PARAMS)))
{
TRACE("in RestartDevice(): couldn't set the install parameters!");
TRACE(" error: %u\n", GetLastError());
return FALSE;
}
// restart the device
if(!SetupDiCallClassInstaller(DIF_PROPERTYCHANGE, m_devInfo, &m_devInfoData))
{
TRACE("in RestartDevice(): call to class installer (STOP) failed!");
TRACE(" error: %u\n", GetLastError() );
return FALSE;
}
//конец кода//
А вообще, стоит посмотреть DevCon от Microsoft — консольный аналог Менеджера Устройств. Исходники есть в XP DDK. Он позволяет удалять усройства, рестартовать, проверять, нет ли новых подключенных и т.д.
У меня вот другой вопрос возник: как сделать рестарт девайса из kernel-mode (из фильтр драйвера). Например, повесить такой фильтр где-то на USB и отслеживать контролы к конкретному USB устройству, и ежели встречается IOCTL_INTERNAL_USB_CYCLE_PORT, отрубить питание самому а потом врубить. Только вот проблема, если фильтр будет висеть на самом устройстве, он выгрузиться (насколько я понял) при отключении питания и некому будет оное включить. Так что мне сдаеться, надо чтоб фильтр висел на USB hub-ах и если на одном его порту висит мое устройство и к этому устройству идет IOCTL_INTERNAL_USB_CYCLE_PORT, вырубить/врубить питание на порт.
Что в свою очередь пробуждает вопросы:
Как USB hub может узнать, на каком порту висит мое устройство?
Как USB hub может отловить, пришло ли к моему устройству IOCTL_INTERNAL_USB_CYCLE_PORT?
И наконец, как вообще отрубается питание в kernel-mode?
Regards,
iGNER
Здравствуйте, 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(¶ms, 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) ¶ms,
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.
Здравствуйте, 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.
Тааак.. Я подозревал, что фильтр хаба не принесет плодов
Я слабо в этом разбираюсь, поэтому не подскажете ли Вы, как остановить устройство чтобы смог его пробудить IOCTL_INTERNAL_USB_RESET_PORT? Задать ему питание PowerDeviceD3? Или моя мысль неверна? Где можно откопать что-то по этим вопросам (откл/вкл питания на USB device)?
Зарание благодарен,
iGNER
Здравствуйте, 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"
