Universal Remote Control USB Devices Driver

-->

The USB-UIRT is a USB version of the now-notorious UIRT (stands for Universal Infrared Receiver Transmitter). The USB version offers a simple plug-and-play solution without having to deal with some of the hassles of the classic serial-port (RS-232) version.

• Your ISY does not need to be babysat, it is not a glorified remote control app on your mobile phone. Neither is it some magical essence in the cloud that might take a break once the Internet is down. Neither is it some magical essence in the cloud that might take a break once the Internet is down.
• However, this configuration involves installing the URC USB Sync MX device driver - 'this is not what you want.' However, you have to go through this step (somebody else might know of a more optimal path to the next step). With your MX-XXX awake if you go to the Device Manager you will see your remote under Mobile Devices.

This topic describes best practices about implementing the remote wakeup capability in a client driver.

USB devices that can respond to external wake signals while suspended are said to have a remote wakeup capability. Examples of devices that have a remote wakeup capability are mice, keyboards, USB hubs, modems (wake on ring), NICs, wake on cable insertion. All of these devices are capable of producing remote wake signaling. Devices that are not capable of generating remote wake signaling include video cameras, mass storage devices, audio devices, and printers.

Drivers for devices that support remote wakeup signaling must issue an IRP_MN_WAIT_WAKE IRP, also known as a wait wake IRP, to arm the device for remote wakeup. The wait wake mechanism is described in the section Supporting Devices That Have Wake-Up Capabilities.

When Does the System Enable Remote Wakeup on a USB Leaf Device?

In USB terminology, a USB device is enabled for remote wakeup when its DEVICE_REMOTE_WAKEUP feature is set. The USB specification specifies that host software must set the remote wakeup feature on a device 'only just prior' to putting the device to sleep.

For this reason, the USB stack does not set the DEVICE_REMOTE_WAKEUP feature on a device after receiving a wait wake IRP for the device. Instead, it waits until it receives a IRP_MN_SET_POWER request to change the WDM device state of the device to D1/D2. Under most circumstances, when the USB stack receives this request, it both sets the remote wakeup feature on the device and puts the device to sleep by suspending the device's upstream port. When you design and debug your driver, you should keep in mind that there is a loose relationship between arming a USB device for wakeup in software, by means of a wait wake IRP, and arming the device for wakeup in hardware by setting the remote wakeup feature.

The USB stack does not enable the device for remote wakeup when it receives a request to change the device to a sleep state of D3, because according to the WDM power model, devices in D3 cannot wake the system.

Why Does Attaching or Detaching My Device Produce a Different Wakeup Behavior in Windows XP and Windows Vista and later versions of Windows?

Another unique aspect of the USB implementation of the WDM power mode regards the arming of USB hubs for remote wakeup. In Microsoft Windows XP all hub devices between host controller and the USB device are armed for wakeup whenever the USB device is armed for wakeup. This produces the surprising consequence that when sleeping devices are detached they will wake up the system.

In Windows Vista and later versions of Windows, if a USB leaf device on the bus is armed for wake, the USB stack will also arm the USB host controller for wake, but it will not necessarily arm any of the USB hubs upstream of the device. The USB hub driver arms a hub for remote wakeup only if the USB stack is configured to wake up the system on attach and detach (plug/unplug) events.

Note UHCI (Universal Host Controller Interface) USB host controllers do not distinguish between remote wake signaling and connect change events on root hub ports. This means the system will always wake from a low system power state if a USB device is connected to or disconnected from a root hub port, if there is at least one device behind the UHCI controller that is armed for wake.

Related topics

As our devices get more and more complex, configuring them gets harder and harder. And for members of the non-tech-savvy public, close to impossible.

Here's an answer: Develop a simple browser plug-in for all platforms that can connect a USB peripheral to a TCP socket back to the server where the plugin page came from. (This is how flash and Java applets work, in fact this could be added to flash or Java.)

Remote Control Usb Switch

Once activated, the remote server would be able to talk to the device like its USB master, sending and receiving data from it and talking other USB protocol commands. And that means it could do any configuration or setup you might like to do, under the control of a web application that has access to the full UI toolset that web applications have. You could upload new firmware into devices that can accept that, re-flash configuration, read configuration -- do anything the host computer can do.

As a result, for any new electronics device you buy -- camera, TV remote control, clock, TV, DVD player, digital picture frame, phone, toy, car, appliance etc. -- you could now set it up with a nice rich web interface, or somebody else could help you set it up. It would work on any computer -- Mac, Linux, Windows and more, and the web UIs would improve and be reprogrammed with time. No software install needed, other than the plug-in. Technicians could remotely diagnose problems and fix them in just about anything.

So there is of course one big question -- security. Of course, the plug-in would never give a remote server access to a USB device without providing a special, not-in-browser prompt for the user to confirm the grant of access, with appropriate warnings. Certain devices might be very hard to give access to, such as USB hard drives, the mouse, the keyboard etc. In fact, any device which has a driver in the OS and is mounted by it would need extra confirmation (though that would make it harder to have devices that effectively look like standard USB flash drives into which basic config is simply read and written.)

One simple security technique would be to insist the device be hot plugged during the session. Ie. the plugin would only talk to USB devices that were not plugged in when the page was loaded, and then were plugged in as the app was running. The plugin would not allow constant reloading of the page to trick it on this.

Remote Control Usb Driver Download

For added security, smarter devices could insist on an authentication protocol with the server. Thus the USB device would send a challenge, which the server would sign/hash with its secret key, and the USB device could then check that using a public key to confirm its talking to its manufacturer. (This however stops 3rd parties from making better configuration tools, so it has its downsides.) It could also be arranged that only devices that exhibit a standard tag in their identification would allow remote control, so standard computer peripherals would not allow this. And the plugin could even maintain and update a list of vendors and items which do or don't want to allow this.

Universal Remote Control Usb Devices Driver Windows 7

There are probably some other security issues to resolve. However, should we resolve this it could result in a revolution of configuring consumer electronics, as finally everything would get a big screen, full mouse and keyboard web UI. (Non portable devices like cars and TVs would require a wireless laptop to make this work, but many people have that. Alternately they could use bluetooth, and the plugin could have a similar mode for working with paired bluetooth devices. Again, doing nothing without a strong user confirmation.)

Universal Remote Control Usb Devices Driver Download

This works because basic USB chips are very cheap now. Adding a small bit of flash to your electronics device and a mini-USB socket that can read and write the flash would add only a small amount to the cost of most items -- nothing to many of them, as they already have it. Whatever new toy you buy, you could set it up on the web, and if the company provides a high level of service, you could speak to a tech support agent who could help you set it up right there.