Touch data packet structures and utilisation in UPDD

Touch devices now cater for single, dual and multi-touch with the majority of devices being USB although some serial are still developed.

With serial devices touch data is delivered on the single interface. If the driver is to communicate with the controller then a bi-directional interface is established to allow data to flow in both directions.

However, with USB devices, there can be many interfaces and each interface can support a number of endpoints. Each interface and endpoint can perform a separate function and the USB descriptor is used to inform the system of the USB configuration.

In is most basic form the USB controller will have one interface with a control endpoint and a data endpoint, typically interface 0, with data delivered on endpoint 1.  The touch data sent will be the same irrespective of the host operating system.  A basic overview of USB device configuration is available here.

More complex USB touch controllers will support a number of interfaces, such that depending on the operating system in use the device will output different data packets, say mouse packet in Windows XP, Linux, Mac OS X, CE, digitizer packet in Vista and dual or multi-touch in Window 7 / 8 and each of these will be delivered on a different interface.  The command exchange with the host OS will determine the packet type to use and typically will be programmed to respond to commands sent for Windows HID driver. So, for example, in Windows 7 / 8 a set feature command will be sent to inform the controller that the OS is dual / multi-touch aware.

As discussed, to define a USB device in UPDD we need to know the following information:

USB Vendor id

USB Product id

USB set feature requests, if used, to switch the controller to dual or multi-touch

USB Interface and endpoint used to deliver the touch data

Touch data format

Touch data format

This can take various forms, from raw analogue data, which needs much processing to calculate the X and Y, to very basic and straight-forward co-ordinate data packets.  HID compatible USB devices will also be driven by HID recommendations and will deliver data in keeping with this specification.

UPDD can cater for any type of input as long as the technical information is available, or can be derived, to allow us to configure the data packet in our packet interpreter.  UPDD’s packet interpreter relies on using a mnemonic code to describe to the driver the structure of the data packet such that key elements of the data can be identified to the driver, such as header bytes, touch down /up bits, stylus information, X and Y data, data format (decimal / binary). Where the delivered data is complex and does not deliver straight-forward co-ordinate data then we can write additional ‘pre-processor’ code to generate a data structure that can be utilised by the interpreter code.

When dealing with a device already in the market then obviously we have to cater for the device as is and configure accordingly.

We dealing with a device under development that might want to be supported by UPDD then these are our recommendations. These recommendation also take into consideration the packet structures utilised by HID (typically referred to a Parallel or Hybrid) packet structures

HID

A parallel packet structure is a fixed length packet that caters for all possible touches from a device in one packet. Hybrid packets deliver the same data in more than one packet.

Here is a typical HID parallel packet delivering a dual touch:

	header	contact	stylus	X	Y	contact	stylus	X	Y	count
Format	01	03/02/00	01	Xh,Xl	Yh, Yl	03/02/00	02	Xh,Xl	Yh, Yl	01/02
1 touch	01	03	01	nn,nn	nn,nn	00	00	00 00	00 00	01
2 touch	01	03	01	nn,nn	nn,nn	03	02	nn,nn	nn,nn	02

Header	01 = Touch data. If delivering other HID packet types, typically a ‘mouse’ packet to denote that the device is only catering for single touch then the header is often a different value, such as 03
Contact	03 = Pen down, 02 = last touch, 00 = pen up
Stylus	Unique stylus id
X or Y	Co-ordinate data
Count	Number of stylus in contact

UPDD

For any packets that are not delivering straight-forward co-ordinate data packets then we need to be supplied technical information that is sufficient to allow us to process the data and extract the touch coordinate for all stylus, stylus id and pen down / up states.

For packets delivering co-ordinate data it is useful if the structure clearly identifies the individual components as shown in the HID packet above.  Where this information is not easily derived then addition code needs to be written to process the incoming data stream rather than being able to simply define the structure to the driver’s packet interpreter.

For the above HID data packet structure we can define 2 packets in the UPDD interpreter mnemonics to support the device:

Stylus 0		Stylus 1
Byte 0	0 0 0 0 0 0 0 1	Byte 0	0 0 0 0 0 0 ~LIFT, NOP
Byte 1	0 0 0 0 0 0 ~LIFT, NOP	Byte 1	0 0 0 0 0 0 ST00 0 (stylus  = 1)
Byte 2	0 0 0 0 0 0 ST00 1 (stylus  = 0)	Byte 2	x x x x x x x x
Byte 3	x x x x x x x x	Byte 3	x x x x x x x x
Byte 4	x x x x x x x x	Byte 4	y y y y y y y y
Byte 5	y y y y y y y y	Byte 5	y y y y y y y y
Byte 6	y y y y y y y y	Byte 6	0 0 0 0 0 0 1 0

~LIFT – indicates when bit goes from 1 to 0 a pen up occurs.

Considerations

In UPDD 4.1.10 stylus 0 co-ordinates are passed to the OS when working in a single stylus environment irrespective of the number of incoming touches.  All touch information will be available to applications using our API. When working in dual or multi-touch enviroments (windows 7, 8, Linux MPX etc) all stylus information is passed to the OS.

We are aware that with some multi-touch devices the stylus number do not always start at 0 or remain at 0 whilst the device is used so starting with UPDD 5.0.2 we are using a different approach to identify a data stream that will be fed to a single touch OS.

We are also aware that stylus numbers associated with an incoming data stream can change or switch position in the parallel packet and with 5.0.2 we intend to synthesize the stylus id from the incoming data stream rather than rely on the stylus number shown in the packet.