分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow
也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!
1. TouchScreen功能在Android4.0下不工作
原来在Android2.3.5下能正常工作的TouchScreen功能,移植到Android 4.0就不能正常工作了。凭直觉,Android4.0肯定有鬼。真是不看不知道,一看吓一跳。在Android 4.0中,Event Input地位提高了,你看看,在Adroid2.3.5中,它在frameworks/base/libs/ui之下,在Android4.0中,它在frameworks/base/services/input之下,看到没有,它有了自己的地位,就像在Kernel中一样,有自己门户了。
再看看代码,变化也太大了,当然TouchScreen不能工作,首先自然会看接口部分代码。首先看它是如何打开设备的,查看函数EventHub::openDeviceLocked,看看其代码,大部分还是很熟悉的,但仔细一看多了一个下面的东东:
ioctl(fd, EVIOCGPROP(sizeof(device->propBitmask)), device->propBitmask);
由于升级到Android4.0时,Kernel还是2.6.35,并没有进行升级。既然需要EVIOCGPROP,就就看看evdev.c中的ioctl函数是否支持此功能。一看不支持,再看看Kernel3.0.8<这个Kernel版本与Android4.0是一伙的>,我的乖乖,它已经支持了此功能,详见evdev.c中函数evdev_do_ioctl,这个写得2.6.35中的友好多了,分别处理:固定长度命令、单个可变长度命令和多个可变长度命令。
对于为什么我的TouchScreen在Android4.0不工作,答案显而易见,我用的Kernel版本不对,当然移植到Android4.0对应的Kernel(Kernel3.0.8)时,TouchScreen驱动本身也需要修改,因为input_dev变化也比较大,比如增加了propbit字段,以供处理上面的ioctl时使用。
2. Android 4.0如何管理各种驱动设备
正是由于遇到上面的问题,才促使自己对Event Input进行深入了解。因为蜻蜓点水不是小弟的性格。
这个年代干啥都有什么经理,小弟之类的。比如去饭店吃饭,吃到小强了,总是会大吼一声,经理,过来看看,然后谈打折或赔偿的问题。可见经理是不可缺少的,要不然我们找谁来维权啊!
前面谈到的EventHub,这个一看就是一个做实事的,肯定不是领导,哪它的领导是谁呢? 哪我们就从以下几方面来分析此问题:
1)每个功能模块是怎么产生的?
2)读取设备输入流程?
3)事件分发流程?
3. 各个功能模块是怎么产生的?
先介绍一下每个模块的工作职责:EventHub, InputReader, InputManager...
3.1 模块功能
3.1.1 EventHub
它是系统中所有事件的中央处理站。它管理所有系统中可以识别的输入设备的输入事件,此外,当设备增加或删除时,EventHub将产生相应的输入事件给系统。
EventHub通过getEvents函数,给系统提供一个输入事件流。它也支持查询输入设备当前的状态(如哪些键当前被按下)。而且EventHub还跟踪每个输入调入的能力,比如输入设备的类别,输入设备支持哪些按键。
3.1.2 InputReader
InputReader从EventHub中读取原始事件数据(RawEvent),并由各个InputMapper处理之后输入对应的input listener.
InputReader拥有一个InputMapper集合。它做的大部分工作在InputReader线程中完成,但是InputReader可以接受任意线程的查询。为了可管理性,InputReader使用一个简单的Mutex来保护它的状态。
InputReader拥有一个EventHub对象,但这个对象不是它创建的,而是在创建InputReader时作为参数传入的。
3.1.3 InputDispatcher
InputDispatcher负责把事件分发给输入目标,其中的一些功能(如识别输入目标)由独立的policy对象控制。
3.1.4 InputManager
InputManager是系统事件处理的核心,它虽然不做具体的事,但管理工作还是要做的,比如接受我们客户的投诉和索赔要求,或者老板的出所筒。
InputManager使用两个线程:
1)InputReaderThread叫做"InputReader"线程,它负责读取并预处理RawEvent,applies policy并且把消息送入DispatcherThead管理的队列中。
2)InputDispatcherThread叫做"InputDispatcher"线程,它在队列上等待新的输入事件,并且异步地把这些事件分发给应用程序。
InputReaderThread类与InputDispatcherThread类不共享内部状态,所有的通信都是单向的,从InputReaderThread到InputDispatcherThread。两个类可以通过InputDispatchPolicy进行交互。
InputManager类从不与Java交互,而InputDispatchPolicy负责执行所有与系统的外部交互,包括调用DVM业务。
3.2 创建流程
1)在android_server_InputManager_nativeInit中创建NativeInputManager对象,并保存到gNativeInputManager中;
2)在创建NativeInputManager对象时,它会创建EventHub对象<且创建是其成员mNeedToScanDevices的值为true>,然后把刚创建的EventHub对象作为参数创建InputManager对象;
3)在创建InputManager对象时,创建InputReader对象,然后把它作为参数创建InputReaderThread;创建InputDispatcher对象,然后把它作为参数创建InputDispatcherThread对象;(注:以上两个线程对象都有自己的threadLoop函数,它将在Thread::_threadLoop中被调用,这个Thread::_threadLoop是线程入口函数,线程在Thread::run中被真正地创建)
4.1)创建InputReader对象
4.1.1)把EventHub、readerPolicy<实质为NativeInputManager对象>和创建的InputDispatcher对象作为参数创建InputReader对象:mReader = new InputReader(eventHub, readerPolicy, mDispatcher);
4.1.2)在创建InputReader时, 保存EventHub对象到mEventHub中,并创建QueuedInputListener对象并保存在mQueuedListener中
4.2)创建InputDispatcher对象
4.2.1)把传入的参数dispatcherPolicy<实质为NativeInputManager对象>作为参数创建InputDispatcher对象:mDispatcher = new InputDispatcher(dispatcherPolicy);
4.2.1)在创建InputDispatcher时,创建了一个looper对象:mLooper = new Looper(false);
3.3 启动流程
1)在android_server_InputManager_nativeStart中调用InputManager::start,代码如下:
result = gNativeInputManager->getInputManager()->start();
2)在InputManager::start中,调用mDispatcherThread->run和mReaderThread->run,代码如下:
result = mDispatcherThread->run("InputDispatcher", PRIORITY_URGENT_DISPLAY);
result = mReaderThread->run("InputReader", PRIORITY_URGENT_DISPLAY);
3)在上面的Thread::run中,调用createThreadEtc函数,并以Thread::_threadLoop作为入口函数,以上面的mDispatcherThread或mReaderThread作为userdata创建线程
4)至此InputReader线程和InputDispatcher线程都已经工作,详细信息见Thread::_threadLoop,在此函数中它将调用mDispatcherThread或mReaderThread的threadLoop函数来做真正的事
5.1)mReaderThread->threadLoop
bool InputReaderThread::threadLoop() {
mReader->loopOnce();
return true;
}
5.2)mDispatcherThread->threadLoop
bool InputDispatcherThread::threadLoop() {
mDispatcher->dispatchOnce();
return true;
}
3.4 EventInput对象关系图
4. 设备操作流程
从EventHub::getEvents读取的事件数据结构如下:
struct RawEvent {
nsecs_t when; //事件发生的时间 int32_t deviceId; //产生此事件的设备,比如发送FINISHED_DEVICE_SCAN,不需要填此项 int32_t type; //事件类型(如:DEVICE_ADDED,DEVICE_REMOVED,FINISHED_DEVICE_SCAN) int32_t scanCode; int32_t keyCode; int32_t value; uint32_t flags;};
读取事件时的调用流程为:
Thread::_threadLoop->
InputReaderThread::threadLoop->
InputReader::loopOnce->
EventHub::getEvents->
4.1 打开设备
在EventHub::getEvents中,当mNeedToScanDevices为true时<当创建EventHub对象时,它就为true>,它将从/dev/input目录下查找所有设备,并进行打开,获取其相关属性,最后加入mDevices列表中。
EventHub::scanDevicesLocked->
EventHub::scanDirLocked("/dev/input")->
EventHub::openDeviceLocked
4.1.1 打开事件输入设备
打开事件输入设备,在用户态调用open,则在kernel态中调用evdev_open函数,evdev_open处理流程如下:
1)首先从参数inode中获取在evdev_table中的索引,从而获取对应的evdev对象
2)创建evdev_client对象,创建此对象时同时为其buffer成员分配对应的内存
3)把新创建evdev_client对象添加到client_list链表中
4)把client保存在file的private_data中
5)调用evdev_open_device->input_open_device->input_dev.open函数打开设备。
4.2 读取输入事件
要说EventHub::getEvents如何获取输入事件,不得不先说说它的几个相关的成员变量:
1)mPendingEventCount:调用epoll_wait时的返回值,当然如果没有事件,则其值为0;
2)mPendingEventIndex:当前需要处理的事件索引
3)mEpollFd:epoll实例,在EventHub::EventHub中初始化此例,所有输入事件通过epoll_wait来获取,每一个事件的数据结构为:struct epoll_event,为了搞明白如何读取输入事件的原理,不得不对epoll相关的东东搞个清清楚楚,明明白白,见epoll kernel实现原理。注:epoll_event只表明某个设备上有事件,并不包含事件内容,具体事件内容需要通过read来读取。
struct epoll_event