nel driver. Partial orientation support is possible if the devicecan distinguish between the two axis, but not (uniquely) any values inbetween. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1][4].
ABS_MT_POSITION_X
The surface X coordinate of the center of the touching ellipse.ABS_MT_POSITION_YThe surface Y coordinate of the center of the touching ellipse.
ABS_MT_TOOL_TYPE
The type of approaching tool. A lot of kernel drivers cannot distinguishbetween different tool types, such as a finger or a pen. In such cases, theevent should be omitted. The protocol currently supports MT_TOOL_FINGER andMT_TOOL_PEN [2]. For type B devices, this event is handled by input core;drivers should instead use input_mt_report_slot_state().
ABS_MT_BLOB_ID
The BLOB_ID groups several packets together into one arbitrarily shapedcontact. The sequence of points forms a polygon which defines the shape ofthe contact. This is a low-level anonymous grouping for type A devices, andshould not be confused with the high-level trackingID [5]. Most type Adevices do not have blob capability, so drivers can safely omit this event.
ABS_MT_TRACKING_ID
The TRACKING_ID identifies an initiated contact throughout its life cycle[5]. The value range of the TRACKING_ID should be large enough to ensureunique identification of a contact maintained over an extended period oftime. For type B devices, this event is handled by input core; driversshould instead use input_mt_report_slot_state().