Computer systems can be configured to save power when not in use which also has the benefit of prolonging the life of the hardware.
To this end systems can be set to turn off video output and place the system into various sleep states.
Sleep states are often determined by either configuration settings, inactivity duration or system type, mainly differentiating between desktop or notebook. In the case of notebooks sleep states can also be adjusted based on battery reserves or if the system is connected to the mains.
Sleep states can be light, with the minimum resources in sleep, or deep where nearly everything is in sleep bar the lowest level system functions.
Systems can be woken up by manual actions or automatically, such as network activity to wake up remote systems.
Manual actions are typically pressing on the start button, pressing a key on the keyboard, moving the mouse or opening the lid on a laptop/notebook.
When hardware devices are used to wake up a sleeping system the hardware will send out a signal on the bus that is used to wake up the system and this is needed to wake up systems that are in deep sleep or standby mode as in these states all programs will be in a suspended state.
Unfortunately, not all touch screens send out these signals and therefore cannot be used to wake up a system from deep sleep.
However, in systems that are in light sleep with drivers and applications still loaded, then the UPDD software will invoke a system function that will fully wake up the system.
This means that for touchscreens that do not send out the 'wake up signal' they will still wake up a system from light sleep.
Touches received when a monitor or system is sleeping are discarded to avoid unintended consequences of touching a blank screen.
Windows
Windows fully embraces the notion of touch devices being used to wake up systems. Windows sleep modes are discussed in this article.
Under Windows, devices handled by UPDD that can be used to wake a system from deep sleep will contain the Power Management tab to 'Allow this device to wake the computer' in the Device Manager.
If this checkbox is not shown, then the device does not have the ability to wake up a system from deep sleep.
UPDD V7
This version of the driver supports HID USB and i2c devices using a UPDD HID filter driver, so the core HID entries are retained in Device manager, and it is these entries that contain the Power Management tab.
The driver also supports legacy, non HID USB devices, resulting in a UPDD device entry in the Device Manage that can be used to enable the Wake on Touch feature
Non HID, USB devices
Since UPDD V7.1.73, for devices of this type there will be an entry in device manager 'UPDD Devices' which carries the appropriate option:
HID devices
In this example, taken from a dual touch screen system, there are various related listings in the Human Interface Devices entry.
In the screenshot below, the lower four entries relate to the two USB input devices and the two UPDD Virtual devices created to post touch or Pen data into the OS.
The top four entries show the proxy HID Compliant touch screen devices associated with the four actual devices, two of which are related to the 'USB Input devices' and two of which are related to the 'UPDD Pen & Touch' devices.
You need to select the HID Compliant touch screen entry that is associated with the 'USB Input Device' as shown, by right-clicking on the entry and viewing the association:
With the correct entry selected, switch to viewing the devices by connection type
This will allow you to see the device in the connection tree to allow you to enable the 'Wake on Touch' option.
Right-click on the entry, Properties and enable the checkbox if not enabled.
UPDD V6
If a UPDD supported touch device is capable of waking up the system then the Device Manager, UPDD Devices, device entry will contain the 'Power Management' tab:
macOS
Under macOSX, waking systems with non Apple devices and methods is less well documented, especially by Apple. MacOS sleep modes are described in this article.
The official line is that keyboard and mouse activity and opening a lid on a Macbook will wake up a system, but it is possible for touch/pen devices to wake up a macOS system if they perform the correct sequence of events on the USB bus as required.
However, it appears that the macOS WoT protocol differs from Windows sequence and not all 'Windows' WoT capable devices can wake up a macOS system.
Further, we have found that some touch devices can fail to function correctly on macOS if the remote wake-up feature is enabled in the device. Therefore, it is for this reason that the macOS UPDD driver 'clears' the remote wakeup feature by issuing the 'Clear Remote wakeup' USB Feature request by default.
For devices known to support remote wake up that disable the feature by the 'Clear Remote wakeup' request, the driver needs to be configured not to issue the request to the device.
There are a number of remote wakeup settings in the driver (value in bold = default)
| Setting |
Value |
Description |
remote_wakeup_mode
Available from build 7.1.43
|
none
partial
full |
partial - UPDD will set the updd managed device to low power state when the OS notifies the driver it is going to sleep
full - UPDD will set the updd managed device to low power state when there has been no touch activity for 60 seconds |
clear_remote_wakeup
Superceded by RWM above |
0,1 |
0 - do nothing, 1 - issue Clear Remote Wakeup USB feature |
set_remote_wakeup
Superceded by RWM above |
0,1 |
0 - do nothing, 1 - issue Set Remote Wakeup USB feature |
disable_remote_wakeup
Superceded by above |
0,1 |
As CRW above, but previous name used in UPDD V6. Ignored in UPDD V7. |
You can set the above with command line interface, e.g. upddutils set remote_wakeup_mode partial
When the system enters sleep, the driver is notified to this affect and records this in the driver logs:
OSXWillSleep() - notification
Thereafter, when a touch is processed whilst the system is 'sleeping', the driver then enters a wakeDisplay routine and issues a resume from sleep API and logs
Touch event while sleeping...
OSXWokeFromSleep ()
APIOperationCmdResumeFromSleep
This API appears to be the trigger to resume the system from sleep and turn on the peripherals, monitors etc
Often, during this sequence, the pending read on the device fails, logged as:
Error from async read: device not responding (IOReturn = 0xe00002e)
at which point the read is reissued and eventually recovers and the read returns touch data.
The above sequence of events only happens once the software is running and receiving a touch notification.
If the system is in a deep sleep, where all applications are dormant, it's required that the system is woken at the hardware level with a device that is capable of waking a mac system and where remote wakeup is enabled.
If the system is triggered to wake up from a deep sleep by the hardware, we are unsure if the software plays any role in the system returning from sleep, as it could be that the hardware signal is sufficient to initiate the full system resume sequence.