基于Android系统的多点触摸屏(MultiTouchScreen)驱动

  • 时间:
  • 浏览:0

触摸设备的类型:

太难 算不算还不不 通过分析Android源码,找到不使用你你这名 idc文件的方法呢?

继续搜索,看某些驱动是怎么可否 设置你你这名 bit的: 

set_bit(INPUT_PROP_DIRECT, input_dev->propbit); 

很多修改朋友 的驱动,在设置input_dev型态体的以前,加进你你这名 属性的设置即可。

Linux输入子系统的型态体:

假如有一天朋友 的触摸屏输入设备通过set_bit设置propbit属性值为INPUT_PROP_DIRECT,当太难 .idc配置文件时,太难 朋友 的EventHub.cpp就会通过ioctl调用Linux中evdev.c去获取你你这名 属性的值,进行判断,最终给InputReader.cpp中的deviceType赋值为DEVICE_TYPE_TOUCH_SCREEN,从而识别朋友 的设备,达到了不不创建idc配置文件的目的。

应用空间: 

 open(“/dev/input/eventx”)

  在Linux中, 应用层对于输入设备(鼠标、键盘、触摸屏等)的操作无非都在open、read、write、ioctl,否则调用驱动层的xxx_open、xxx_read、xxx_write、xxx_ioctl去操作具体的硬件输入设备。否则按照传统的思路,每个输入设备都按照你你这名 套路写哪几种open、read等,是都在太过于累赘了。很多Linux就定义了一套标准,来标准化哪几种输入设备驱动,你你这名 标准就叫做输入子系统。通过你你这名 标准,写驱动的人沒有重复的写xxx_open、xxx_read等通用代码,而只用完成各个输入设备不同的累积(注册不同的输入设备, 上报不同的输入事件,操作不同的硬件等)。

在EventHub中去获取你你这名 属性值。

经过分析发现,在文件的你你这名 地方通过getEventHub获取设备的属性,根据设备属性同样也会更改deviceType的值。

内核空间: 

输入子系统设备驱动 

  向输入系统核心注册有三个 多具体类型的输入设备,检测输入事件的位于,并上报输入事件到输入子系统事件防止层。 

输入子系统核心 

  提供各个输入设备的注册接口,设备驱动上报事件到事件防止层的桥梁。 

输入子系统事件防止层 

  接收设备驱动上报的输入事件,提供应用层访问设备统一的接口(open, read等),将事件通过接口传递到用户空间。

  在Linux中,输入子系统是由输入子系统设备驱动层、输入子系统核心层(Input Core)和输入子系统事件防止层(Event Handler)组成。其中设备驱动层提供对硬件各寄存器的读写访问和将底层硬件对用户输入访问的响应转换为标准的输入事件,再通过核心层提交给事件防止层;而核心层对下提供了设备驱动层的编程接口,对上又提供了事件防止层的编程接口;而事件防止层就为朋友 用户空间的应用任务管理器提供了统一访问设备的接口和驱动层提交来的事件防止。很多这使得朋友 输入设备的驱动累积沒有用关心对设备文件的操作,要是要关心对各硬件寄存器的操作和提交的输入事件。下面用图形来描述一下这三者的关系吧!(转) 

首先,对触摸屏数据的埋点是采用i2c接口否则spi接口,本例子以i2c接口为例,太难 首太难熟悉i2c驱动的框架。

Android源码中搜索 touch.deviceType

去Linux内核中搜索EVIOCGPROP:

通过输入系统的你你这名 框架发现,朋友 需用做的事情要是对于不同的输入设备,写出对应的设备驱动,并向输入系统核心注册你你这名 输入设备当检测到有输入事件位于,将输入事件上报到输入子系统事件防止层就OK了。

Android官方文档: 

https://source.android.com/devices/input/touch-devices 

touch.deviceType: 

Definition: touch.deviceType = touchScreen | touchPad | pointer | default

底层硬件: 

鼠标 键盘 触摸屏等