HID报告描述符(Report Descriptor)脚本语言研读笔记2

本文链接：https://blog.csdn.net/luohsh1/article/details/17338101

对HID Script脚本语言的理解: Global item--全局项 Main item --主项 local item --局部项对于Main项,parser解释器,将顺序解释集合中的数据,并且,解释器解释完的数据, 将按Main项出现的先后顺序,主要是Input和Output项,顺序拼接生成对应的数据bit位, 解释器将以关键字Collection开始解释并拼接bit位信息,关键字End Collection将结束paser解释器的工作,我把关键字Collection和关键字End Collection叫做"集合", 这样给他取个名字,以后说明起来也方便些,"集合"里边描述的就是最后生成的由HID硬件设备1次性上发给pc的HID驱动程序的数据流了.在<HID协议.pdf>中,(gliethttp) 关键字Collection和关键字End Collection都是Main item主项,对应的控制字分别为: 1010 00 nn和1100 00 nn,如果Collection后边有1个参数数据,那么即为: 1010 00 01=0xA1,如Collection(Application) 翻译成控制码后为:0xA1,0x01;0xA1的1表示有1个参数数据,0x01表示Application在HID 协议中规定的索引值为0x01,pc的HID驱动程序在parser解释器中会通过0x01得知, 是对Application进行数据流位生成,就是说HID报告描述符(Report Descriptor) 所描述的数据流是为了Application使用的,Application在<HID协议.pdf>中包含两种设备:mouse和keyboard,至于Collection(Application)里边描述的是mouse 还是keyboard,将具体的由Usage进一步限定,如:Usage(KeyBoard),也就是说明确告诉pc的HID驱动程序的paser解释器,接下来的这段信息最后生成出来的bits位数据信息, 将交由pc的HID驱动程序中KeyBoard对应的API函数处理,当然这只是HID硬件设备开发者给pc的HID驱动程序的paser解释器提供的一个建议值,比如我们做DDK下的HID驱动二次开发, 那么我们可以很随意,但是HID硬件设备开发者,建议使用的HID驱动程序API接口,最好遵守, 因为HID硬件设备开发者比DDK开发人员更清楚送上来的bit数据流的真正物理意义. Input和Output是用来真正生成bits位流数据域的关键字,他们描述的东西是最后通过 usb总线实实在在发送到pc或者从pc接收的数据位,当然这些bits数据流数据域所代表的意义以及某段bits位们所代表的意思以及这些bits将交由pc上HID驱动程序的哪一个API接口来做进一步解析(是mouse还是keyboard),需要其他描述符来描述,比如前边的Usage就是其中的1个描述符, 如果一个HID设备同时提供2种不同的功能,那么就会分别生成2个bits位流数据域, 每个bits位流数据,将交由不同的驱动解析,比如,一个keyboard可能还集成了一个附属的鼠标功能, 那么键盘数据信息将由HID script脚本描述的keyboard对应bits数据位流传送,mouse数据将由 HID script脚本描述的mouse对应bits数据位流传送,但同一个Input管道怎么能传送两个独立的数据流呢,答案很简单:不能,所以又引入了一个Report ID的概念,ID用来标识多条独立的bits数据流, pc的HID驱动程序根据ID,将这些独立的bits数据流们路由到相应的API处理函数上去, 进而不同的bits数据流数据最终都能够被自己对应的API驱动函数正确接收并解析处理. 对于2字节、4字节等多字节数据的传输,是按小端模式little-endian进行的.这些多字节数据的最小值由Logical Minimum定义,最大值由Logical Maximum定义,如果两个值均为非负值,那么bits位流数据就是无符号数,如果没有明确指定,那么作为有符号数处理,另外HID1.1协议不允许传输浮点数据. 硬件开发者应该时刻清除自己写的HID script脚本所描述的数据流将来应该由PC上的HID驱动程序怎么使用,另外对于硬件开发者来说,对于不允许PC驱动修改的bit位数据,HID1.1协议制定者强烈建议采用NULL数值,最好不要随便填其他值. ---------------------------------------------- Main item --主项当前一共5个: 1)Input 2)Output 3)Feature 4)Collection 5)End Collection ---------------------------------------------- Global item--全局项当前一共13个: 1)Usage Page 2)Logical Minimum ---var变量或array数组的逻辑最小值 3)Logical Maximum 4)Physical Minimum 5)Physical Maximum 6)Unit Exponent ---单位的指数值,是10的指数 7)Unit ---单位索引号:可以是时间单位、电流单位、电压单位和距离单位等等. 8)Report Size 9)Report ID ---数据流的ID值设置 10)Report Count 11)Push 12)Pop 13)Reseved ---保留 ---------------------------------------------- local item --局部项当前一共11个: 1)Usage ---定义Uage Page下面某个功能item的起始索引值,比如Keyboard功能,LEDs功能等, 这也告诉pc的HID解释器,Input或Output变量或数组的相应生成数据位用来描述 Usage引用到的那个功能,如:用来描述Keyboard功能或LEDs功能等. 2)Usage Minimum ---定义与array或bitmap关联的usage定义的某个功能下的起始值 Usage作为Uage Page的一个子功能索引号,同时Usage自己也有很多子功能,或者说有很多个子值,这里就是定义这些子值的范围值,之后和用Input或Output生成 bits位数据流,进行相应关联.(可以用多维数组来说明,可能会更明确一点) 如:Gliethttp[5][6][80],Gliethttp为最上层,5就是Usage Page(5),6就是在前一个基础上Usage(6),当然在HID Descriptor Tool里边6有它的字符串名,即: Usage(Keyboard),然后80就是Keyboard里边的一个索引取值,查找之后是: KeyBoard LeftArrow,所以Usage_Minimum(80)就等于Usage_Minimum(KeyBoard LeftArrow) Usage的顺序先后和Report Count定义的bits位组的先后顺序依次一一对应,Usage Minimum和

Usage Maximum之间的Usage的索引值也将依次与Report Count定义的bits位组的先后顺序

依次一一对应上。 3)Usage Maximum ---定义与array或bitmap关联的usage的结束值 4)Designator Index 5)Designator Minimum 6)Designator Maximum 7)String Index 8)String Minimum 9)String Maximum 10)Delimiter 11)Reserved local的作用范围不会延续到下一个Main item,下一个Main item开始的local值会自动恢复到local的默认值;如果local item定义开始到下一个Main item之间的 Report Count=0,那么local item的属性值将作用在下一个Main item上(通常是Collection) 以上部分内容来自<HID协议.pdf>,部分内容是自己的揣测式理解,可能有不正确之处,要是能够拿到 HID Descriptor Tool工具的源码就能够清除pc的HID驱动程序下的parser解释器到底是怎么处理以上关键字的了,linux里边可能有,如果大家打算再深入一些的话,我想你可以到linux 的源程序里边去看看,那里有parser解释器的全部源程序,不过对于我来说,以上的这些知识基本上就够用了,再往往深入走,对我已经没有什么用了,所以就到这里;这2篇研读笔记是我在english文档中辛苦的总结, 希望能够对刚刚开始做HID这方面工作的同行们有一点点积极的作用(gliethttp).