Elo touchscreen software version 2.00 for WinCe 6.0 Copyright 2008 Tyco Electronics / Elo TouchSystems Updated: 2008-10-08 CONTENTS This is revision 2.00 of the Elo touchscreen OS components for Windows CE6.0. It contains three DLL drivers, one DLL application library, two EXE support applications, and one CPL (control panel applet) plus project files to enable the components to be built into a system. Each component has an independent version number as well as being a part of the package revision (2.00). The previous release was 1.17. eloUsb.dll (1.50) is the USB driver. eloSer.dll (1.50) is the serial driver. eloApi.dll (1.50) provides application-driver interface functions. eloVa.exe (2.70) is the touchscreen video alignment program. eloTalk.exe (1.40) is a touchscreen configuration and diagnostic application. eloBeep.dll (1.10) is a tone generator for x86 systems only. eloCpl.cpl (1.00) is a control panel applet. EloVa.exe, eloTalk.exe, eloCpl.cpl and any other applications that communicate directly with the drivers require eloApi.dll to be included in the system image. For each component, the install package includes CPU-agnostic bib, cec, pbpxml, and reg files plus CPU-specific dll or exe, pdb, and rel (if dll) files. This release supports X86, ARMv4i, MipsII, and MipsIV. AddEloCat.bat adds the Elo touchscreen components to the CE Catalog database. RemEloCat.bat removes Elo components from the Catalog database. INSTALL Get installation files by invoking Elo200Ce60.exe, a self-extracting ZIP file, which copies all files to wince600\EloTouch unless you select an alternate destination. ADD COMPONENTS The components can be added to your target image in three way; two as user projects and one as platform components. The latter requires rebuilding the platform and is less flexible. It should be used only if you are building a platform for distribution. If your product is not a platform, it is easier and quicker to add the components as user projects. The quickest way to add the components is to insert them as existing projects, directly referencing their project (pbpxml) files. This is done for each component individually in Platform Builder by Project > Insert > Existing Project and pointing to the appropriate pbpxml file under wince600\eloTouch, for example wince600\eloTouch\eloUsb\eloUsb.pbpxml. All necessary output files will already exist under eloTouch and simply remaking the run time image adds the components to nk.bin. Similarly, a component can be removed by deleting it from the Workspace Files view and remaking the run time image. The components can also be added as user components in the Catalog. Instead of directly referencing them in the EloTouch directory, they are first added to the Catalog. From there they can be selected into any project. The only advantage that this affords is that it allows the components to be selected without having to know their origin (under EloTouch). The procedure is: 1. Set installation environment 1.1. Open your project in Platform Builder. 1.2. Open the project release directory (Build OS > Open Release Directory). 1.3. Change the directory to C:\Wince600\EloTouch (or alternate). 2. Invoke AddEloCat.bat to add Elo components to the Catalog. 3. Update the platform's Catalog 3.1. In Platform Builder, if the Catalog is not displayed, select View > Catalog. 3.2. Right-click in the Catalog window and select Refresh Catalog. This is very important. Platform Builder's Catalog does not automatically update. 3.3. In the Catalog window under Third Party > Device Drivers > Touch, you should see eloUsb, eloSer, eloApi, eloVa, eloTalk, and eloBeep. If you don't see these, the installation has failed. 4. Add components to OS/Project design. For each component that you want to add, right-click its icon in Platform Builder's Catalog window and select Add to OS Design. All components are independently selectable except eloVa and eloTalk, which should not be selected without EloApi. As each component is selected, its icon appears in the OS Design View under Device Drivers > Touch and a grayed project appears for it under Projects. Remaking the run time image adds the components to nk.bin. 5. Removing components. A touchscreen component can be removed from the OS design by right-clicking its icon in the OS Design View > Device Drivers and selecting Remove Item from User-specified Catalog Item(s). Both this icon and its project companion will disappear from the Design View window. The project cannot be directly managed. The components can be added to the Platform by following the Catalog procedure described above but then rebuilding the Platform instead of just remaking the run time image. This process cannot be easily reversed. Once the components have become part of the Platform, you can remove them by deleting them from your project and rebuilding the Platform but you cannot reintroduce them as user projects but only as Platform components unless all references to them are deleted from the Platform's pbxml file (by hand editing). After building the image (nk.bin) the inclusion of Elo components can be verified using Platform Builder's viewbin program. From the Build menu, select Open Release Directory. At the command prompt type viewbin -o nk.bin | findstr /i "elo". The components should also appear in the CE system's \windows directory. To verify this, open My Device\Windows on the CE system. Using View > Options, open the Folder Options dialog and uncheck "Hide protected operating system files" and "Hide file extensions". REG FILES Touchscreen reg files (eloUsb.reg, eloSer.reg, and elova.reg) must be merged into the OS image. Platform Builder automatically merges the reg files of included components. You can edit these files directly and remake the run-time image to change touchscreen operating parameters initialized by Registry entries. It is not necessary to fully understand the purpose and meaning of registry keys in order to properly prepare project reg files if the EloTalk program is included in the image (normally only during development, as EloTalk is too powerful for end users). After using EloTalk facilities to configure the CE system, EloTalk's "save registry" button in its system dialog produces the plain text file eloreg.txt in the windows directory. Using Platform Builder's remote file viewer tool, this file can be uploaded to the development system where portions of it can be pasted into reg files. FEATURES OF RELEASE 2.00 1. Fully defined application programming interface (API) including header files and run-time library, for system developers' programs to directly access the drivers. 2. Multiple touchscreens (as many as nine serial and 100 USB). 3. Screen rotation by configuration (registry) and at run-time without recalibration. 4. Touch lockout with touch hold unlock cleaning mode. 5. Registry viewer. 6. Quick global right-click-on-hold disable for selective disabling RCOH on touch-hold elements, such as scroll buttons. 7. EloVa improvements: touch-hold escape, touch-touch redo, more precise exit codes, calibration status record in registry, conditional calibration. 8. Control panel applet. CORRECTIONS 1. Cal parameter storage. Release 1.17 introduced a bug that could cause calibration parameters to not be written to the registry and/or controller (as determined by "CalStore" in the registry). 2. The serial driver was producing a debug message "Bad touchpacket checksum" and both USB and serial drivers were producing "Forcing untouch" even in the retail build. These messages were correct but should not appear in the retail build. 3. The serial driver could enter an endless loop trying to resynchronize after communication error. Symptoms ranged from communication failure to apparent system crash. 4. Forced untouch worked for both serial and USB to protect against communication or controller failure and it worked for serial disconnect but it did not work for USB disconnect. Now, if a USB touchmonitor is unplugged while touching, an untouch is immediately generated regardless of whether forced untouch is enabled. APPLICATION PROGRAMMING INTERFACE This is more completely described in the ELO WINCE API manual. The touchscreen drivers normally translate touch events to mouse events, which they send to the OS to pass on to applications. Applications can also communicate directly with the drivers through synchronous DeviceIoControl calls. The API comprises two parts, definitions shared by applications and drivers and application-level functions to simplify the task of communicating with drivers. The former are required. The latter are convenient but not essential. The shared files are: 1. eloCodes.h defines IOCTL codes, by which an application tells the driver the function to perform, and error codes returned by the driver. 2. eloIoctl.h defines data constants and structures associated with each IOCTL code. 3. eloRegNames.h defines registry names used by the drivers and, for some of these, ordinal values that are used in API communication. These are primarily used by one command, IOCTL_ELO_CFGITEM, which provides much of the functionality that would be of interest to an application. 4. smartSetCmd.h defines constants and structure required for communicating directly to a touchscreen controller via Elo's SmartSet protocol. The application-only files are: 1. eloApi.h defines classes, inline functions, and function prototypes advertising capabilities provided in the interface library eloApi.dll. 2. eloApi.dll instantiates interface functions declared in eloApi.h. To communicate directly with the driver an application must be built with eloCodes.h and eloIoctl.h. It requires eloRegNames.h only if it invokes the IOCTL_ELO_CFGITEM and a few obscure functions. It requires smartSetCmd.h only to talk directly to a touchscreen controller. While it is possible for an application to communicate with the driver without eloApi.dll, the library greatly simplifies this task. EloApi.h is required for this. MULTIPLE TOUCHSCREENS The USB and serial drivers support multiple touchscreens. Due to the limitations of Windows CE, the serial driver cannot support more than nine devices. The USB driver supports an essentially unlimited number. To support even one touchscreen, the USB driver requires the registry key [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\USB] to exist, although it may be empty. This is the "root" key. If the root doesn't contain the value "Multimon", all USB touchscreens attached to the system will share the root key. This is typically acceptable for configuration values. However, if calibration results are stored in the registry (e.g. "CalStore" = 22) and each touchscreen can be expected to require unique values (i.e. any but IR) then this scheme is unlikely to give acceptable results. If the USB root key contains the value "Multimon" assigned 0, the behavior is identical to "Multimon" not existing at all. The first USB touchscreen uses the root if "Multimon" is assigned 1 or the subkey "T1" if "Multimon" is assigned 2. In either case, subsequent touchscreens use "T2", "T3", etc. The driver will create these subkeys if they don't already exist in the registry. It also duplicates any values in the root that do not already exist in a subkey. Thus, it is not necessary to define subkeys or to know how many devices may eventually be attached, yet devices with unique registry requirements can be predefined, inheriting just a subset (or nothing) from the root. If a USB touchscreen with a unique registry key is disconnected, the key is unchanged and will be assigned to the next device attached to the system. Multiple touchscreens can be simultaneously disconnected but if they don't reattach in the original order of attachment (not disconnect order) some may be assigned a key intended for another. Similarly to the USB driver, the serial driver requires the root key [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\SER] to exist for even one touchscreen. Unlike USB, each additional serial device requires that a subkey ("T2", "T1", etc.) be predefined for it. This subkey must identify the com port. For example: [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\SER\T2] "ComPort"="COM3:" If the serial root doesn't contain "Multimon" or "Multimon" is assigned 0, the driver supports only the device defined in the root, which must contain at least the "ComPort" value. The first serial touchscreen uses the root key if "Multimon" is assigned 1, or "T1" if "Multimon" is assigned 2. The second serial device always uses "T2". SCREEN ROTATION The screen can be rotated to the 0, 90, 180, and 270 degree (counter-clockwise) orientation by a registry setting and/or dynamically through the IOCTL_ELO_ROTATE command. Recalibration is not required. Three-point calibration performed at any orientation produces results applicable to all other orientations. Edge calibration can be performed only at 0-degree orientation but is valid for all others. Calibration results are stored in the registry and/or controller (depending on each touchscreen's "CalStore" registry value) normalized to 0 orientation. Consequently, the stored parameters are compatible with older drivers that do not afford the flexibility of this new CE driver and a precalibrated touchscreen may be attached to a system in any orientation. By default, the driver initializes each touchscreen with its 0-degree parameters. If the driver's root key (HKLM\HARDWARE\DEVICEMAP\TOUCH\USB or SER) contains the value "Orient" assigned 1, 2, or 3, touchscreens are initialized to 90-, 180-, or 270-degree orientation. If bit 9 of the "Orient" data is set, the driver additionally rotates the video display by invoking the OS function ChangeDisplaySettingsEx. For CE5.0, this is more convenient than the alternative: [HKEY_LOCAL_MACHINE\System\GDI\Rotation] "Angle"=dword:5A ; 0=0, 5A=90, B4=180, 10E=270 For CE6.0, the "Orient" method is essential because of an error in its GWES code. When "Angle" is 0, subsequent interactive rotation works just as it does under CE5.0. However, when "Angle" is any other value, rotation by ChangeDisplaySettingsEx either splits the screen or produces a fault that freezes the system. In previous Elo CE releases, the registry value "SWAPXY" (or "XySwapped") required adjustment to match video rotation. It no longer serves in this capacity and should not be adjusted for any reason. It is now strictly a calibration parameter, indicating the relationship between the touchscreen and video panel, irrespective of video orientation. The IOCTL_ELO_ROTATE command can be invoked at any time to rotate the touchscreen. The one argument to this command performs identically to the "Orient" data. Values 0, 1, 2, and 3 select 90-, 180-, or 270-degree orientation and setting bit 9 requests the driver to rotate the display via ChangeDisplaySettingsEx. While it is possible to directly pass this command to the driver, it is more convenient to call one of the related EloApi functions. For example, to rotate the first or only screen to 270-degrees with the driver rotating both the touchscreen and display: EloApi::rotate( 0x103, 1 /*device number*/, _T("Elo1:" ) /*device name optional*/ ); More conveniently, especially if the system has multiple screens: EloApi::rotateAll( 0x103 ); or EloApi::rotateAll( ORIENTATION_90 + ROTATE_VIDEO ); TOUCH LOCKOUT The touch lockout facility is used to prevent inadvertent activation during cleaning or when the touchscreen is not in use. A touchscreen can be put into cleaning mode only by sending it an IOCTL_ELO_ON_TOUCH command with appropriate arguments. While in cleaning mode, the touchscreen does not respond to touches. However, it responds to touch-hold in the same manner as it would right-click-on-hold. While the touch is being held, an expanding reverse-video circle around the touch point informs the user that the touch is recognized. If the touch is held for the programmable hold event time, the indicator disappears and cleaning mode ends. To prevent inadvertent activation at this point, the touchscreen continues to ignore touch events until after the next untouch. All parameters of the unlocking means are controlled by the right-click-on-hold parameters. These can be set by registry values for each touchscreen. "TouchTick" is hold timer resolution. e.g. 0x64 = 100 msec per tick. "HoldJiggle" is the hold perimeter in absolute touch units. Movement inside this is ignored. "HoldEventTick" is the tick count to unlock. "HoldShowTick" is the tick count before showing hold visual feedback. 0 = immediate feedback. >= HoldEventTick = no feedback. "HoldShowStep" is hold visual feedback step size in video pixels. These parameters can also be set via the IOCTL_ELO_HOLD_PARMS command directly or through the EloApi::HoldParms send function. A touchscreen can be put into cleaning mode most easily by calling the EloApi function setCleaningMode e.g: EloApi:: setCleaningMode( 1 /*device number*/ ); There is no complementary function to to stop cleaning mode, as the user's touch-hold is expected to do this. REGISTRY VIEWER In the previous Elo CE release (1.17) the EloTalk program provided a registry capture (to file) facility to simplify transferring experimentally determined settings from a system under development to the design source. A registry viewer has been added to display the same information in order to show immediately the effect of changes and as an alternate means of capturing the information (by hand) when the system is not attached to a development host. The display, like the file, is arranged and formatted similarly to a reg source file (e.g. eloUsb.reg) but is derived entirely from the current registry contents. RIGHT-CLICK-ON-HOLD GLOBAL DISABLE When RCOH is enabled for a touchscreen, touch-hold causes an expanding reverse-video circle to appear around the touch point and, after a delay, a right-click mouse event to be generated. Properly configuring "HoldShowTick" and "HoldEventTick" for the type of application prevents annoying false triggering of these events on normal touches. However, if the user interface contains controls that are normally pressed and held, such as scroll buttons, the RCOH mechanism is activated. The driver cannot avoid this because only the application knows when such a control is being touched. An application can detect when a control that should not experience RCOH is being touched and could disable the touchscreen's RCOH mechanism until the control is untouched. The application could use the IOCTL_ELO_ON_HOLD command or EloApi:: setOnHold function for this purpose but there are several problems with this approach. One is that the application would have to record the existing configuration in order to restore it. Another is that it is difficult to cover all possible code paths that might interfere with recognizing that RCOH should be restored, leaving it inappropriately disabled. Further, if the system contains multiple touchscreens, RCOH would have to be disabled and reenabled for each one individually. The EloApi::disableHold, disableHoldTemp, and allowHold functions afford an easier and more reliable means of temporarily disabling RCOH for all touchscreens. e.g: EloApi::disableHold( 1 /*device number*/, _T("Elo1:" ) /*device name optional*/ ); EloApi::disableHoldTemp( 1, _T("Elo1:" ) ); EloApi::allowHold( 1, _T("Elo1:" )); These functions require a device number (providing the optional device name accelerates execution) in order to access the driver but the effect occurs on all touchscreens attached to the driver (USB and serial are separate). After disableHold executes, RCOH is disabled until allowHold executes. With disableHoldTemp, RCOH is disabled until the next untouch. An application calls disableHold to temporarily disable RCOH for a group of controls or an entire dialog. It calls disableHoldTemp to disable RCOH when a particular control is touched. ELOVA IMPROVEMENTS Touch-hold Abort If the CE system includes a keyboard, the calibration process can be aborted at any time by pressing the Esc key. Otherwise, it has been necessary to wait for timeout to abort. Another means of aborting has been added. Touch-hold at any position on the screen produces the same response as pressing the Esc key. An expanding reverse video circle accompanies this gesture. Unlike right-click- on-hold, the gesture's timing parameters are fixed: tick resolution is 100 ms; feedback begins at 600 ms; event occurs at 1.7 seconds. Touch-touch Redo Calibration can be repeated by pressing the redo button in the acceptance dialog. However, the most common reason for repeating is a user error, such as pressing the same target twice, that causes the cursor to not follow touch, making it difficult to touch the button. Now, when this dialog is displayed, double touching anywhere on the screen is interpreted as redo command. Return codes In previous releases, Elova's return code was 0 to indicate "success" or one of several positive values indicating various types of failure. There was no indication of whether calibration was completed. The return code range has been expanded to: 0 = Everything possible was done and accepted. Every touchscreen received three- point calibration. Edge calibration was done on every touchscreen with non-zero EdgeCalCfg registry value. 1 = Three-point calibration done and accepted on all touchscreens but one or more possible edge calibrations was skipped. This should be considered success, in most cases, because edge calibration may be performed less often than three-point. 2 = Three-point calibration was not done or not accepted on one or more touchscreens. 3 = A previous instance of elova is already executing (immediately aborts). 4 = No touchscreen device is connected. 5 = Unable to allocate sufficient memory. 6 = System failure. Cal Status With multiple touchscreens, even elova's expanded range of exit codes may be insufficient. In any case, the exit code itself does not afford a persistent record of calibration status. Elova now writes the calibration status of each touchscreen to the "Cal" (dword) value under that device's registry key. Nothing is written if the touchscreen is skipped, allowing previous calibration status to remain in the registry. If the touchscreen is completely calibrated, that is three-point and edge if indicated by its EdgeCalCfg value, "Cal" is assigned 2. If the touchscreen receives three-point calibration but its edge calibration is skipped, "Cal" is assigned 1. Elova's default behavior is to not flush the touchscreen's registry key after writing "Cal". If persistence is required and it requires RegFlushKey to be called after writing, Elova can be configured to do this by setting bit 9 of the "Cal" value under elova's registry key, [HKLM\HARDWARE\DEVICEMAP\TOUCH\ELOVA]. For example "Cal" = dword:100 Elova's default behavior is to not write the "Cal" registry value of touchscreens that the user chooses to not calibrate (elova is terminated by timeout or prematurely by ESC or touch-hold). Setting bit 10 of elova's "Cal" registry value configures elova to always write this value. Thus, if the user skips a touchscreen that is already calibrated, its "Cal" value will be changed to 0, indicating that it is not calibrated. For example: "Cal" = dword:200. Elova's write and flush Cal behavior can also be set by the command line argument cal, which has precedence over the registry Cal (which has precedence over the defaults). The cal argument is cal=word, where word is some combination of 'w' and 'f', with optional '-' prefix, and a digit, which serves a purpose in conditional execution. 'w' tells elova to write Cal for every touchscreen. "-w" forces elova back to its default behavior, overriding elova registry "Cal" bit 10. 'f' tells elova to flush the touchscreen's registry key after writing. "-f" forces elova back to its default, overriding elova registry "Cal" bit 9. The word is both order- and case-insensitive and any component may be omitted. For example: "elova cal=-W-F2" and "elova cal=2-f-w" are equivalent. "elova cal=f" and "elova cal=F" are equivalent. Conditional Calibration When the user explicitly invokes elova, it closes automatically only when all touchscreens have been calibrated or at timeout. Elova may also be invoked automatically under circumstances in which the user experience would be better if the program were to close immediately if all touchscreens were already calibrated. For example, when the CE system boots, elova may be invoked automatically to ensure that touchscreens are calibrated. If the system has no mouse or keyboard or precalibrated touchscreen, this is the only means of establishing effective user input. However, after the user has calibrated all touchscreens, it may be annoying for elova to appear at every reboot. By default, elova always tries to calibrate all touchscreens. The LSbyte of elova's "Cal" registry value can be assigned the level of calibration that is required of all touchscreens. If the "Cal" status of all touchscreens is above this level, elova exits immediately before displaying anything. If elova's "Cal" level is 2, it unconditionally tries to calibrate all touchscreens. If elova's level is 1, it exits if all touchscreens are fully calibrated ("Cal" level 2). If elova's level is 0, it exits if all touchscreens are at least partially calibrated (three-point but not necessarily edge). The optional digit in the cal command line argument to elova overrides elova's "Cal" value level. All touchscreens require three-point calibration. Only selected ones (by their registry value "EdgeCalCfg") have edge calibration. If elova is invoked automatically when the system boots and the user calibrates all touchscreens to the required level, at all subsequent reboots, the user will see no evidence of elova. If the user quits elova before calibrating all touchscreens, elova will continue to display itself at every reboot until the user calibrates the remaining units. Conditional calibration requires registry persistence. If persistence requires flushing, setting elova's "Cal" bit 9 is the preferred configuration means and elova is never invoked with the cal=f or cal=-f argument. The other potential elements of the "Cal" value exist for specialized applications and are typically unused. Consequently, elova's "Cal" value is typically undefined if flushing is not required or assigned 102 (hex) if flushing is required. Elova is invoked at boot with the argument "cal=0" so that it will try to calibrate all touchscreens unless they all have been at least three-point calibrated. At any other time, elova is invoked without arguments. To launch elova automatically at startup, alternative project files are used. elova.bib MODULES eloVa.exe $(_WINCEROOT)\EloTouch\EloVa\$(_TGTCPU)\eloVa.exe NK FILES elovaBoot.lnk $(_WINCEROOT)\EloTouch\EloVa\elovaBoot.lnk NK elova.dat Directory("\Windows\Startup"):-File("elovaBoot.lnk", "\windows\elovaBoot.lnk") elova.pbpxml Directory("\Windows\Startup"):-File("elovaBoot.lnk", "\windows\elovaBoot.lnk") elova.pbpxml elovaBoot.lnk: (copy this to release directory) 24#\windows\elova.exe cal=0 CONTROL PANEL APPLET EloCpl.cpl is a control panel applet supporting the relatively common touchscreen user operations calibrate, clean, and rotate. If EloTalk is included in the image, the applet dialog also contains a button to invoke it. The applet requires eloApi.dll to be included in the image. The applet functions operate on all touchscreens in a multi-monitor system. Calibrate invokes eloVa, which inherently applies to all touchscreens. Clean locks all touchscreens for cleaning. Touch-hold on any screen unlocks all of them. The rotate buttons-- 0, 90, 180, and 270-- rotate the video display and all touchscreens. ================================================================================ RELEASE 1.17 NOTES (EXCERPTS) ================================================================================ FEATURES OF RELEASE 1.17 1. Edge and corner acceleration for improved finger access especially to small icon buttons at the top and bottom of the screen. 2. Linearity correction for improved touch accuracy with resistive touchscreens. 3. Registry image capture in EloTalk to simplify creating the OEM Registry image. 4. Selectable automatic persistent Registry key flush when calibration data is saved. 5. Corrects crash on touch hold selection in EloTalk's Touch dialog when not previously enabled in the Registry. Would not have affected end users. 6. Corrects confusion regarding purpose of "HoldJiggle" Registry key value. 7. Replaces essentially duplicate Registry key values "TrackingCursor" and "Enable" with a single "OnTouch" value. 8. Moves Elova timeout Registry values from under the serial and USB drivers to a separate key [HKLM \HARDWARE\DEVICEMAP\TOUCH\ELOVA]. 9. Implements a more consistent Registry key value naming convention. ACCELERATION AND LINEARITY CORRECTION This is an abbreviated description. A more complete description is provided in the EloTalk User Guide. Finger access to positions near the edges of a touchscreen, for example to activate standard window close and tooltray icon buttons, can be inconvenient because the cursor normally tracks the center of touch and the bezel blocks the required finger movement. This problem may be aggravated by non-linearities in a resistive touchscreen, which may be more severe near the edges. The problem can be reduced or eliminated by acceleration and/or linear correction. The touchscreen driver (eloSer.dll or eloUsb.dll) produces "edge acceleration" by reporting mouse positions that shift toward a screen edge as the touchpoint moves toward that edge. Edge acceleration distorts the video-touchscreen relationship and can even cause some positions away from the edge to become inaccessible. Consequently, acceleration should be as little as necessary to afford edge access. Non-linearities in the touchscreen exacerbate this tradeoff because a response trough near an edge requires additional acceleration while a peak further from the edge requires less than average. Therefore, correcting non-linearity, especially near edges, improves acceleration. In some applications unaccelerated edge access is acceptable except in the corners of the screen. For these, accelerating just the corners avoids the broader distortion of accelerating entire edges. Corner acceleration simply defines an area within which any touch position is translated to a specified screen position. The touchscreen drivers support all three means of improving edge access-- linearity correction, edge acceleration, and corner acceleration. Each edge may independently receive simple edge acceleration or linearity correction, which includes its own form of edge acceleration. Each corner can be accelerated independently of the treatment of edges or other corners. Simple acceleration and linearity correction can't be combined on one edge and corner acceleration is not usually of any value with linearity correction. However, corner acceleration combined with edge acceleration may allow the edge acceleration rate to be reduced. All acceleration and linearity correction data are stored in the Registry, even if three-point calibration data are stored in the touchscreen. Edge and corner acceleration parameters can be determined once for a product and stored in the OEM Registry image. Linearity correction data is produced by performing an edge calibration, which may have to be repeated in the field. Without Registry persistence, edge calibration may have to be repeated every time the product is turned on. Elova provides both standard three-point and edge calibration. When invoked, Elova always presents the three-point calibration and then displays a dialog for the user to accept or repeat the calibration, to quit, or to perform edge calibration. Edge calibration data is used only for linearity correction, which the driver performs before touch-to-mouse translation. Consequently, it is insensitive to changes in the touchscreen-video relationship and does not need to be adjusted as often as the three-point calibration data. For three-point calibration, Elova presents three points in succession, expecting the user to touch each one exactly. For edge calibration, the user slides their finger along an edge using the bezel for a guide. A series of dots is presented along the edge to tell the user approximately where to touch. Dots disappear as the user touches near them. Remaining dots indicate areas that do not yet have sufficient data, due either to the user skipping them or extreme linearity distortion. Corner dots may remain due to access restrictions of the bezel. The user should be instructed to simply keep pressing the remaining dots in the way the touchscreen is normally used. Elova recognizes when the user is trying repeatedly to touch the same dot, even if not very close to it, and continually expands the range that it will accept so that all dots will eventually be gone. Elova presents for calibration only the edges configured for linearity correction. For example, if linearity correction is enabled only for the top, when the user selects edge calibration Elova displays the dots on the top edge and redisplays the accept dialog as soon as the user finishes that edge. If no edges are configured for linearity correction, the edge calibration button is disabled. The Registry key value "EdgeCalCfg" under the driver key tells Elova which edges to calibrate. Bits 0 through 3 correspond to left, top, right, and bottom; 1 enables calibration of that edge. CALIBRATION TEST AND CONFIGURATION Except for calibrating edges that have already been selected, the end user has no options regarding acceleration and linearity correction. Configuration information resides in the OEM Registry image. Although the system developer could, for the most part, configure the system just by editing the reg files that are incorporated into the image, it could be difficult to predict the optimum configuration. EloTalk's calibration dialog (calib tabbed dialog) allows interactive configuration, parameter adjustment, and testing of all options. The main calib dialog provides checkboxes for selecting edges for calibration. These set or clear the appropriate bits of the Registry value "EdgeCalCfg", which directs Elova. Also provided are radio buttons to select the source (Registry, touchscreen, or none) of three-point calibration data when the system boots and checkboxes for writing the calibration data to Registry and/or touchscreen. The "flush registry calibration writes" checkbox tells whether to flush the Registry (by calling the system function RegFlushKey) whenever calibration data is written to the Registry. This always applies to edge calibration and to three-point if writing to the Registry is selected. For reference, the calib dialog shows the values of "EdgeCalCfg" and "CalStore" in response to edge calibration and calibration storage configuration selection changes. The calib dialog also contains a "calibrate" button to invoke Elova and a "test" button to invoke the calibration configuration and test facility. The calibration test facility comprises a test window, which occupies the entire screen, and a configuration dialog, which can be moved around over the test window. The test window contains a grid to assist visualizing the effect of a particular configuration especially when the show trails checkbox is checked. Briefly, the dialog's controls act as follows. 1. Trails 1.1. show. When check leaves a trail, in the selected color, behind touches. 1.2. clear. Erases touch trails. 1.3. color. Selects the trail color. Clicking this cycles through the range of colors. 2. Test Pad Size 2.1. Up/down numeric tells the pixel resolution of the grid. 4 is the smallest grid resolution. Selecting 3 changes the test window to a plain gray and touches to the equivalent of a pen. 2.2. min selects the smallest grid resolution (4) 2.3. icon selects a grid resolution matching the size of standard window title bar buttons (at the current video resolution). 3. Edge Acceleration 3.1. left, top, right, bottom checkboxes enable standard edge acceleration for edges that have not be configured for linearity correction. When linearity correction is selected for an edge, the corresponding checkbox is checked but disabled, indicating that acceleration is always part of linearity correction. 3.2. Rate up/down controls set the acceleration rate for each edge. These are active for both standard edge acceleration and linearity correction but the ranges are different. For standard edge acceleration the value does not directly correspond to an obvious physical quantity but arbitrarily ranges from 2 to 100. For the acceleration component of linearity correction, the rate corresponds to an offset, in touchscreen points, determined during edge calibration. The rate can only be reduced from this experimentally determined value. 3.3. Border up/down controls set the edge acceleration border. Only touchpoints outside this border are accelerated. The border currently does not work with linearity correction, for which acceleration increases continuously from the center of the screen to the edges. 3.4. show border checkbox causes the edge acceleration border to be show. 3.5. <> unlabeled buttons uniformly reduce or increase the size of the acceleration border. 3.6. min and max set the border to its minimum (which may cause it to be hidden under the floating dialog) or maximum recommended size. The border may be explicitly made smaller or larger than these recommended limits. 4. Linearity Correction 4.1. left, top, right, bottom checkboxes enable each edge to be independently selected for linearity correction. 4.2. all and none select linearity correction for all edges at once. 5. Corner Acceleration 5.1. Each of the four up/down controls sets the width and height of the "capture" area around the corresponding corner. A touch in this area produces a mouse event at the screen position specified by the Edge Target. 5.2. on checkbox turns all corner acceleration on or off at once. 6. Edge Target. This up/down control sets the ideal position of a mouse event near an edge or corner in terms of touchscreen points offset from the edge ( or edges in a corner). It is shared by edge calibration and corner acceleration and, although the two use it differently, it has the same meaning for both. During edge calibration, Elova uses it to determine the ideal position of touches relative to the edge and, by inference, the edge acceleration irrespective of linearity correction. For corner acceleration, the driver generates a mouse event at this offset from the corner for all touches in the "capture" area. The default is half the width of a small icon. A value of 0 causes linearity correction and corner acceleration to accelerate touches to the furthest edges of the screen. REGISTRY CAPTURE Elotalk affords rapid configuration and testing of all aspects of touchscreen operation but the resulting Registry values are not automatically transferred to the reg source files used to make the OS image. Elotalk's System dialog (system tabbed dialog) "save registry" button causes all touchscreen Registry values to be written to the file \windows\eloreg.txt in the target system. The information is formatted for pasting directly into the reg source files. If the target is connected (serial or Ethernet) to the development computer, Platform Builder can upload the file using Tools > Remote File Viewer > Import File (toolbar button). In a typical development scenario, the target is initially brought up using the eloUsb.reg, eloSer.reg, and elova.reg files provided in the release package. Elova and Elotalk are then used to tune the touchscreen to the application. The configuration is captured by "save registry" and the appropriate sections of eloreg.txt can then be copied and pasted into the source reg files. It is not necessary to fully understand the meaning of the values. Calibration data is especially incomprehensible but still valuable, affording the product touchscreen operation before the first field calibration. In most cases, a good three-point and edge calibration on a first article (following GMP) yields an acceptable OEM Registry image for all similar units. CORRECTIONS 1. Touch hold selection (Right-Click-On-Hold or cable-disconnect forced untouch) crash. If eloSer.reg or eloUsb.reg enables right-click-on-hold or forced untouch then these functions could be enabled and disabled dynamically (through EloTalk). However, if neither was enabled in the Registry when the system booted and was subsequently enabled, the driver (serial or USB) would crash. This has been corrected. It is now possible to enable and disable these functions from EloTalk's Touch dialog regardless of their initial state. 2. HoldJiggle was being treated as an RCOH parameter by implication in eloSer. reg, eloUsb.reg, and by association and program in the EloTalk Touch dialog. Its appearance and function have been moved to apply to both RCOH and forced untouch. 3. Registry keys "TrackingCursor" and "Enable" have been replaced by "OnTouch". The old eloSer.reg and eloUsb.reg files contained TrackingCursor = 1 but not Enable, which defaulted to 1. "OnTouch" is a bit-mapped DWORD telling the driver what to do with touches. 0 means to discard them, essentially disabling the touchscreen. 1 means to process them normally, submitting them to the system as mouse events. Higher bits select special handling modes for retrieving touches directly through the driver's API. 4. In previous releases, the three timeouts for elova were determined by the "VaTime1", "VaTime2", and "VaTime3" values under the driver key. These have been moved to "Time1", "Time2", and "Time3" under the elova key [HKLM \HARDWARE \DEVICEMAP\TOUCH\ELOVA] reflecting the fact that Elova uses the same timeout values for all touchscreens. The new value "EdgeCalCfg" remains under the touchscreen key because each touchscreen may require a unique selection of edges for calibration. 5. A consistent Registry key value naming convention has been adopted. Generally, values likely to be edited by hand, either because they represent configuration options or self-evident parameters, use "camel" naming, for example "EdgeCalCfg". Values that are unlikely to be edited by hand use uppercase names, for example "SWAPXY". Some of these, such as edge calibration values "EC0" and "EP62", are generated by programs and have no discernable meaning. Others, such as "SWAPXY", have evident meaning but are, nevertheless, expected to be generated by programs and not normally edited. The old names "ScrDx", "ScrDx", "OffsetX", "ScrDy", "Dy", "OffsetY", and "XySwapped" have been replaced by "VIDX", "TSDX", "OFFX", "VIDY", "TSDY", "OFFY", and "SWAPXY". ================================================================================ RELEASE 1.16 NOTES (EXCERPTS) ================================================================================ FEATURES OF RELEASE 1.16 1. Removes EloVa and EloTalk dependency on SIM. 2. Removes debug messages, except by Debug Zone request. 3. Corrects serial touchscreen missing untouch on fast touch. 4. Corrects EloVa timeout truncation after calibration reject. 5. Corrects data alignment fault on MIPS. 6. Corrects rotated screen calibration error. 7. Adds Beep (x86 only) and WAV (all CPUs) on touch. CORRECTIONS 1. Version 1.15 improved the operation of EloVa and EloTalk in systems that include the SIP on-screen keyboard (User Interface > Software Input Panel) by forcing the input panel to disappear immediately instead of lingering over the application. However, the improvement incorrectly required the SIP module to be present for EloVa and EloTalk to execute at all. The SIP module requirement has been eliminated but, if it is present, EloVa and EloTalk still force the panel to immediately disappear. 2. In previous versions, the drivers produced a number of debug messages that, depending on target configuration, might appear at a COM port, possibly interfering with a device attached to the port. Routine debug messages have been eliminated from the release build. Catastrophic errors and messages enabled by explicit Debug Zone settings are still reported. 3. Beginning with version 1.15, the serial driver is more responsive than its predecessors and is able to detect very short touch events, exposing a flaw in the anti-bounce mechanism controlled by the Registry key DragDelay (under HKEY_LOCAL_MACHINE\ HARDWARE\ DEVICEMAP\ TOUCH). A value of DragDelay other than 0 supposedly tells the number of milliseconds of untouch that will be ignored in order to prevent false untouches. However, the driver imposed an additional 60 millisecond delay. The driver was previously not able to detect an event this fast. The new driver can detect such an event, causing the untouch to be discarded due to the minimum drag delay. This has been corrected by eliminating the minimum drag delay built into the driver. Previous DragDelay values for a particular application may have to be increased with the new driver to avoid unwanted untouches. 4. In the 1.15 release of EloVa, upon repeat (reject calibration) the intra- touch and acceptance timeouts would become significantly shorter. This has been corrected. 5. The MIPS (II and IV) USB driver had a data alignment fault that prevented it from working. Also, if configured to write calibration data to NVRAM in the touchscreen controller (by e.g. Registry "CalStore" = dword:31) EloVa would experience a data alignment fault. These have been corrected. 6. Previously, the touchscreen could not be aligned with 90 and 270 degree video rotations. This has been corrected. VIDEO ROTATION The video display can rotated by the Registry key: [HKEY_LOCAL_MACHINE\System\GDI\Rotation] "Angle"=dword:5A ; 0=0, 5A=90, B4=180, 10E=270. match XySwapped=0/1/0/1 It can also be rotated interactively by an application calling the OS function ChangeDisplaySettingsEx. In either case, the touchscreen driver requires the rotation to be matched by the Registry key "XySwapped" under [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH] for serial and [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\USB] for USB. "XySwapped" = dword:1 ; 0 (default) = not swapped For rotations of 0 and 180, XySwapped should be assigned 0. For 90 and 270 it should be assigned 1. The touchscreen must be recalibrated when the rotation changes. For interactive rotation, an application should set XySwapped appropriately and then invoke EloVa. CE5.0 and CE6.0 both support video rotation to 0, 90, 180, or 270 degrees. An error in CE5.0 may leave video fragments on the display as a mouse or touch moves across the screen. These are not caused by the touchscreen driver. Under CE6.0, if the display is rotated to any angle other than 0 via the Registry, it may not be interactively rotated due to an error in ChangeDisplaySettingsEx. This error does not exist in CE5.0. TOUCH SOUND Sound can be associated independently with each of four touch events, touch down, touch up, right click, and drag. Drag can only be associated with the beeper, while the other three can be associated with either beeper or a wav file. Wav files play only if the system contains a sound facility that responds to CE's PlaySound function. Beeper sounds require a beeper facility that closely approximates the PC standard beep I/O interface and the EloBeep driver runs only on x86 systems. All beep sounds are characterized by duration and tone. Drag sound duration is always infinite until untouch and, therefore, doesn't need to be specified. Tone is the period rather than frequency of the sound. It is the actual value programmed into the tone generator, which imitates an Intel 8254 PIT channel in square wave mode. CE does not include any component for controlling standard beep hardware. This is provided by EloBeep.dll. For the three non-drag events, the sound parameters are: 1. Sound type = None, Beep, or Wav 2. If sound type is Beep then: 2.1. Duration in milliseconds from 11 to 65,535 (i.e. maximum 65 seconds) 2.2. Tone from 11 to 65,535 in units that depend on the PIT-like hardware. Typically, the frequency range that this affords is about 18Hz to 100KHz. The usable tone range is typically 100 (highest audible frequency) to 5000 (lowest). 3. If sound is Wav then the full name and path to a wave file is given as a string, for example "\windows\startup.wav". The drag sound parameters are: 1. Starting tone (period). The frequency increases (tone value decreases) as the touch point drags away from the starting position, so this value is normally set relatively high (low frequency) for example at or above 2000. 2. Limit tone (period) specifies the lowest tone value (highest frequency) that the driver will go to while dragging regardless of the Step and Post parameters. 3. Step defines how rapidly the tone changes relative to drag distance from the touch down point. Smaller values cause the tone to change more slowly. The exact numeric effect of step varies with touch screen and video resolution but the usable values normally range from 10 to 500, with 100 typically providing a good response. 4. Post defines how far the drag must move (in touch grid points) before the tone changes, including the initial onset of drag sound. For example, if post is 20 the sound does not begin until the drag point moves at least 20 grid points from the touch down point and the sound changes only at each additional move of 20 grid points or more. REGISTRY All sound parameters for USB or serial are stored under the key: [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\SOUND] This can be defined in any of the reg files, EloUsb.reg, EloSer.reg, or EloBeep.reg. However, if the beeper is not used (including for all CPUs other than x86) EloBeep.reg will not be included in the image and one of the driver reg files must be used to define the touch-WAV associations. For example: [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\SOUND] ; Each of three events, down (touch), up (untouch), and right (click) can have ; no sound (default), beep ("Down|Up|RightBeep"), or wav file ("Down|Up|RightWav"). ; Beep value is dword with HIWORD=duration, LOWORD=tone, e.g. ; "DownBeep" = dword:00640BBA ; HIWORD=duration, LOWORD=tone, e.g. 00640BBA duration=100(d), tone=3000(d) ; Wav value is full path (with \\ for each \) to wav file name, e.g. ; "UpWav" = "\\windows\\startup.wav" "DownBeep" = dword:00640BBA ;duration=100(d), tone=3000(d) "UpBeep" = dword:0064046A ;duration=100(d), tone=1130(d) "RightWav" = "\\windows\\startup.wav" ; Drag sound is defined by: ; "DragTone" combines starting tone in HIWORD and limit (lowest tone = highest frequency) in LOWORD ; "DragStepPost" combines step in HIWORD and post in LOWORD. "DragTone" = dword:07D00190 ; start = 2000(d), limit = 400(d) "DragStepPost" = dword:00640014 ; step = 100(d), post = 20(d) With these parameters, a low frequency beep is generated on down touch, a high frequency beep on up touch (untouch), and the wave file "startup.wav" is played at right click (right click on hold). Additionally, dragging produces a beep tone that starts at a low frequency, which increase at a moderate rate up to a relatively high frequency as the drag point moves across a 15" monitor diagonal. This configuration serves to demonstrate the variety of sound capabilities. None of the sound associations are fixed or required. ================================================================================ RELEASE 1.15 NOTES (EXCERPTS) ================================================================================ PREVIOUS USERS EloUsb.dll replaces EloHid.dll. EloSer.dll replaces EloTch.dll and EloStub.dll. If you have been using the USB driver, you must remove eloHid from your platform design and replace it with eloUsb. If you have been using the serial driver, you must remove eloTch and eloStub from your platform design and replace them with eloSer. EloUsb.reg is derived from the old eloHid.reg. EloSer.reg is derived from the old eloTch.reg merged with eloStub.reg. New Registry keys have been defined to support new capabilities, including eloVa timeouts, right-click-on-hold, and controller-based (NvRam) calibration store. EloUsb.reg identifies the USB driver, eloUsb.dll, as both a USB and a HID device. Previously, it was only a HID device. FEATURES OF RELEASE 1.15 1. EloVa timeouts controlled by Registry keys. 2. Calibration data storage and automatic retrieval to/from the controller's NvRam. 3. Right-click-on-hold. 4. EloTalk touchscreen configuration tool. 5. Two-part serial driver eloStub.dll and eloTch.dll replaced by a single driver, eloSer.dll. 6. The USB driver, eloHid, is replaced by eloUsb. 7. SmartSet communication. ELOVA TIMEOUTS The video/touchscreen alignment and calibration application, eloVa.exe, presents a sequence of touch targets. After the user touches each of these, the program presents two buttons for the user to accept or reject the results. The program waits for user input at three distinct phases. When it is first invoked, it displays the first target and waits for the user's touch. After each touch, the program displays the next target and waits for another touch. The initial touch wait and subsequent touch waits represents two distinct phases with potentially very different requirements. Often eloVa is invoked automatically at startup, and the delay before the first touch may be quite long. However, once the user has begun responding to eloVa, the delay should be rather short. The third timing phase occurs while waiting for the user to press one of the accept/reject buttons. If the process has gone well, the user should respond quickly. If alignment is very bad, for example due to random touches, the user may not be able to activate one of these buttons at all. Previously, eloVa used fixed delays for each of the three phases. Now, the delay for each phase can be determined by Registry settings. One set of parameters is shared by all touchscreens in the system. The keys are "VaTime1", "VaTime2", and "VaTime3", setting, respectively, the first touch, intra-touch, and accept/reject delays. These are stored in the Registry under [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH] Each value is a hexadecimal dword in seconds. A value greater than 0xFFFF is interpreted as infinite, which should only be used, if at all, for the initial touch delay. The default values are 0x14, 0x10, and 0x14, for an initial delay of 20 (decimal) seconds, intra-touch delay of 10 seconds, and accept/reject delay of 20 seconds. [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH] ;--- ELOVA TIMEOUTS --------------------------------------------------------- ; For all EloVa timeouts, values > FFFFh mean infinite. "VaTime1" = dword: 14 ; Initial timeout. Default 20d (14h) seconds. "VaTime2" = dword:0A ; Timeout between target touches. Default 10d (0Ah) seconds. "VaTime3" = dword:14 ; Timeout to accept or reject. Default 20d (14h) seconds. CALIBRATION DATA STORE The touchscreen drivers convert raw touch events into system pointer device messages using calibration information stored in either the Registry or the touchscreen controller. This information can be pre-stored in the production process and/or as a result of executing an alignment program, such as eloVa. One advantage of storing calibration data in the controller is that the data remains with the device. Thus, a touch monitor can be calibrated in one system and moved to another simply by attaching the touch monitor to the other system. More significantly, using the controller's non-volatile memory to store the data enables persistent recalibration in a system that doesn't have a persistent Registry, as is often the case in CE-based systems. The Registry image in ROM/flash is copied into RAM and any changes in the RAM-based Registry are lost when the system is turned off. If the touch monitor doesn't require field recalibration then static calibration data in the Registry image is sufficient. Otherwise, the monitor must be recalibrated whenever the system is turned on, or the Registry must be persistent, or the data can be stored in the controller. Not all controllers support calibration data storage. The controllers that do provide this are 2216, 2500, 2700, 2701, 4500, 4501, and 5000. Controllers that afford both serial and USB interfaces support this identically on either interface but some, such as 4500, require different calibration data for serial vs. USB. These must be calibrated through the same interface through which they are used (the system need not be the same, however). The calibration data store is independently defined for each touch monitor in the system by its Registry key "CalStore", which is a bit-mapped dword. Only the lowest byte is used. The low nibble determines the source that the driver reads when a touch device is attached (or at system startup). The high nibble determines the destination that eloVa writes when the user accepts a calibration. In both cases, bit 0 indicates controller and bit 1 indicates Registry. Thus, the value 1 indicates controller, 2 indicates Registry, and 3 indicates both. For example 0x31, tells the driver to load calibration data from the controller's NvRam and EloVa.exe to write it to both the controller and Registry. Writing to the Registry affords a convenient means of remotely viewing the parameters (with Remote Registry Editor on the host computer). If the target's Registry uses flash memory for persistence, it would be best to turn off this feature to reduce wearout by setting CalStore equal to 0x11. If the source nibble is 3, calibration data from the controller will be used. If CalStore is not defined, the Registry is used for both source and destination. In eloUsb.reg: [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\USB] "CalStore" = dword:31 ; low nibble = src, high = dest. 1 = controller, 2 = Registry, 3 = both. In eloSer.reg: [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH] "CalStore" = dword:31 ; low nibble = src, high = dest. 1 = controller, 2 = Registry, 3 = both. RIGHT CLICK ON HOLD The drivers can simulate a right mouse button click by the user pressing in one place for a specified length of time. This time and other parameters controlling this feature are established by Registry keys individually for each touch monitor in the system. These are located under: [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\USB] for eloUsb and under: [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH] for eloSer. The timing for right-click on hold, cable disconnect untouch, and other functions related to touch is provided by one timer (per touch monitor) whose period is defined (in milliseconds) by the Registry key "TouchTick". If this key is not defined, all touch timer functions are disabled, regardless of whether related keys are defined. The value of TouchTick is normally 0x64, providing 100 msec resolution. Higher resolution (smaller period) may be defined but will consume more CPU bandwidth. Bandwidth consumption can be reduced at the expense of resolution by defining a larger period. The Registry key "HoldEventTick" defines the number of TouchTick counts to trigger a right-click. For example, if this is 8 and TouchTick is 0x64, the resulting hold time requirement is 800 msec. If HoldEventTick is 0, the function is disabled. The Registry key "HoldShowTick" defines the number of TouchTick counts to trigger visual feedback reminding the user that continued holding will result in a right click. If HoldShowTick is 0, feedback begins immediately upon touch. Any value larger than HoldEventTick disables visual feedback and the user will have no indication that a right click is imminent. If visual feedback is enabled, the driver displays a reverse video square around the touch point. At each count of TouchTick, this expands by the number of pixels specified by "HoldShowStep". If the user moves the touch point before the HoldEventTick timeout, right-click on hold is disabled until an untouch occurs, allowing drag operations to proceed without interference. A small amount of touch position change is not interpreted as deliberate movement. The amount of movement required to indicate a real drag is defined by the key "Hold Jiggle". This is in normalized (to remove technology differences) touch screen position units, which are of higher resolution than most video screens. A typical value of 0x400 provides a jiggle area of about 10 by 10 pixels on most screens. Typical Registry keys for right-click on hold are: ;... Hold touch timer. Used for cable disconnect and right-click-on-hold "TouchTick" = dword:64 ; Tick resolution. e.g. 0x64 = 100msec per tick. ;... Right-Click-On-Hold .............................. "HoldEventTick" = dword:8 ; Tick count til event. 0 disables. "HoldShowTick" = dword:1 ; 0 = immediate feedback. >= HoldEventTick = no feedback. "HoldShowStep" = dword:6 ; Feedback step size in pixels. "HoldJiggle" = dword:400 ; Hold perimeter in absolute touch units. Movement inside is still hold. Right click on hold by the driver is not compatible with the similar, but more primitive, facility provided by Aygshell. Since this feature of Aygshell cannot be turned off, to use the driver facility, the target operating system must not include Aygshell. FORCED UNTOUCH If communication with the touch monitor fails, for example due to cable disconnect, while in the touched state, the system may never receive an untouch. To prevent such a hung touch, the driver can force an untouch at a specified TouchTick count without untouch or steam events. This facility existed in release 1.14 but has been merged with right click on hold, changing its Registry keys. It now depends on "TouchTick" for timing and the trigger count is defined by "UntouchTickCount". Not defining UntouchTickCount or defining it as 0 disables forced untouch. In most cases, the forced untouch timeout can be quite short because the facility does not simply count the time from the initial touch but is reset at every stream touch message. Thus, even a setting that detects cable disconnect within milliseconds allows unlimited touch time. This is especially useful for the 2500U and 3000U controllers, which occasionally lose an untouch message when the system is very busy. For these controllers, an untouch timeout of 300 msec prevents missing untouches without causing false untouches. The 2216 controller will cause false untouches with such a short timeout. Other controllers can operate with this timeout but they only need cable disconnect detection, which could be considerably longer. The circumstances of the application dictate the ideal range of timeouts but good starting points are 300 msec for the 2500 and 3000 controllers and one second for all others. As with all Registry keys related to TouchTick, UntouchTickCount is under [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\USB] for eloUsb and under: [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH] for eloSer. For example: ;... Lost untouch and cable disconnect ....... "UntouchTickCount" = dword:0A ; 0 disables ELOTALK The EloTalk application program comprises a number of touch monitor configuration and test facilities. Related facilities are grouped into tabbed dialogs. The SmartSet dialog provides direct communication with any touchscreen controller. Among other things, this allows the serial number and calibration data to be read and written. The "Touch Hold" dialog provides a means to set any of the right click on hold and forced untouch parameters in order to determine the best settings for a particular application. The settings will be stored in the Registry as well as immediately in the driver but, unless the Registry is persistent, the static OS image settings will be restored if the system is rebooted. The ideal settings should be copied into the appropriate reg file (eloUsb.reg or eloSer.reg) and the OS image rebuilt for permanence.