There are multiple software and hardware components involved in communicating with a USB touch device. All of these must be in place and functioning correctly for UPDD to communicate with a device. When everything is working correctly, UPDD will be able to issue an interrupt transfer request on a USB endpoint. When the touch device sends data the transfer request is completed, UPDD receives the data and issues further requests. When no data is being sent from a touch device UPDD will, if all is okay, be awaiting an interrupt request completion.
When UPDD is able to receive data from an endpoint we refer this as a connected status. To be connected, the physical connection (cable) must be in place, the appropriate software components installed, the firmware and software in the hardware devices must be able to exchange information according to the USB protocol. In general this should “just work”, this guide gives a few points that can be looked at in troubleshooting. From an end users point of view if UPDD is not showing a connected status and assuming that the UPDD package supports the device in question then checking the hardware is the only practical option.
If a USB device is connected to UPDD then it is listed with an active icon in the Console as shown by the Dell P2418HT example below:
If a USB device is not connected to UPDD then it is listed with an inactive icon in the Console (if previously listed as connected) as shown by the Dell P2418HT example below or not listed at all (if it has never been listed):
The same information is available using the upddutils devices command.
A connected device is shown with status OK:
A not connected device is not listed or shown with NOK.
When a device is listed as not connected but it is physically connected there are a few things that can be checked.
The UPDD device package must be configured to support the vendor and product of the touch device.
The Console Devices -> Supported tab lists the supported devices and the vendor / product ids as shown below:
The format is <vendor id>;<product id>;<optional reserved value>
Each of these elements can be a single value, a comma separated list or a range (e.g. 1-5).
So in the example above Dell devices with a vendor ID 1FD2 and product ids 6103 or 8105 are supported.
This document describes how to see the vendor and product ids of a device in the system's hardware list.
If a supported attached device is not listed by UPDD or listed as disconnected you should start by checking if the operating system lists the device.
In MacOS the device should be listed in the system report, under Hardware->USB:
Note that when the operating system initially interacts with a device, known as enumerating the device, various information is read from the device.
We occasionally see that the detail pane (bottom right in he screen shot above) is incomplete. This appears to occur when the one or more of these read operations fail and is an indicator of a hardware fault or an incompatibility between the operating system or the computer’s USB hardware (e.g. USB host controller) and the touch device.
In such a case typically the operating system does not recognise the device fully and as far as client drivers are concerned the device is simply not present.
On a Windows system the USB connected device is listed under UPDD Devices in the device manager:
The name of the device will match that of the device in use. Right click and select Properties you should see this:
In some cases the device might be listed under HIDClass, but so long as it has the UPDD icon and is shown as working properly it should be okay.
If the device is listed under Human Interface Devices as a USB Input device.
Then UPDD will not be able to access the device. NB the UPDD Virtual HID devices do not relate to the USB connection. Unfortunately Windows lists all HID devices with same name. Select Properties -> Details -> Hardware IDs to see the vendor and product ID of each device. Alternately use a 3rd part tool such as USBView or USBlyzer
UPDD Log files
Some additional information can be seen from the UPDD log.
The log file is found at
Mac OS /Library/Preferences/updd/log/updd.log
Windows c:\ProgramData\updd\log
Linux /opt/updd/data/updd/log/updd/log
By default updd.log omits data that might impact performance, such as data emitted for each touch packet.
To see full debugging information take one of the following steps:
Enable boot logging
Run diagnostics
Explicitly set logdebughigh=y in updd.ini
The key point to look for is the “read starts” message.
This message shows that a USB interrupt request is initiated and the driver is waiting for data from the device.
In normal use the driver waits at this point. There will be other messages periodically (typically every 10 seconds) but there should be no error messages.
It is at this point that UPDD will report a device as connected.
The event above is only shown if all setup operations are completed successfully.
If this event is not seen then likely the device is not visible to UPDD. In the log a list of accessible devices is shown periodically.
Additionally in MacOS a check is made using a lower level interface (IOKit).
If, as in this case, a supported device is found that is not available using UPDD’s standard interface then an OS specific mechanism to try to claim control of the device is invoked.
Note it is quite normal to see errors at the start of the log. If UPDD can’t properly access the device it will attempt to claim the device and try again. Errors are only significant if they are repeated and thus prevent the “read start” logic being reached or occurs after “read start”.
There is a lot of additional information in the log, but nothing that is likely to be useful to an end user.
For a firmware engineer the details of all USB requests are logged and should be clear.