深夜看代码2

昨天的文章

晚上读内核代码

有人评论说好像说了一些什么，好像又没有说什么，所以我到底是在说什么呢？

因为今天已经把内核修改好了，自己也测试了，所以这次好好说下，我到底是说了什么，又做了什么。

——问题是什么？

还是从HID来说，上面留言说的没问题，USB嘛，不就是一个发送，一个接口，设备到主机通过in端口，这个没问题。

在HID低版本的时候用的是endpoint 0端口，也不能说是低版本，即使在高版本，也是可以用endpoint 0端口的「不同之处在于低版本只有endpoint 0」，我也拿了一些竞品的产品来看，他们也是可以通过endpoint 0来发送信息给设备端的。

问题是，我们用的RK方案打开了out端点后不可以。

其他产品在打开out端口的时候，也是可以用endpoint 0 发送数据到设备的。

为什么我揪着这个endpoint 0发送呢？

是因为测试发现通过这个端口可以使用set report 函数，用这个函数来发送消息不会出现偶发的超时问题。

RK是怎么回复的呢？

他们说他们提供的方案是用endpoint 0的，都不会有问题。

而且看了内核代码，确实是配置想用哪个就用哪个，用户自己选择，用了out ，endpoint 0 就用不了了。

人家代码也是写得很清楚了，就是更子的。

——那我们为什么不直接用RK的方案，直接用endpoint 0 就好了

直接用endpoint 0我在之前的文章也说了，这样就可以兼容MAC的电脑，也不会出现一些乱七八糟可能性的问题。

但是问题是，我们的应用程序开发的很多功能，都已经实现，都是用的out端点，包的长度也是1024， 这方案一搞下去，那所有人都要重写代码，重新测试了。

—— 后面怎么修改了？

因为如果加上

设备是可以调用HOST的setreport接口的，我要做的，无非就是在这里判断下数据指令，然后传给应用程序就好了。

问题就出在这里，usb的一些结构体，如果没有好好写，就可能影响到系统的东西。

OUT端点写入数据的时候，是直接用到req结构体的

这段代码在out端点接收没有问题，但是放到setreport部分来处理就出现了问题。

setreport的处理不一样

他给HOST来的数据在内核重新分配了空间。

然后就针对这些不同的逻辑修改修改。

细节就不说了

内核代码不像应用代码，应用的调试是比较方便的，内核的调试涉及硬件设备就不同了，而且接口的处理也会不同，稍不注意引起的空指针问题，整个系统就挂了，应用还可以用守护进程拉起来，内核就不行，只能重启。

不过内核都是C，看起来还是比较舒服的。

就这些！

参考：

https://blog.csdn.net/zqixiao_09/article/details/52973392