The driver supports both USB and Serial devices.
For serial devices you add the device in the UPDD setting / console program and set the serial port and the driver will connect to the port defined and if it exists the connection should be successful. There is no 'hot plug' detection of serial devices.
With USB devices the device does not need to be manually added into the system as it is automatically located by the driver. We refer to this detection process as USB enumeration.
USB enumeration is invoked:
- At driver start up
- 5 seconds after a device change notification is issued by the OS (A device change notification is only issued in Windows and MacOS)
- On a timing loop of every 10 seconds.
As part of the enumeration process the driver builds a list of connected USB devices and looks for any that are supported by UPDD that are not already connected and tries to access any new devices. If connection to the device fails, possibly the device is not yet ready during system startup or after hot plug, the device is 'reset' (to clear any errors) and the timing loop activation is reduced down to 5 seconds, hopefully giving sufficient time for the device to become available.
This means that most newly connected devices will be activated within 5 seconds of being connected in Windows and MacOS and 10 seconds in Linux. Once all devices are connected the timing loop activation is increased to 10 seconds.
In theory the polling loop activation is surplus to requirements in Windows and MacOS due to the other events that trigger the USB enumeration process but if was left in as a fail safe in the event of any of the other triggers failing to occur.
In an earlier implementation of the USB enumeration procedure the driver tried to access the device immediately upon receipt of the device change notification but it was found that in some cases, particularly under MacOS, the device was not ready and issued an error when accessed. This caused the driver to invoke a device reset and enumeration was set to be retried after 1 second. However, this occasionally resulted in an enumeration deadlock in that the device wasn't ready in 1 second time, reset again and repeated ad infinitum.
In some cases the device was immediately ready when connected and resulted in activation within 1 second. However, UPDD supports 1000's of touch devices and it is impossible to know how long each device will take to be available at start up or hot plug. Some devices have a different initialisation sequence when plugged into a non Windows system and will even switch HID report descriptors and this can introduce delays at both the device and OS level. For this reason it was considered prudent in recent implementations to set the retry to 5 seconds to avoid the possibility of a deadlock.
The enumeration time period of 5 seconds set after a device access failure can be lowered by adjusting the setting usb.enum_delay_after_force_claim using the command line interface e.g.
upddutils nodevice set usb.enum_delay_after_force_claim 4
Setting this too low could result in the enumeration deadlock as described above. You will need to experiment on a case by case basis.