TP 跟手度

getevent -ltr  获取报点率

报点率是TP的概念,屏幕刷新是LCD的概念。不是一个概念。getevent中看到的报点率(rate)是个统计概念,每收到一个新的点都会计算跟前一个点的事件间隔,间隔长计算出来的报点率就低

​TP固件应该可以配置发出中断信号的频率,这个跟getevent中的rate概念有关联但不太一样。对这个感兴趣可以问厂商.

3 我们一致认为10ms触发一次中断是合理的,但是目前debug下来是花了100ms,搞清楚这个问题最直接的方法就是在isr中加log1 isr触发间隔,理论上应该接近10ms2 isr中是否有报点)。

考虑到客户不方便提供驱动代码,我在本地用我司参考机测试了一下,tp驱动代码。由于不了解客户驱动代码,客户可参考下面的方案在自己的代码中验证。

drivers/input/touchscreen/adaptive-ts/ats_core.c

1 测试前后检查tp中断数,相差64-25=39

测试前:

console:/ # cat /proc/interrupts | grep adaptive                                

 72:         25          0          0          0          0          0          0          0  irq-ap-gpio 144 Edge      adaptive_ts-irq

测试后:

130|console:/ # cat /proc/interrupts | grep adaptive                            

 72:         64          0          0          0          0          0          0          0  irq-ap-gpio 144 Edge      adaptive_ts-irq

2 测试时打开getevent,发现上层共接收到25个点(包含downup),39个中断报了25个点,少了14个。且发现第一个点跟第二个点之间间隔了150ms,余下各点间隔约10ms

console:/ # getevent -ltr

add device 1: /dev/input/event4

  name:     "madev"

add device 2: /dev/input/event0

  name:     "sprd-gpio-keys"

add device 3: /dev/input/event3

  name:     "sprdphone Headset Keyboard"

could not get driver version for /dev/input/mouse0, Not a typewriter

add device 4: /dev/input/event1

  name:     "adaptive_ts"

add device 5: /dev/input/event2

  name:     "sprdphone Headset Jack"

could not get driver version for /dev/input/mice, Not a typewriter

[     140.822618] /dev/input/event1: EV_ABS       ABS_MT_TRACKING_ID   00000001            

[     140.822618] /dev/input/event1: EV_ABS       ABS_MT_POSITION_X    00000086            

[     140.822618] /dev/input/event1: EV_ABS       ABS_MT_POSITION_Y    000001e3            

[     140.822618] /dev/input/event1: EV_KEY       BTN_TOUCH            DOWN                

[     140.822618] /dev/input/event1: EV_SYN       SYN_REPORT           00000000            

[     140.978920] /dev/input/event1: EV_ABS       ABS_MT_POSITION_X    0000008b            

[     140.978920] /dev/input/event1: EV_ABS       ABS_MT_POSITION_Y    000001e4            

[     140.978920] /dev/input/event1: EV_SYN       SYN_REPORT           00000000             rate 6

[     140.989623] /dev/input/event1: EV_ABS       ABS_MT_POSITION_X    0000008e            

[     140.989623] /dev/input/event1: EV_SYN       SYN_REPORT           00000000             rate 93

[     140.999986] /dev/input/event1: EV_ABS       ABS_MT_POSITION_X    00000092            

[     140.999986] /dev/input/event1: EV_ABS       ABS_MT_POSITION_Y    000001e5            

[     140.999986] /dev/input/event1: EV_SYN       SYN_REPORT           00000000             rate 9

3 我已经提前在代码中加了log,驱动中对于坐标不变的点是不上报的

static inline void ts_report_translate_key(struct ts_data *pdata,               

                       struct ts_point *cur, struct ts_point *last,             

                       bool *sync_abs, bool *sync_key, bool *btn_down)          

{                                                                               

        ......

        if (cur->pressed && last->pressed) {                                    

                if (cur->x == last->x && cur->y == last->y) {                   

                        if (!kc)                                                

                                *btn_down = true;

                        TS_ERR("point not move.x: %x, y: %x", cur->x, cur->y);                               

                        return;                                                 

                }                                 

        ......

}

检查kernel log,可以看到有14个点是没有坐标变化的

[  141.345235] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.355766] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.365858] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.376358] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.386825] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.397256] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.407664] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.417694] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.428542] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.438515] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.449385] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.459211] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.469548] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

[  141.480452] [TS] ts_report_translate_key() point not move.x: 86, y: 1e3

在我的机器上,Canda之前提到的protocol B是可以解释前两个事件间隔100ms的问题的。

但是并不是每次都是100ms,这完全取决于手指触摸TP时的快慢。100ms相对于人的反应时间并不是一个很长的时间,手指接触屏幕后稍作停顿就会导致有几个相同的坐标被检测到,并在中断中被丢弃

下面的是正常触摸,约40ms

[    4686.722633] /dev/input/event1: EV_ABS       ABS_MT_TRACKING_ID   00000007            

[    4686.722633] /dev/input/event1: EV_ABS       ABS_MT_POSITION_X    000001fe            

[    4686.722633] /dev/input/event1: EV_ABS       ABS_MT_POSITION_Y    00000239            

[    4686.722633] /dev/input/event1: EV_KEY       BTN_TOUCH            DOWN                

[    4686.722633] /dev/input/event1: EV_SYN       SYN_REPORT           00000000            

[    4686.764722] /dev/input/event1: EV_ABS       ABS_MT_POSITION_X    000001f9            

[    4686.764722] /dev/input/event1: EV_ABS       ABS_MT_POSITION_Y    00000237            

[    4686.764722] /dev/input/event1: EV_SYN       SYN_REPORT           00000000             rate 23

因涉及固件计算坐标的初始位置有部分耗时。在报点率为100HZ情况下,自容屏第一个点的中断上报时间稍长,不同器件厂商,差异不大,大概耗时65ms左右;互容屏39ms左右报第一中断。

comment内容:

move事件的产生条件:
  inputReader中是会有判断的,在获取down事件之后,获取的下一个事件的id与上一个事件的id相同时,会将当前事件当做move事件,也就是AMOTION_EVENT_ACTION_MOVE,

可以理解为两个事件在同一个轨迹上,第一个down事件之后的事件,到抬起up事件中间的事件,从inputdispatcher向上派发即为move事件。
  这个判断中间是不会有耗时。
 
如下判断代码:
5089    if (currentIdBits == lastIdBits) {
5090        if (!currentIdBits.isEmpty()) {
5091            // No pointer id changes so this is a move event.
5092            // The listener takes care of batching moves so we don't have to deal with that here.
5093            ALOGD_READER("dispatchTouches action MOVE now(ns): %lld",now);
5094            dispatchMotion(when, policyFlags, mSource,
5095                    AMOTION_EVENT_ACTION_MOVE, 0, 0, metaState, buttonState,
5096                    AMOTION_EVENT_EDGE_FLAG_NONE,
5097                    mCurrentCookedState.cookedPointerData.pointerProperties,
5098                    mCurrentCookedState.cookedPointerData.pointerCoords,
5099                    mCurrentCookedState.cookedPointerData.idToIndex,
5100                    currentIdBits, -1,
5101                    mOrientedXPrecision, mOrientedYPrecision, mDownTime);
5102        }

 
/*下面的事件分别是ABS_MT_TRACKING_ID(0x39), ABS_MT_POSITION_X(0x35), ABS_MT_POSITION_Y(0x36), BTN_TOUCH(0x14a) */
 
09-17 17:19:30.391 26699 26813 D InputReader: Input event: device=3 type=0x0003 code=0x0039 value=0x00000093 when=73681066665000
09-17 17:19:30.391 26699 26813 D InputReader: Input event: device=3 type=0x0003 code=0x0035 value=0x00000080 when=73681066665000
09-17 17:19:30.391 26699 26813 D InputReader: Input event: device=3 type=0x0003 code=0x0036 value=0x0000023d when=73681066665000
09-17 17:19:30.391 26699 26813 D InputReader: Input event: device=3 type=0x0001 code=0x014a value=0x00000001 when=73681066665000
09-17 17:19:30.391 26699 26813 D InputReader: Input event: device=3 type=0x0000 code=0x0000 value=0x00000000 when=73681066665000
09-17 17:19:30.391 26699 26813 D InputReader: dispatchTouches action DOWN now(ns): 73681067442373
 
//reader读到的时间就与down事件间隔100ms
09-17 17:19:30.487 26699 26813 D InputReader: Input event: device=3 type=0x0003 code=0x0035 value=0x0000008c when=73681163184000
09-17 17:19:30.487 26699 26813 D InputReader: Input event: device=3 type=0x0000 code=0x0000 value=0x00000000 when=73681163184000
09-17 17:19:30.487 26699 26813 D InputReader: dispatchTouches action MOVE now(ns): 73681163639527​
客户拒绝提供tp驱动代码,这里借助chipone_icn8318.c的代码

3、InputReader从EventHub 里面读取是坐标还是已经处理好的Down、Move 事件,这些Down、

     Move 事件是在哪里根据坐标合成事件?

EventHub通过getEvent读取驱动上报的数据struct input_event ,这个数据如下:

        

26struct input_event {
27      struct timeval time;
28      __u16 type;
29      __u16 code;
30      __s32 value;
31};

再经过InputReader中TouchInputMapper去合成down,move,up事件,事件的合成不是根据坐标判定的。

    down和up事件可以通过上报的值判断,该值根据协议规定判断,

    move事件是前一个down事件来之后,当前事件与前一个事件id相同会将该事件合成为move事件。

  • 2
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值