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.p
Thereafter, this data can, if required, 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.
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 a device setting, active_touch_interface (A_T_I), is 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 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
||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 multi touch Virtual HID interface for Windows systems running Pen Services (native touch support)
|| An experimental method to post touch data directly into an application bypassing the OS mouse and touch processing
|| A basic single touch client 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 (Touch events and gestures)
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.