As discussed in the driver introduction the driver is responsible for interfacing with the pointer device hardware (touch screens, pens, digitizers etc) to receive incoming co-ordinate data.
Thereafter, this data can be posted by the driver into the operating system in various ways to control the system pointer or interface with the underlying input subsystem to interact with any native touch features built into the OS.
Applications can also register to receive co-ordinate data via the driver's API and implement their own system interface as required, as is the case with our own UPDD Commander application under MacOS and optionally under Windows.
Where the driver is configured to post touch data into the OS, this is generally referred to this as 'mouse emulation' and there is a setting used to disable this emulation if another application is receiving touch data from the driver via the API and dealing with the touches.
If the driver is posting touches into the OS, there are two settings to indicate what interface to use. For UPDD V6 the device setting is called active_touch_interface, and for UPDD V7 it's called active_pointer_interface. These settings are referenced by the driver if mouse emulation is enabled.
These settings are set in the UPDD Console, touch interface dropdown. For macOS there is only one driver interface, hence this setting is not shown in macOS.
You can also use the UPDD Command Line utility to set this setting, using the command 'upddutils device n set active_touch_interface [interface type]' - n = device handle, (default 1 if 'device n' not included), interface type = as listed below.
If this setting is not defined or the setting is blank, then the driver will select an appropriate default interface for the operating system as follows:
|Default system interface
|Virtual HID interface (if it is present and the Windows 'tablet' component also exists) otherwise the single mouse interface.
XP - No Virtual HID or tablet components will exist.
For WES7 note that only WS7P contains the table component. WS7E and WS7C do not appear to contain the tablet component.
All other Windows editions should have both the Virtual HID and tablet components present.
The tablet component is deemed to exist if the registry entry HKLM\SYSTEM\\CurrentControlSet\services\TabletInputService branch exists.
If this does not exist, you may need to enable it in the system.
|Uinput single touch events
|Simple touch client interface is used (unless Commander module is loaded, in which case Commander has its own interface)
- Most UPDD Mac installers install the driver plus Commander, so it is likely that Commander is actually in control of posting the touch data. Commander is not bound by this setting. Only the driver references this setting should Commander not be in control of posting the touch data, either because Commander is configured to not post data or it has been stopped.
- If you switch interfaces there is a possibility that calibration may be lost, especially if switching in a complex multi-monitor system in Linux whereby the internal kernel video mapping using uinput could be different when switching to X or vise-visa.
UPDD components implement a number of system interfaces:
| A basic single touch, mouse type, kernel interface for Windows XP and higher
| A multitouch Virtual HID interface for Windows systems running Pen Services (native touch support)
|Post data on most appropriate interface based on device characteristics
|An experimental method to post touch data directly into an application, bypassing the OS mouse and touch processing
| A basic single touch interface that works only when a user is logged in (core graphics library)
| Linux xtest interface
| Linux event system interface - requires the uinput component to be discovered
| The UPDD Commander utility processes touch events and gestures.
Given that client applications can also be used to interface with the system pointer or input subsystem, then to aid synchronization between these applications and the core driver interfaces the active_touch and active_pointer interface settings are used to indicate what interface is currently enabled. The setting is passive, in that it does not in itself invoke the described functionality, but is used to indicate the interface in use, against which tests can be performed by any components that implement a system interface.
If another process wishes to control the touch interface with the OS, or if the current interface is to be disabled, then the setting should be changed to a custom name or set to a dummy value. Specifying the name here hands control to the custom interface. Such an interface implementation should also check the value of this field and only deliver touches into the system if this value matches the custom name, as described here.
If under Windows you wanted to disable the Virtual HID interface and revert to single touch mouse interface, then set the setting to tbupddsu. The driver will only post to this interface irrespective of the presence of the Virtual HID interface.
i.e. upddutils set active_touch_interface tbupddsu
If a 3rd party UPDD client application wanted to process incoming data and post the data to a specific application only, for example to satisfy the native touch event API only within that application, then set this setting to a non-standard value and data will no longer be posted via one of the standard interfaces.
If you utilised the standalone UPDD TUIO server interface (not UPDD Commander TUIO server option) to post touches into TUIO client applications and only wanted TUIO client applications to work with touch, then set this setting to a non-standard value and data will no longer be posted via one of the standard interfaces.