Touch Screen Stream Interface


Drivers which deal with user I/O like display, keyboard, mouse and touch are someway different respect to the others: they’re loaded by GWES, first of all, and they have a specific interface rather than following the common stream interface. This has at least a drawback: the developer has to familiarize with different programming practices. In WEC 7 MSFT introduces a MDD/PDD stream interface model for the touch screen drivers which can furnish aid to the programmers. Does this mean that old-fashioned touch screen drivers won’t work in WEC7? No they still work  because GWES still relies on the old touch screen driver model. The magic is provided by tchproxy.dll: as the name suggests it acts as a proxy between GWES and the stream interface touch screen driver since it exposes itself to GWES as a classical touch screen driver while internally calling the stream interface touch screen driver. This driver must -rougly speaking- handle a number of IOCTL‘s which are functionally almost equivalent to the low (PDD) interface in the old model: for example IOCTL_TOUCH_ENABLE_TOUCHPANEL <-> DdsiTouchPanelEnable, IOCTL_TOUCH_GET_SAMPLES <-> DdsiTouchPanelGetPoint and so on (you can see
the details in the documentation if you installed any of the WEC7 CTP). Looking at the system registry you may then have these scenarios:

 [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]
     "DriverName"="tchproxy.dll"

 [HKEY_LOCAL_MACHINE\Drivers\Touch]
     "Prefix"="TCH"
     "Index"=dword:1
     "Order"=dword:2
     "Flags"=dword:8        ; DEVFLAGS_NAKEDENTRIES
     "IClass"=multi_sz:"{25121442-08CA-48dd-91CC-BFC9F790027C}",
                       "{7119776D-9F23-4e4e-9D9B-9AE962733770}"
     "Priority256"=dword:6D    ; touch ist priority = 109
     "DLL"="touch.dll"

 [HKEY_LOCAL_MACHINE\System\GWE\TouchProxy]
     "tchcaldll"="tchcaldll.dll"
   

This is the default case, in which GWES loads the proxy which in turns load the actual driver. The tchcall.dll includes the standard calibration routines if the driver does not
implements its own. If you’re going to write a driver from scratch this is the recommended approach.

 [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]
     "DriverName"="touch.dll"
   

In this case GWES loads directly a touch screen driver written according to the old model so you can reuse what you’ve already done.

 [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]
     "DriverName"="tchproxy.dll"

 [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch]
     "Prefix"="TCH"
     "Index"=dword:1
     "Order"=dword:2
     "Flags"=dword:8        ; DEVFLAGS_NAKEDENTRIES
     "IClass"=multi_sz:"{25121442-08CA-48dd-91CC-BFC9F790027C}",
                       "{7119776D-9F23-4e4e-9D9B-9AE962733770}"
     "Priority256"=dword:6D    ; touch ist priority = 109
     "DLL"="touch.dll"

In this case the actual touch screen driver is loaded by the device manager: the touch proxy wait for the driver to be loaded, possibly failing after a timeout. Note that in this case the registry entries must include the {25121442-08CA-48dd-91CC-BFC9F790027C} GUID since the proxy registers a notification for this TCH_DRIVER_CLASS_GUID.

Advertisements
This entry was posted in Windows Embedded Compact and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s