将A/B协议这部分单独拿出来说一方面是因为这部分内容是比较容易忽视的，周围大多数用到input子系统的开发人员也不甚理解；另一方面是由于这部分知识一旦扩展到TP(触摸屏Touch Panel)的多点触摸就要与Middleware/Framework一起结合起来看才能完全掌握，复杂性所在。这里的Middleware/Framework是针对android来说的，本人从事android这几个层次的工作，所以就从android的角度来讲讲这部分内容，其他系统虽然代码不同，但原理上是完全一样的。
B协议又称为slot协议，那么input子系统里面使用的slot是什么，A/B协议究竟是如何划分的？
slot直译为位置、槽，有两层含义，一层是位置，另一层是容器。在Input子系统中，它扮演的就是这两个角色。它产生于这样一个背景：
如果从Device获取的当前数据与上一个数据相同，我们有必要再上报当前数据吗？如果我们不管两次数据是否一致都上报，那就是A协议；如果我们选择不上报，那么既然需要比较，总需要把上一次数据存起来吧，slot就是做这个事情的，显然这就是Slot(B)协议。
其实到这里，对TP不感兴趣的童鞋可以不继续向下看了，了解了两个协议的区别看或者写一般模块的代码不会有问题了。需要注意的是，想要测试Device驱动的input部分是否正常的时候，假如使用的是B协议，input_report数据的时候要记得每次都要report不同的值，否则在HAL层是看不到数据不停上报的，因为前后两个数据相同的时候，B协议是不会上报到系统的。另外，在上层测试数据上报频率的时候，采用 数据总量/时间差 的方法，如果驱动采用的是B协议，测试结果也是不准确的。
下面要说的与TP的多点触摸（MT Multi-touch）的功能关系密切，没有兴趣的可以略过。由于这部分代码不从事TP或者android的人是不会接触到的，所以代码就不贴出来了，有兴趣的童鞋可以单独交流O(∩_∩)O~
我们都知道，在支持MT的手机上多指滑动的时候，多条手指滑动过的轨迹彼此是不相交的，这也是我们所期望的。但这个功能究竟是如何实现的呢？看了上面的分析应该就知道，A/B两种协议方式都可以实现该功能。
A协议不会使用slot，多指处理中，它的报点序列如下（每一个序列都以input_report_***函数实现）：
点击(此处)折叠或打开
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
上面的序列中需要说明的是系统以SYN_MT_REPORT为一个点的信息的结尾，以SYN_REPORT为一次事件的结尾。也就是说多指触摸的时候，android的中间件部分每收到一次SYN_MT_REPORT就形成一个点信息，收到一个点之后并不会立即处理，而是一个事件完成之后才会处理，SYN_REPORT就是这个事件的标志。A协议比较简单，我们也可以发现在上面的序列中根本就没有轨迹跟踪的信息，有的只是点坐标等信息，那么系统如果去判断当前的多个点各属于哪一条线呢？
我们假设前一次事件共有5个点，本次触摸也有5个点，系统会分别计算前一次5个点与本次5个点的距离，distance[prev_i, curr_j] (i=0,1,...,4; j=0,1,...4)，这样会产生总共5*5=25个数字。然后对这25个数字进行排序，android用的是堆排序。（我们在系统上如果用多指，一般最多也是双值，也就是4个数据，这里采用了堆排序，不知是出于什么情况考虑，感觉换个方法可能更实用些。）下面的任务就是判断哪些当前点与前一次的点最近，那么赋予它们相同的id，应用收到这个信息后，就可以知道当前点属于哪条线了。
手抬起来的时候又用什么样的序列来通知系统呢，
点击(此处)折叠或打开
SYN_MT_REPORT
SYN_REPORT
只有SYNC，没有其它任何信息，系统就会认为此次事件为UP。
B协议使用了slot，还有一个新面孔TRACKING_ID.
点击(此处)折叠或打开
ABS_MT_SLOT 0
ABS_MT_TRACKING_ID **
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_MT_SLOT 1
ABS_MT_TRACKING_ID **
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
SYN_REPORT
没有SYN_MT_REPORT，那么它用什么来跟踪当前点属于哪一条线呢，用的就是ABS_MT_TRACKING_ID，当前序列中某点的ID值，如果与前一次序列中某点的ID值相等，那么他们就属于同一条线。既然如此，那么android系统中还需要做排序等运算吗？当然不需要。那么手指全部抬起的时候序列又是怎样的呢？
点击(此处)折叠或打开
ABS_MT_SLOT 0
ABS_MT_TRACKING_ID -1
SYN_REPORT
ABS_MT_SLOT 1
ABS_MT_TRACKING_ID -1
SYN_REPORT
这里上报的ABS_MT_TRACKING_ID为-1，也只有这里该值才可以小于零，收到该值，系统就会清除对应的ID。看似简单的两个协议内容到这里就分析完毕了。
看了上面的分析，明显可以看出B协议要由于A协议，但事实上并不如此简单。B协议需要硬件上的支持，ID值并不是随便赋值的，而是硬件上跟踪了点的轨迹；如果硬件上满足不了这个条件，那么采用B协议只能闹成笑话。另外，B协议的复杂性如果掌握不好往往会带来一些莫名其妙的问题，比如如果因为某些因素（同步等），在UP的时候少清除了一个slot的信息，那么下次单击的时候你也会惊奇地发现竟然有两个点（采用了B协议，slot已经保存了点信息，除非明确清除）。
希望本文对希望了解TP或者多点触摸功能的童鞋有所帮助。
参考于：http://www.cnblogs.com/rutian2013/p/3341118.html
PS：多点触控协议相关知识
Multi-touch (MT) Protocol
-------------------------
Copyright(C) 2009-2010 Henrik Rydberg<rydberg@euromail.se>
简介
------------
为了发挥新近的多点触摸和多用户设备的强大功能，为多点触摸定义一种上报详细数据的方法（比如有多个物体直接接触到设备的表面），是非常有必要的。这篇文档描述了多点触摸协议（multi-touch，MT），是的内核驱动可以对多个随意数量的触控事件上报详细的数据信息。
基于硬件的能力，该协议被分为两种类型。对于只能处理匿名接触（type A）的设备，该协议描述了如何把所有的原始触摸数据发送给接收者。对于那些有能力跟踪并识别每个触摸点的设备（type B），该协议描述了如何把每个触摸点的单独更新通过事件slots发送给接受者。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
本部分由DroidPhone 翻译：http://blog.csdn.net/droidphone
Kernel版本：V3.7
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
协议的使用
--------------
详细的触控信息被按顺序地分割为多个ABS_MT事件数据包进行发送。只有ABS_MT事件信息被识别为触控数据包的一部分，因为这些事件在当前的单点触控（single-touch，ST）应用中是被忽略掉的，我们可以在现有的驱动中基于ST协议之上来实现MT协议。
对于type A设备的驱动，在每个数据包的结尾用input_mt_sync()对多个触控包进行分割，这将会产生一个SYN_MT_REPORT事件，它通知接收者接受当前的触控信息并准备接收下一个信息。
对于type B设备的驱动，在每个数据包的开始，通过调用input_mt_slot()进行分割，同时带入一个参数：slot。这会产生一个ABS_MT_SLOT事件，它通知接收者准备更新给定slot的信息。.
两种类型的驱动通常都通过调用input_sync()函数来标记一个多点触摸数据传送的结束，这通知接收者对从上一个EV_SYN/SYN_REPORT以来的所有累加事件作出响应，并准备接收新的一组事件/数据包。
无状态的type A协议和有状态的type B slot协议之间的主要区别是通过识别相同接触点来减低发送到用户空间的数据量。slot协议需要使用到ABS_MT_TRACKING_ID，它要不由硬件来提供，或者通过原始数据进行计算【5】。
对于type A设备，内核驱动应该根据设备表面上全部有效触控进行列举并生成事件。每个触控点数据包在这次事件流中的顺序并不重要。事件过滤和手指跟踪的工作留给用户空间来实现【3】。
对于type B设备，内核驱动应该把每一个识别出的触控和一个slot相关联，并使用该slot来传播触摸状态的改变。通过修改关联slot的ABS_MT_TRACKING_ID来达到对触摸点的创建，替换和销毁。一个非负数的跟踪id被解释为有效的触摸，-
补充：移动开发 , Android ,
