TP sequence(msm zinitix)

1.      TP

1.1 In zt7554ic,0x0080 is STATUS_REG.0x0082-0x00a5 per three ADDR is a point info.

1.2 eg.Hera  SUPPORTED_FINGER_NUM  5

While three points down , there will be point 0,1,2.

Then the point 1 up , there will be point 0,2.

Then another point down , there will be point 0,1,2 not 0,2,3

1.3 While atouch event is produced , the Interrupt pin is controlled to be low.

And the IC will check the status whether have been read.

If no , wait and no touch event.

Driver send commnd to ic to clear status after read coord info, andthe int pin is to be high .

 

2.DRIVER(coord info)

2.1  Driver read coord info fromzt7554 ic by i2c,send coord info to android by Input system.

2.2  Interrupt handler: the driveruse request_threaded_irq to request irq(IRQF_TRIGGER_FALLING | IRQF_ONESHOT)

2.3     Driver read a struct  _ts_zinitix_point_info from ic .If aICON_EVENT , driver will read a 16bit info from ic to the icon_event_reg.

    If a ICON_EVENT , driver will test  the icon_event_reg every bit as one bit meansone icon event . If a bit is tested to be 1 , report the corresponding key inthe BUTTON_MAPPING_KEY .

    If a PT_EVENT , driver will test thesub_status in a for loop . If a sub_status is tested to be SUB_BIT_EXIST ,report the touch point coord info by SLOT protocol (slot equal to thepoint  identified by the IC ).

 

 

3.Input core(Input system)

Driver layer isrelated to hardware , directly capture and obtain the data of the hardware ofthe information (including the touch screen is pressed, press the location,mouse, keyboard, press, etc.) . Then the data information report to the corelayer.Core layer is responsible for the connection driver layer and eventprocessing . the registration of  devicedriver and handler   needs to be donethrough core layer . Core layer receives data from the driver layer , andselect the corresponding handler to process the data information .  The final handler copies data to user space.

TP report inputevents include EV_SLOT and EV_KEY.

 

4.      ANDROID

4.1  Module function

4.1.1         EventHub

It is the central treatment station of all the events in the system. It manages all input events of the system can identify the input device . Inaddition, when adding or removing equipment, EventHub will generate thecorresponding input event to the system.

EventHub provide an input stream for the system by getEvents function . It also supports the query thecurrent state of the input device (e.g., which key is pressed current).AndEventHub also track  each input intoability, such as input equipment category, what key input device support.

4.1.2         InputReader

InputReader load from EventHub InputReader raw event data , andprocessed by each InputMapper after input the corresponding input to thelistener . InputReader have a InputMapper collection.It completed most of thework  in InputReader thread .  But InputReader can accept any thread of thequery.For manageability, InputReader using a simple Mutex to protect it's state. InputReader has an EventHub object, but the object is not created by it, butas a parameter when creating InputReader incoming.

4.1.3 InputDispatcher

InputDispatcher distribute the event to enter the target  theevent, some of these functions (such as identification input target) iscontrolled by independent policy object.

4.1.4 InputManager

InputManager is the core of the event handling system , although itdoes not do specific things, but still to do management work, such as acceptour customer's complaints and claims, or the boss out of the barrel.

InputManager using two threads:

1) InputReaderThread called "InputReader" thread, it isresponsible for reading and preprocessing RawEvent, applies the policy and senda message to DispatcherThead queue management.

2) InputDispatcherThread called "InputDispatcher" thread,it on the queue waiting for the new input events, and asynchronously todistribute these events to the application.

InputReaderThread classes and InputDispatcherThread don't share theinternal states, all communication is one-way, from InputReaderThread toInputDispatcherThread.Two classes can be InputDispatchPolicy interact.

InputManager class never interact with Java, but InputDispatchPolicyresponsible for performing all interactions with external of the system,including the call DVM business.       

 

4.2 briefprocess

WindowManagerService through InputManager provided interfaces toopen a thread driver InputReader constantly read eventfrom/dev/input/directories below device file , and then distributed to theclient connect  to WindowManagerServiceservice through InputDispatcher . InputReader read  RawEvent from the device file, before to InputDispatcher for distribution, itneeds to transform RawEvent for classification, split into KeyEvent,MotionEvent, TrackEvent various types, etc.

 

4.3 keylayout

Android through EventHub constant reading kernel input report EV_KEY* event , then according to the key layout file converts it into KEYCODE_ *event .

The Linux kernel on the definition of keyevents in the kernel/include/Linux/input. h file , such as :

 define KEY_UP , 103

The android source code about thedefinition of KEYCODE events in frameworks/base/core/Java/android/view/KeyEvent.java file, such as:

 Public static final ints KEYCODE_VOLUME_UP =24 ;

Note : that compose button handler on theAndroid platform , the use of the general is KEYCODE_ * yards .

Keylayout file suffix for *.Kl , thesefiles in the android source device/$(company)/$(board)/(eg.device/mitac/hera/)directory .

Of course , we also can directly toonline  pull down *. Kl file from themachine , push up again after modification . The path is thesystem/usr/keylayout/directory .

For example , convert the kernel KEY_UPevent into KEYCODE_VOLNUME_UP events , you can write keylayout file , thecontent is as follows :

The key 103 VOLUME_UP WAKE