Some features and functions are referenced in the UPDD documentation that requires further explanation. Here it is!
Double clicking on a touch screen relies on double click related settings set to a tolerance that allows a touch screen to be used to generate the double click. In Windows, for example, there are 3 such settings, DoubleClickSpeed, DoubleClickWidth and DoubleClickHeight. These settings establish the width of the rectangle that Windows uses to detect double-clicks. If sequential clicks are positioned within the rectangle defined by DoubleClickHeight and DoubleClickWidth, and occur within the time specified by DoubleClickSpeed they are interpreted as double-clicks. Otherwise, they are interpreted as sequential single clicks.
When UPDD is installed it sets these internal settings (for the user performing the install) to values that cater for finger double click usage. In our old version 3 driver dialog we allowed these system setting to be changed. However, our version 4 dialog calls the system’s mouse dialog to change double click settings, as seen below:
Most of these mouse dialogs allow the double click speed setting to be changed and this must be a slow (ish) setting to allow for touch double clicks. Too fast a setting will prevent double clicks. The other related settings can be found in the registry at HKCU\Control Panel\Mouse. The Width and Height default settings are 4 pixels and the speed is 500 milliseconds. UPDD sets these settings to 32 and 370 respectively.
If a new user logs in they will get the default Windows double click settings which may make it difficult to double click. With UPDD version 4.1.6, build 1156 and above, the UPDD daemon task monitors the users. When a new user logs in it automatically sets these settings.
Settings changed by 3rd party software
There have been cases of double click difficulties following the installation of mouse drivers that have set these settings to values that prevent touch double clicks requiring the setting to be reset to ‘touch’ values.
Disabling double click
This is not a driver issue but a system issue. If touch double click is to be disabled we suggest that the settings be set such that it is almost impossible to achieve a double click with touch. Try Height and Width = 1 and Speed = 200 – see below.
Should you need to manually set the registry for the Double Click Settings these lines can be copied to a .reg file and double clicked to update the registry settings:
Registry Editor Version 5.00
On Windows XP the DoubleClickSpeed ranges from 200 (Fast) to 900 (Slow)
If using UPDD version 5.0.x you can use our command line processor o change these values, such as “tbutils nodevice setting dw DoubleClickHeight 64”.
OS double click options
One potentially useful setting in Windows, when using the desktop via touch, is to invoke icons, folders and files using a single click rather than double click. This setting is located in the folder options as shown below:
Mac OS X
Under Mac the Mouse dialog is as follows:
UPDD generated double click settings
For a future release of UPDD we are considering processing our own double click setting for situations where it is still difficult to achieve a double click using system DC setting with certain touch devices such as slow infra red devices. In this case where UPDD DC setting deduce that a double click is required then two complete click sequences will be sent at the same location very quickly which will result in a double click.
Since UPDD 4.1.6, build 1156, a serial controller can be set for auto-detection rather than set to a specific com port. This option is only available, and enabled, where a serial controller can receive and acknowledge a firmware command. Controller commands are held in UPDD macros. Typically a macro sequence used to detect a controller would look like this:
[HEX]0A0141 //Check Controller Activity
In this example the driver sends 0A0141 to the controller which is echoed by the controller by way of acknowledging receipt.
Some macros are needed for controller initialization rather than just containing commands to illicit a response but as long as the controller responds to the received commands then the macro can be used to detect the controller.
When the controller is set for Auto detect the driver issues the macro to each com port in turn looking for the response. If a response is received then the com port is set accordingly. If no response is seen from any port then the com port is set to ‘None’. Each time UPDD is loaded it will automatically detect the device but on 2nd and subsequent attempts the detection will initially check the current port setting before checking thro each port in sequence.
Setting serial controller for auto detection
There are various ways to indicate a serial controller is to be auto-detected as follows:
In the majority of cases touching a touch screen or similar device will normally be the equivalent of generating a mouse left click. However, in some cases it is also desirable to be able to generate a right click via touch. With UPDD there are a number of possible methods; Right click trigger in the data stream, the Event Selector (to indicate if the next touch should generate a left or right click), using Interactive Touch mode (which caters for both left and right clicks) or using the right click mechanism built into the operating system; as described below.
Where Extended touch feature is enabled and thus utilising the OS in-built right click functions any UPDD native right click processing is disabled.
Right Click data trigger
Some devices, such as a Pen, may have a barrel switch that when pressed will alter the data packet delivered to the driver to indicate the switch is depressed. Our driver can be configured to act upon triggers in the data packet which can be set to perform certain functions, including Right click. If a device is configured in such a way and the data trigger is assigned to a right click function then pressing the switch will generate a right click.
The UPDD Event Selector, in its most simple terms is a user controlled trigger that indicates to the driver if the next touch should be a left or right click. Click the link for more details.
Operating System feature
The operating system may cater for right click generation using a pen or touch device and in some cases this can be utilised by the driver, as discussed below:
If using UPDD 4.1.8 and above in touch enabled versions of Vista or Windows 7 there is a setting in UPDD, called Extended Touch, that passes touch data to the OS such that all touch features built into the OS are available to the touch user. In the Pen and Touch system settings you will find some settings specific to touch and you can associate a right click to one of the actions as shown in this Windows 7 example
In our controller definition database we allocate default controller names to help identify the manufacturer, model and interface, e.g XYZ Inc, M123, USB or a name as requested by the manufacturer or system integrator.
In the UPDD Console there is a Device list entry that shows the currently selected device and, if more than one device is configured on the system, offers a dropdown list to select other devices.
If another controller of the same type is plugged in then the driver will allocate a unique name based on the name of the controller along with a bracketed number i.e. XYZ Inc, M123, USB (2), XYZ Inc, M123, USB (3) etc
Each controller discovered on the system is allocated a unique bind key to help associate and identify UPDD controller settings with individual controllers as they are unplugged, replugged or rediscovered, such as after a reboot.
In a 3 touch monitor device with all devices connected the device list would be seen as:
XYZ Inc, M123, USB
XYZ Inc, M123, USB (2)
XYZ Inc, M123, USB (3)
Any PnP devices that are unplugged would have their name displayed in red. So unplugging (2) would result in the device list as follows:
If the controller is subsequently reconnected, then the driver will calculate the bind key to find the previous entry and settings and re associate the device with its previous settings.
However, if the device in red is deleted from the UPDD console (using the ‘Remove a device’ option), leaving two entries:
XYZ Inc, M123, USB
XYZ Inc, M123, USB (3)
then the next time the device is connected no previous settings will be found and a new device entry will be created. Given (2) is the next unique device name then the device will reappear as XYZ Inc, M123, USB (2) but will be allocated default settings which may need manually adjusting.
Our recommendation is to not delete devices if they are to be reconnected at some future date.
Controller names can be manually adjusted once the device is listed in the UPDD Console device list. Simply select the device, click on Properties and change the name. In a three touch monitor system you could name the controllers to reflect their position on the desk, say Left, Middle, Right as shown below:
In this instance, plugging in a 4th controller would result in the name of the new controller being XYZ Inc, M123, USB.
UPDD utilises two daemon (background) processes;
TBdaemon, dedicated to Windows background functions
Aidaemon – that caters for cross platform functions or functions that will eventually become available across all platforms.
Implements functions that are used across all platforms.
The daemon task is invoked at system startup due to the ‘aidaemon’ registry entry in the Windows run branch HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Appropriate startup methods are used in other OS.
The daemon task is responsible for the following functions:
Under Windows desktop version of the driver the software utilizes a daemon (or background) task to implement certain functions related to the driver and user interface. The program is called TBdaemon.exe and resides in the UPDD application folder. In UPDD version 3 this program was called TBsystry.exe.
The daemon task is invoked at system startup
due to the ‘tbdaemon’ registry entry in the Windows
run branch HKEY_LOCAL_M
The daemon task is responsible for the following functions:
A pointer device generates data packets when in use, such as touch packets whilst a stylus is in contact with a touch screen. When the device is no longer in use then obviously the data packets will stop being generated. A driver or application may need to perform a specific function at this point, such as pen up processing if the device is being used in mouse emulation in an appropriate mouse click mode.
Most touch screen devices, but not all, will indicate in the last data packet that the stylus has left the screen. These data packets are often referred to as the pen up or lift off packet.
If a device has a pen up packet defined in the UPDD controller configuration then there is a UPDD Setting called “Use Lift Off packet”. This setting can be set in the UPDD settings file as appropriate or via the UPDD Console, properties page and is enabled by default.
UPDD will generate a pen up in mouse emulation mode when
· the ‘pen up’ packet is seen (and pen up processing is enabled)
and/or when data
packets cease (if Lift off time processing is enabled).
This approach caters for all methods of ‘pen up’ detection:
· The device generates pen up packets
· The device does not generate pen up packets
· The device generates pen up packets but due to communication error is not received or is corrupted.
To generate a pen up where data packets cease there has to be a short wait prior to generating the pen up to ensure the data has stopped rather than being a gap between the packets. In UPDD this short wait period is referred to as the Lift Off time settings, as described below.
Lift off time setting
The Lift off Time
value specifies the time interval required to register a stylus lift after
the last touch packet is received. Lift off time is defined in units of 20ms.
This value is used to perform a pen up if the ‘Use Lift off’ packet is
disabled otherwise Pen ups are generated as soon as the stylus leaves the
pointer device display.
Delta mode considerations
Delta mode refers to a pointer device mode whereby data packets with the same X and Y coordinate values (i.e. the stylus it stationary) are not sent by the device. In this mode, UPDD will generate a pen up when the stylus is held stationary. To cater for this situation a lift off time value of zero is defined to disable pen ups based on time.
The ‘Lift off time’ and ‘Use pen up packets’ settings can be set via the UPDD Console, Properties page or directly in the UPDD settings files:
If the console is not available the setting can be found in the UPDD settings files as follows:
Within the files will be a branch ‘Parameters’. With UPDD 4.0.x this will be followed by a GUID number (a very large number). For each controller there will be a controller number 1,2 etc. Therefore the location for a single controller system will be:
liftofftime=0x0000000n (n = 0 = disabled or lift of time value in units of 20ms)
use liftoff bit =0x0000000n ( n = 0 = disabled, 1 = enabled)
With release 4.1.10 we hope to release the first version of the UPDD Advance Console.
The standard UPDD Console shows the basic driver settings and allows them to be updated. However, there are many other settings that may occasionally need to be updated and the Advance Console is being created to offer a GUI interface to these settings. Currently these settings need to either be set as required as default or updated manually.
Once this utility is available a separate web document will be created to document features and usage.
With release 4.1.8 we have implemented Windows Live annotation function. This function allows a touch screen user to annotate over a live desktop. Annotation can be enabled, disabled, paused and erased. The line colour and width can also be defined.
This functionality came about from a project we undertook for a cable television company to allow a presenter to annotate over a live Windows desktop showing financial data. The presenter uses UPDD Toolbars at either side of the larger touch display (with no desktop visual representation – so not seen by the viewer) to invoke the annotate functions as required.
Annotation functions can be controlled via UPDD API calls and we have implemented two user interfaces of our own, as discussed below:
The UPDD toolbar interface implements toolbar cell actions to control all annotate functions. An example of an Annotate toolbar is described in full in the toolbar documentation.
UPDD Console interface
The UPDD Console, Extensions dialog, exposes a simple UPDD interface to the Annotate functions.
Annotate API calls
The annotate settings:
Are set via the standard api followed by TBApiApply
Color is a Windows COLORREF value NOT RGB; example
COLORREF cr = RGB(r,g,b);
TBApiSetSettingDWORD(0, "AnnotateColour", cr);
There’s no API to clear. This can be achieved as follows (C++ example)
#define WM_DOCLEAR 4365
GetClassNameA(hWnd, className, sizeof(className));
:PostMessage(hWnd, WM_DOCLEAR, NULL, NULL);
The values for mode are
If annotation is in a stopped state then activedw.exe must be launched to activate annotation.
Setting stop will cause activedw.exe to terminate.
A primitive touch logging facility was added to UPDD 4.1.8 build 1784 to allow for the logging of touch data reported in screen co-ordinates (pixels) with the origin (0,0) at the top left. This logs first and last touches. This facility was added to allow for a customer to match touches against application layout to help track what they considered to be a ‘user usage’ issue rather than an application issue. If any other coordinate data is required (e.g. raw controller coordinates) please let us know.
To enable logging use the following command to define and enable the logging setting in tbupdd.ini:
UPDD 4.1.8 - tbcalib Device=0 /settingsz:logging=Y
UPDD 4.1.10 – tbutils nodevice setting sz logging Y
and restart the computer or reload the driver (UPDD Console, Status, Reload driver settings)
recording starts as soon as the driver is loaded.
reporting starts as soon as the windows desktop is fully loaded and the screen is touched (i.e. at least one touch is required on an active system to write the log).
use tbcalib Device=0 /settingsz:logging=N to stop logging
C:\Program Files\UPDD>type upddlog_20100718_202531.log
2010-07-18 20:25:31 - left touch down @ x=688 y=619
2010-07-18 20:25:31 - left touch up @ x=688 y=619
2010-07-18 20:25:31 - left touch down @ x=688 y=618
2010-07-18 20:25:31 - left touch up @ x=674 y=438
2010-07-18 20:25:32 - left touch down @ x=475 y=316
2010-07-18 20:25:32 - left touch up @ x=465 y=383
2010-07-18 20:25:39 - left touch down @ x=1180 y=773
2010-07-18 20:25:39 - left touch up @ x=1179 y=771
The name of the log is based on the date and time the log file is created. Each entry is time stamped.
When the driver is installed it sets up the settings for any configured controller based on the default settings delivered as part of the driver setup or components. In some cases, as an end user, you may wish to configure a system and then capture these settings for use with subsequent installations. In Windows we have a Clone option to clone setting for use with subsequent installs but this has some limitations and is being superseded with this new custom settings file, which is called extra.ini.
For any given touch controller updd custom settings can be defined and embedded in the driver package such that when the controller is configured in the driver any settings defined in the custom settings file will be applied to the controller.
The custom settings file currently caters for the following settings:
General driver and system configuration settings
Define any dword or string scalar driver setting.
Define any dword or string scalar value associated with a controller.
[extra-controller name] – Controller name related to the subsequent settings
Setting name=Value – Setting name and value
[extra-Quanta Computer, Dual, USB]
first touch calibration=0x00000001
Toolbar calibration settings
Pre-define toolbar calibration
ntoolbars=N (where N=no of toolbars)
and for each toolbar (1st N = 0, 2nd N = 1, 3rd N = 2 etc)
CalX0 Toolbar N=0x00000nnn
CalY0 Toolbar N=0x00000nnn
CalX1 Toolbar N=0x00000nnn
CalY1 Toolbar N=0x00000nnn
Other settings will be catered for as the need arises.
Once the extri.ini file is created it can be embedded in to the setup program we supply to you.
Since UPDD version 5.1.827 the setup file can be placed externally with the setup file to be used in subsequent installs.
1) On windows systems extra.ini files can be stored in the subfolder .\updd_ext relative to the location of the setup*.exe file on the installation media allowing most settings to be customised by an integrator.
2) On Linux systems the extra.ini file can be embedded in the installer (tgz) file with the path ./opt/tbupddlx/extra.ini to achieve the same.
3) For OS/X the extra.ini file can be combined with the UPDD.pkg file (extracted from updd.dmg) using the ‘disk utility.app’ to create a modified disk image updd.dmg.
Currently, the installation works by copying the extra.ini settings into a special section [Extra] of the main setting file, tbupdd.ini. When a device is configured manually or via the PnP manager then any settings defined in this section that relate to the new controller are applied.
When considering the need for customized settings, please consider the following:
1) Are these settings we can define as the default settings and deliver a package that does not need cloning or extra.ini?
2) Can the settings be supplied to us in extra.ini for use in your delivered software?
3) Under Windows, can you utilize the ‘old’ clone method (until improvements to the extra.ini mechanism are available)
Are your custom settings to do with
calibration? If so, there are various ways we can embed default calibration
setting for you and customized settings are not necessarily the best approach. See, for example, TBcalib dump4tba
command. Since UPDD version 5.1.827 this command now dumps the calibration
data in a extra.ini file.
Important note: The last line of the extra.ini file must have a new line such that the last entry is a blank line
The UPDD driver is aware of ‘Events’ that can be generated
by a device and all devices inherit the default event associated with the
touch and release of a stylus on the device. Each Event can have two
associated click modes referred to as the Primary and Secondary modes and
these modes are described in great detail in the Mouse Emulation document. In standard touch screen usage the primary
mode is normally associated with single left click mouse emulation and the
secondary action is set to single right click mouse emulation. The current
active mode is dictated by an internal setting call the
Extended touch consideration in
With extended touch enabled the Event Selector mechanism is disabled. Under Extended touch, using the systems HID interface we are not aware of an external method of generating a right click request. Extended touch has its own right click mechanism build into the operating system.
Currently not available.
Mac OS X
Available since UPDD 4.1.10, released 21st Oct 2010.
Event Selector Utilities
We have implemented a number of different Event Selector utilities as discussed below. Some are OS specific as indicated:
This overview should be viewed in conjunction with the mouse emulation documentation.
A controller is defined in the UPDD Controller database.
As part of the definition we specify the events that can be generated by the
device. Some have more than one event,
however, all touch devices have the default event defined which relates to
the first and last touch. Each Event can have two click modes associated with
the event, the Primary action (Mode) and Secondary action (Alternative
Mode). For each device UPDD holds an
internal state (
Event Selector API
An application can call the TBApiSetEventSelectorState(n) to switch to the primary or secondary modes as required. n = 0 = Primary or n = 1 = Secondary. When changed any active event selector utility will automatically reflect the state change.
The function has been superseded in UPDD version 5.0.2 with the Touch Pad function below.
A touch screen type device would normally function in absolute mode, that is, the system pointer or touch activation point would be directly under the point of contact. However, in some cases there is a requirement to operate a touch screen in relative mode such that the movement of the system pointer is relative to the point of contact (similar in operation to a touch pad or mouse). However, given that touch screens generate absolute co-ordinates then additional processing is required to convert the absolute touch to a relative movement. Touch Mouse implements a relative pointer device along the lines of a “trackpad” device. This feature currently only works with the system primary monitor.
Newly reinstated in UPDD 4.1.8 build 1948 this function is enabled and configured by the following settings:
By default a click is generated on first touch. Other button modes can be utilised by setting “event mode 0”=<mode>. See Mouse Emulation documentation. For example set this to “none” for no automatic click. In this case a toolbar can be used to implement the mouse buttons.
The function was introduced (and only works in) UPDD version 5.0.2 and supersedes the Touch Mouse function above.
Starting with UPDD version 5.0.2 a new option is available to emulate a ‘touch pad’ similar to that found on laptop device using a “touch screen” input device.
When utilising this function the touch screen input device will typically not be attached to a monitor as with a normal touch screen but will still be operating in absolute mode. The absolute co-ordinate input is converted to relative motion as needed for touch pad emulation. There is additional support for multi fingered operation where the device supports it.
This feature replaces the previous “Touch Mouse” option from earlier versions. It supports the same features and more.
The following modes of operation are supported for generating button clicks
Multi touch and gestures
When two or more concurrent touches take place the secondary touches are passed to the operating system at a position relative to the current primary touch point based on the vector between the primary and each touch and a predefined metric. This allows full support for gestures using 2 or more fingers. Single touch gestures, such as flicks, are not possible because it is difficult to distinguish between single fingered gestures and normal movement. The reliability of the gestures depends to a large extent on characteristics of the input device. UPDD for the most part is passing this data directly to the OS. When using multi-touch with the Touch Pad in button mode the touches must be outside of the dedicated button area.
The operation of this feature is defined by a number of settings to allow tailoring to a specific device. Some might usefully be adjusted to suite a specific user.
Some of the settings refer to “dwell”. When a primary touch starts it is unknown if this is the start of a single touch or the start of a multi finger gesture.
The software will therefore not pass through mouse events until one of the following occurs.
The period during which events are held in this way is known as the dwell period.
If using the command line utility to define the settings the ‘Type’ parameter shown against each setting indicates the setting type which is reflected in the tbutils command e.g. ‘tbutils setting dw touchpad 1’ is the command used to enable the touch pad function.
This function is effectively utilising the device in two
modes of operation, single touch mouse and multi-touch digitizer.
Occasionally you may wish to, for whatever reason, disable touch for a device or disable the mouse emulation interface.
The driver can be prevented from processing any touches from a device. This can be set in a number of ways:
1) Command line interface passing parameters enable or disable
2) UPDD Console, Properties, Enabled checkbox (check or uncheck)
3) Windows - UPDD System Tray, Enabled option – select to toggle setting
4) API TBApiSetSettingDWORD(passedDeviceNumber,_T("Enabled"),0); = Disabled or….. ,1); = Enabled
The driver can be prevented from passing any touches to the 'mouse interface' of the OS. This will stop mouse emulation from all devices configured in the driver, but will, for example, still allow applications to receive touch data via the API.
1) Command line interface passing parameters pointeron or pointeroff
2) API TBApiMousePortInterfaceEnable(true); or (False);
3) TBupdd.ini setting “InitialMousePortEnabled”
(false = ignores MousePortInterface setting at startup and starts up with port disabled)
With UPDD 4.1.10 we can supply a driver with InitialMousePortEnabled setting = false as default so that the touch is not functioning after installed and subsequent reboots. Pre 4.1.10 this setting needs to be set manually by one of the methods described above.
Pre UPDD 4.1.10 sound (during touch or calibration) was only supported in Windows 32 bit and only available via the system speaker. With UPDD 4.1.10 we have introduced support for sound file playback during touch and calibration.
We have implemented sound playback via a cross platform utility which utilises sound playback mechanisms relevant to the OS in use:
Sounds can be associated with touch and calibration events and are configured as follows:
Configured in the UPDD Console, Click Mode dialog, via the Sound option button:
Enter the name of the sound file to play or select the speaker icon to invoke Windows Explorer to located the sound file:
Configured in the UPDD Console, Calibration dialog, via the Sound option button
Some touch systems may be configured to run a dedicated touch application such that if the application fails then touch should be disabled to restrict access to the underlying system. This option has been implemented in UPDD 4.1.10, build 2235.
Configuring the security feature can be performed via a GUI interface or via settings in the UPDD settings file.
The GUI interface is invoked via the command “dcu /security” (dcu is the .exe name of the UPDD Console). This is currently Windows only but a minor change is required for this to work in other OS. Please contact us if required in non – Windows systems.
This will invoke the following security dialog:
If following settings, in the UPDD setting file, parameters branch, are used to implement the security feature:
Settings can be updated using the tbutils command line interface. To replicate the above settings using tbutils would be as follows:
Tbutils setting nodevice dw security.enabled 1
Tbutils setting nodevice dw security.visual 1
Tbutils setting nodevice dw security.number.programs 1
Tbutils setting nodevice sz security.program.0 C:\program files\updd\dcu.exe
Tbutils setting nodevice dw security.poll.secs 1
Tbutils setting nodevice dw security.block 0 – needed to create setting as this is for internal use only and value will be set as required.
The UPDD background task invokes the security checking if enabled. If enabled it reviews the list of processes looking for the process associated with the defined program(s). If any are missing from the process list, touches are flagged to be blocked by the driver to the UPDD API or system interfaces. If all the processes are found the touch mechanism is not blocked. The checking is continuous so if a missing process is restored the touches will automatically be unblocked so long as all defined processes are seen.
If a user touches the screen whilst the touches are blocked and the visual indicator is enabled the user sees the following dialog:
It was reported that this feature did not work on a Korean system. Further investigation showed that the program’s pathname was retaining some illegal characters
To overcome this issue please ensure the selected pathnames are in a folder that can be represented in ASCII file name, as per this example:
Starting with UPDD version 5.1.0; in addition to support for physical hardware such as USB and RS232 interfaces, virtual devices are now supported. Note that this refers to the virtualisation of the touch data input, not the interface to mice and pointer systems that is documented elsewhere.
This is useful, for example, where the API TBApiPostPacketBytes is to be used to support a device where the hardware is being controlled by other software. Similarly an application can be used to drive the system pointer without a physical device being used.
Data recorded with “tbutils record” can be played back to a virtual device in cases where the actual device is not available (although in most cases it is probably more useful to mark a PnP device as “virtualconnected”, see below).
To use a virtual device you will first need a driver with support for one or more virtual devices. Then use the add device option in the UPDD console or tbutils to add an instance of such a device.
A new device setting is used in conjunction with virtual devices. “virtualconnected” will by default have a value of 1 (meaning true).
The UPDD console will show a device as connected (in black text) in this case. A program can set this value to 0 (meaning false) to have the console show disconnected (red text).
Note this option is supported for all controller types but only a value of 1 has an effect, this forces the device into a connected state allowing tbutils playback for example for a disconnected device
UPDD software consists of a Windows cursor utility, tbcursor, that can be used to change the cursor scheme:
Simply select a cursor scheme from the defined set of four schemes.
Be careful if selecting blank as there is no visual feedback at point of touch.
Starting with version 5.1.656 UPDD supports tracking dynamically attached monitors and automatically adjusting the monitor desktop assignments. This feature is implemented as an extensible framework based around monitor characteristics. Currently the only characteristics supported are Monitor dimensions. Others can be added as the need arises.
This feature is used to automatically configure touch monitors in a system as they are connected and to remove them from the driver’s configuration as they are unplugged with out any user intervention.
This function is portable and supported on all platforms running daemon process Aidaemon.
Current support is for this feature is based on Monitor dimensions (video resolution). The feature also requires eeprom calibration support. With this enabled so long as monitors have different dimensions UPDD will detect insertions, position changes and removals of all monitors and configure itself accordingly.
The default settings for touch controllers must be set to “extended touch” OFF.
Default calibration data must be provided for supported controllers through one on the documented methods.
To use monitor dimension tracking a device must be precalibrated using the eeprom storage feature.
Settings used by this feature
Trackmonitors: this must be set to 1 to enable monitor tracking. This setting is not device specific.
Tbutils nodevice setting dw Trackmonitors 1
Trackmonitorsdwell: specifies a delay in seconds that must elapse after detection of a new monitor before the configuration takes place, this allows the system to “settle” avoiding multiple configuration calls in the event that the video layout changes multiple times.
Tbutils nodevice setting dw Trackmonitorsdwell 1
Eepromreadatnewmonitor: this is described in more detail in eeprom settings but should be set to 1 to track monitor dimensions. This setting is not device specific.
Tbutils nodevice setting dw eepromreadatnewdevice 1
eeprom calibration: this is described in more detail in eeprom settings but should be set to 1 to track monitor dimensions. This setting is device specific.
Tbutils device=N setting dw “eeprom calibration” 1
A system can have either a 800 x 600 and/or 1024 x 768 touch monitor connected such that they should be both correctly calibrated and associated with the correct desktop at the time the monitor is connected to the system. The daemon task will be notified when a new monitor is connected and will detect the video resolution. If it matches the video resolution associated with a touch device then the touch device is associated with the monitor with the detected resolution. Will currently only work if the monitor resolution is unique on the system.
For further information or technical assistance please email the technical support team at email@example.com