Android-powered Linux Input Subsystem tp--a/b (Slot) protocol "Go"

Transferred from: http://www.thinksaas.cn/topics/0/646/646797.html

This part of the A/b agreement is taken separately, on the one hand because this part of the content is relatively easy to ignore, most of the developers using the input subsystem are not very understanding, on the other hand because this part of the knowledge once extended to TP (touch panel) Multi-touch will be combined with middleware/framework to see the full mastery of the complexity. The middleware/framework here is for Android, I am engaged in the work of Android, so from the perspective of Android to say this part of the content, other systems although the code is different, but the principle is exactly the same.

      B protocol, also known as the slot protocol, what is the slot used in the input subsystem, and how is a/b protocol divided?       Slots are position, slot, two meanings, one layer is position, the other is container. In the input subsystem, it plays these two roles. It arises from such a background:      If the current data obtained from the device is the same as the previous data, do we need to escalate the current data? If we do not report two times whether the data is consistent, it is a protocol; If we choose not to report, then since the need to compare, it is necessary to save the last data, slot is to do this, obviously this is the slot (B) protocol.       In fact, to this, the TP is not interested in the children's shoes can not continue to look down, understand the difference between the two protocol look or write the code of the general module will not have a problem. It should be noted that if you want to test the device driver input part is normal, if the use of the B protocol, input_report data should remember each time the report different values, otherwise in the HAL layer is not see the data constantly reported, The B protocol is not escalated to the system because the two data are the same. In addition, in the upper test data escalation frequency, the use of data total/time difference method, if the driver is a B protocol, the test results are inaccurate.       The following points are closely related to the function of TP's multitouch (MT multi-touch), and no interest can be skipped. Since this part of the code does not engage in TP or Android people will not be exposed, so the code is not posted out, interested in children's shoes can be exchanged separately O (∩_∩) o~        We all know that in support of Mt mobile phone more finger sliding, The trajectory of multiple fingers is disjoint, which is what we expect. But how is this function implemented? Look at the above analysis should know, A/b two protocol methods can achieve this function.       A protocol does not use slots, multi-finger processing, and its quote sequence is as follows (each sequence is implemented with the input_report_*** function): Click (here) to collapse or open abs_mt_position_x X[0]abs_ Mt_position_y y[0]syn_mt_reportabs_mt_position_x x[1]abs_mt_position_yY[1]syn_mt_report ... syn_report        The above sequence requires that the system Syn_mt_report to the end of the information at a point, syn_report as the end of the event. That is to say, when the touch of the Android, the middleware part of the Syn_mt_report to form a point of information every time, received a point and will not be processed immediately, but after an event is completed before processing, Syn_report is the flag of this event. A protocol is relatively simple, we can also find that in the above sequence there is no trace tracking information, and some are only point coordinates and other information, then the system to determine the current multiple points belong to which floss?         We assume that the previous event had a total of 5 points, this touch also has 5 points, the system calculates the distance from the previous 5 points to the 5 points, distance[prev_i, Curr_j] (i=0,1,..., 4; j= 0,1,... 4), this will produce a total of 5*5=25 numbers. Then the 25 numbers are sorted, and Android uses a heap sort. (We in the system if the multi-fingered, generally at most is a double value, that is, 4 data, where the heap sorting, I do not know what is the case, I feel that a different method may be more practical.) The task below is to determine which current points are closest to the previous one, then give them the same ID, and once the application receives this information, it can know which line the current point belongs to.         What sequence is used to notify the system when the hand is lifted, click (here) to collapse or open syn_mt_reportsyn_report        only sync , without any other information, the system will assume that this event is up. The       &NBSP;B protocol uses slots and a new face tracking_id. Click (here) to collapse or open Abs_mt_slot 0abs_mt_tracking_id **abs_mt_ position_x x[0]abs_mt_position_y y[0]abs_mt_slot 1abs_mt_tracking_id **abs_mt_position_x X[1]ABS_MT_POSITION_Y y[1] syn_report      No syn_mt_report, then what does it use toTrace the current point belongs to which Floss, with abs_mt_tracking_id, the ID value of a point in the current sequence, if the ID value of a point in the previous sequence is equal, then they belong to the same line. So, what sort of operations do you need to do in the Android system? Of course not. What about the sequence when all the fingers are lifted?       Click (here) to collapse or open Abs_mt_slot 0abs_mt_tracking_id-1syn_reportabs_mt_slot 1abs_mt_tracking_id-1syn_ report  the abs_mt_tracking_id here is-1, and only here the value can be less than 0, received this value, the system will clear the corresponding ID. The seemingly simple two protocol content has been analyzed here.       Looking at the above analysis, it is clear that the B protocol is due to a protocol, but in fact it is not so simple. B protocol requires hardware support, the ID value is not random assignment, but the track of the hardware tracking points, if the hardware can not meet this condition, then the B protocol can only be made into jokes. In addition, the complexity of the B protocol will often lead to some puzzling problems, such as if, because of some factors (synchronization, etc.), when the up time to clear a slot information, then the next click on the time you will be surprised to find that there are two points (using the B protocol, the slot has saved a bit of information , unless explicitly cleared).       Hope this article is helpful for children's shoes that want to learn about TP or multi-touch functionality. Reference: Http://www.cnblogs.com/rutian2013/p/3341118.htmlPS: Multi-Touch Protocol Knowledge multi-touch (MT) protocol ---------------- ---------          copyright (C) 2009-2010 Henrik rydberg<[email protected]>& nbsp;  profile------------     to give full play to the new multi-touch and multi-user devices, define a method for multi-touch reporting of detailed data (such as having multiple objects directly touching the surface of the device), is very necessary. This document describes the multi-Touch Protocol (MULTI-TOUCH,MT), which isThe kernel driver can escalate detailed data information to a number of random touch events.      Hardware-based capabilities, the protocol is divided into two types. For devices that can handle only anonymous contact (type A), the protocol describes how to send all the raw touch data to the recipient. For devices that have the ability to track and identify each touch point (type B), the protocol describes how individual updates for each touch point are sent to the recipient via event slots.   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  this section by Droidphone Translation: Http://blog.csdn.net/droidphoneKernel version: v3.7~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The use of the ~~~~~~~~~~~~  protocol--------------     detailed touch information is sequentially split into multiple ABS_MT event packets for sending. Only the ABS_MT event information is recognized as part of the touch packet because these events are ignored in the current single-Touch (SINGLE-TOUCH,ST) application, and we can implement the MT protocol on the existing driver based on the ST protocol.      for the type a device driver, multiple touch packs are split with Input_mt_sync () at the end of each packet, which results in a Syn_mt_report event, It notifies the recipient to accept the current touch information and is ready to receive the next message.      for the type B device driver, at the beginning of each packet, by calling Input_mt_slot () to split, and bring in a parameter: slot. This results in a Abs_mt_slot event that notifies the recipient to be ready to update the information for the given slot. .     Two types of drivers usually mark the end of a multi-touch data transfer by calling the Input_sync () function. This notifies the receiver to respond to all accumulated events since the previous Ev_syn/syn_report and prepares to receive a new set of events/packets.      stateless type a protocol and stateful type B slot protocol between the masterThe difference is to reduce the amount of data sent to the user space by identifying the same contact point. The slot protocol needs to be used to abs_mt_tracking_id, which is either supplied by the hardware or calculated "5" from the original data.      for Type a devices, the kernel driver should enumerate and generate events based on all the effective touch on the device surface. The order of each touch point packet in this event stream is not important. The work of event filtering and finger tracking is left to the user space to implement "3".      for Type B devices, the kernel driver should correlate each identified touch with a slot and use that slot to propagate changes in the touch state. The creation, substitution, and destruction of touch points is achieved by modifying the abs_mt_tracking_id of the associated slots. A non-negative Tracking ID is interpreted as a valid touch, and 1 represents a slot that is no longer in use. A trace ID that was not previously seen is considered a new touchpoint and is considered to have been removed when a Tracking ID no longer appears. Since only the changed parts are propagated, the state information of each initiated touchpoint must reside on the receiving side. Whenever a MT event is received, simply update the relevant properties of the current slot once.      Some devices can identify and/or track more contact points than it can report to the driver, and the driver for such a device should associate a slot of type B with each contact point the hardware escalated. Once a contact point that is associated with the slot has been identified, the driver should invalidate the slot by changing his abs_mt_tracking_id. If the hardware notifies it that it tracks more touchpoints than is currently reported, the driver should use the Btn_tool_*tap event to inform the user space that the total number of contact points for hardware tracking at the moment has changed. To complete this work, the driver should explicitly send the Btn_tool_*tap event and set the Use_count parameter to False when calling Input_mt_report_pointer_emulation (). The driver should only advertise the number of slots that the hardware can report. User space can detect whether the driver can report more than slots number of touch points by noting that the maximum supported Btn_tool_*tap event is greater than the total number of slots of type B reported in the absinfo of the abs_mt_slot axis.  protocol Example a------------------     for a two-touch touch message, the smallest thing about type A deviceThe sequence of pieces looks like this:     abs_mt_position_x x[0]     abs_mt_position_y y[0]     syn_mt_report     abs_mt_position_x x[1]     abs_mt_position_y y[1]     syn_mt_report     syn_report       In fact, the escalation sequence after moving one of the touch points looks the same, and all the original data that has the touch point is sent, They are then synchronized between them with Syn_report.        When the first point of contact leaves, the sequence of events is as follows:      abs_mt_position_x x[1]      abs_mt_position_y y[1]      SYN_MT_REPORT      SYN_REPORT     When the second point of contact leaves, the sequence of events is as follows:     syn_mt_report     syn_report     If the driver is in the Abs_ A Btn_touch or Abs_pressure event is reported outside of the MT event, and the last Syn_mt_report can be omitted, otherwise the final syn_report will be thrown away by the input core, resulting in a 0 touch point event being uploaded to the user space.   protocol Example b------------------     for a two-touch touch message, the smallest sequence of events for type B devices looks like this:       abs_mt_slot 0      abs_mt_tracking_id 45     abs_mt_position_x x[0]     abs_mt_position_y y[0]   & nbsp Abs_mt_slot 1     abs_mt_tracking_id 46     abs_mt_position_x x[1]     ABS _mt_position_y y[1]     syn_report     The event sequence after the touch point of ID 45 moves in the x direction is as follows:     Abs_ Mt_slot 0     abs_mt_position_x x[0]     syn_report     SLOT 0 corresponds to the contact point left after The corresponding sequence of events is as follows:     abs_mt_tracking_id-1    SYN_REPORT     The last modified slot is also 0, So Abs_mt_slot is omitted. This message removes the slot 0 associated with the contact point 45, so the contact point 45 is destroyed and slot 0 is freed to be reused by another point of contact.        Finally, the time sequence after the second contact point leaves is as follows:      abs_mt_slot 1     &NBSP;ABS_MT _tracking_id-1      SYN_REPORT  Event usage-----------     A set of ABS_MT event sets are defined as required. These events are divided into groups to allow only a subset of them to be implemented. The smallest set consists of abs_mt_position_x and abs_mt_position_y, which are used to track multi-point contact. If the device supports, abs_mt_touch_majorAnd abs_mt_width_major can be used to provide contact area and corresponding contact tool. The       touch and width parameters have a geometric interpretation. Imagine a window observing a person pressing a finger on the opposite glass, and you will see two areas where the inner ring contains the actual part of the contact with the glass, and the outer rim is the contour of the finger. The contact area (a) is abs_mt_position_x/y, and the center of the finger Contour area (b) is abs_mt_tool_x/y. The diameter of the contact area is abs_mt_touch_major, and the diameter of the finger contour is abs_mt_width_major. Now imagine the person pressing the finger closer to the glass, the contact area increases, and usually the abs_mt_touch_major/abs_mt_width_major ratio is always less than 1, which is associated with the pressure of the contact. However, for pressure-based equipment, the abs_mt_pressure should be used instead to provide the pressure value of the contact. Devices that can detect suspension can use Abs_mt_distance to indicate the distance from the surface.             &NBSP;LINUX&NBSP;MT                               win8          __________     &NB Sp              _______________________        /    &N Bsp                          ,         &NB SP; |               &NBsp                          ,         &NB sp;|                               &NBSP ;                  |                          ,         &NB Sp                |      /     ____                               |                          ,         &NB Sp                |    /   /                                  &NBSP    |                          ,         &NB Sp              |          a         &NB Sp                           |       A                             nbsp           |            ____/        &NBSP ;                    |                          ,         &NB Sp              |                   &NBS P                              |                          ,         &NB Sp              |               &NBSP;B   &NB Sp                              |           B                         nbsp           |                       &NB Sp                           |                          ,         &NB Sp               |                   &NB Sp                                |                          ,         &NB Sp               |                   &NB Sp                               |                          ,         &NB Sp               |                   &NB Sp                      /        |                          ,         &NB Sp           &NBSP;   |                               &NB Sp        /         |                          ,         &NB Sp                 |                 &NB Sp                    /          |                          ,         &NB Sp                 |                ____ ______/           |_______________________|     In addition to major parameters, The oval shape of the contact and finger areas can also add a minor parameter, with the major and minor parameters equivalent to the long and short axes of the ellipse. The direction of the ellipse in the contact area can be described with the orientation parameter, while the elliptical direction of the finger area can beis obtained by means of a vector operation (A-B).      for Type a equipment, future specifications may be abs_mt_blob_id to describe the shape of the contact.      Abs_mt_tool_type can be used to indicate whether a touch tool is a finger or a pen or other object. Finally, the abs_mt_tracking_id should always be used to track the identified contact point "5".      In the Type B protocol, Abs_mt_tool_type and abs_mt_tracking_id are hidden in the input core layer for processing, and the driver should instead call Input_mt_report_ Slot_state (). The semantic description of the    event---------------  ABS_MT_TOUCH_MAJOR    length of the long axis of the contact area. The length should be supplied in units of the contact surface. If the resolution of the surface is X-y, the maximum possible value for Abs_mt_touch_major is sqrt (x^2 + y^2), which is the diagonal "4".   ABS_MT_TOUCH_MINOR    Contact Area short axis surface unit length. If the area is a circle, the event can ignore "4".   ABS_MT_WIDTH_MAJOR    Tool Contour Area long axis surface unit length. This should be the size of the tool province. The orientation of the contact surface and the contour surface is assumed to be the same as "4".   ABS_MT_WIDTH_MINOR    Tool Contour area short axis surface unit length, circular words can be ignored "4".      The above 4 values can be used to derive additional information about the contact surface. Abs_mt_touch_major/abs_mt_width_major can be used as a close pressure. The fingers and palms have no characteristic width. The pressure value of the   ABS_MT_PRESSURE    contact area can be any unit. Pressure-based devices should use this event instead of the touch and width events. Also used for devices that can report the strength of a space signal.   ABS_MT_DISTANCE    The surface unit distance between the contact and the contact surface. The distance of 0 indicates that it has reached theSurface. A positive value indicates that the contact is suspended above the surface.   ABS_MT_ORIENTATION    The direction of the contact Ellipse area. This value describes the number of signed 1/4 clockwise rotations around the touch center. The range of the number is not qualified, but should return a value of 0 when the ellipse and the Y-direction of the surface are aligned, the ellipse should return a negative when it turns to the left, and positive values should be returned to the right. When fully aligned with the x-axis, the maximum value should be returned.       Contact Ellipse is assumed to be a symmetric point. For devices that can be rotated 360 degrees, it is necessary to report out the maximum range to indicate more than 1/4 turns. For inverted fingers, the maximum range of twice times should be reported.        If the contact surface is a circle, or the orientation information is not available in the kernel driver, the direction parameter can be ignored. If the device can identify two axis orientations, it is possible to support only partially discontinuous orientations, in which case the Abs_mt_orientation range should be [0,1] "4". X-coordinate of the  ABS_MT_POSITION_X    contact center. The Y-coordinate of the   ABS_MT_POSITION_Y    Contact Center   ABS_MT_TOOL_X    The X-coordinate that touches the center of the tool outline. This event can be ignored if the device cannot differentiate between the contact surface and the tool itself.   ABS_MT_TOOL_Y    Touch the Y-coordinate of the tool Contour Center. This event can be ignored if the device cannot differentiate between the contact surface and the tool itself.       These 4 position values can be used to detach the actual contact position from the touch tool position. If both position information is present, then the long axis of the touch tool points to the contact point, otherwise the tool and the axis of the contact face pair it with each other.  ABS_MT_TOOL_TYPE    Types of proximity tools. Many kernel drivers cannot distinguish between different touch tools, such as fingers and pens. In this case, the event can be ignored. The current protocol supports both Mt_tool_finger and Mt_tool_pen "2" types. For type B devices, the event is handled by the input core layer, and the driver should be escalated using input_mt_report_slot_state () instead.   ABS_MT_BLOB_ID    BLOB_ID Events put a fewThe data packets are grouped together to form an arbitrary contact shape. Some points consist of a sequence that defines the shape of a polygon. This is an underlying anonymous data combination of type a devices and should not be confused with the tracking IDs of the upper layers. Most type a devices do not have the ability to blog, so the driver can safely ignore the event.   ABS_MT_TRACKING_ID    TRACKING_ID identifies the entire life cycle "5" of a touch point that has been initiated. The scope of the tracking_id should be large enough to ensure that a unique value can be maintained for a long enough period of time. For type B devices, the event is handled by the input core layer, and the driver should instead use Input_mt_report_slot_state () to escalate the event.    calculation of events-----------------     A bunch of different hardware inevitably leads to some devices that are better suited to the MT protocol than others. For simple and uniform correspondence, this section gives some methods to determine how certain events are calculated.       For those who report contact shapes as rectangles, we cannot get the signed directional values, assuming that x and Y are the two sides of the contact rectangle respectively, and the following formulas are the most likely to get the most information:     Abs_mt_touch_major: = max (x, y)      Abs_mt_touch_minor: = min (x, y)      Abs_mt_orien Tation: = bool (X > Y)      Abs_mt_orientation range should be set to [0,1] so that the device can differentiate whether the finger is along the Y axis or along the X axis "1".       for WIN8 devices with T and C coordinates, the correspondence between location information is:     abs_mt_position_x: = t_x     Abs_mt_position_y: = t_y     abs_mt_tool_x: = c_x     abs_mt_tool_x: = c_y   &nbs P Very notFortunately, there is not enough information to determine the touch ellipse and the tool ellipse, so you can only resort to approximate algorithms. A simple solution that is compatible with earlier uses is:       abs_mt_touch_major: = Min (X, Y)       abs_mt_ Touch_minor: = <not used>      abs_mt_orientation: = <not used>      abs_mt_width_major: = min (x, y) + distance (T, C)       abs_mt_width_minor: = min (x, y)  &nbs P   The rationale is that we don't have information about the touch ellipse, so we use its inscribed circle shape to approximate it. The ellipse of the Touch tool should be aligned with the vector (T-C), so its diameter must be increased (T, C) between the distances. Finally, assuming that the diameter of the touch area equals the thickness of the touch tool, we can get the above formula.    finger tracking---------------     Track the processing of your finger, for example, assigning a unique trackingid to each touch point that starts on the surface, is a Euclidean parity match problem. In each event synchronization, a set of actual touch points to match a set of touch points in the previous synchronization, the complete implementation please refer to "3".    gestures--------     in certain special applications that can generate gesture events, you can use the touch and width parameters, such as the pressure on the finger or the index finger and thumb. Using the extra minor parameter, you can tell whether the whole finger is pressed or just a point pressure of the finger. Using the orientation parameter, we can detect the twist of the finger.    precautions------------     in order to be compatible with existing applications, the data reported in a finger packet cannot be identified as a single touch event.       for Type a devices, all finger data is skipped through the input filtering algorithm because the next event of the same type points to a different finger.       For examples of using Type a protocol devices, refer to the bcm5974 driver. For an example of type B protocol, refer to the Hid-egalax driver. &NBSP;&NBSP;&NBSP;[1] Also, the difference (tool_x-position_x) can be used to model TILT.&NBSP;[2] The list can of course Be extended. [3] Mtdev project: http://bitmath.org/code/mtdev/. [4] See the Event Calculation section. &NBSP;[5] See the contents of the Finger tracking section.

Tp--a/b (Slot) protocol "turn" of the Linux input subsystem of the Android drive