Inputmapper Treatment of Linux/android--input system (eight)

The Inputreader of the former Linux/android--input System (vii) introduces the operation flow of Inputreader, how to get the events to the preliminary distribution, then analyze to Inputmapper to do the first step of processing.

The previous article has resolved the mapper type of dependency rules, do not restate. Here is an example of a touch screen input_device corresponding singletouchinputmapper.

Writing is not easy, reprint need to indicate the source: http://blog.csdn.net/jscese/article/details/43561773 This blog from the "Jscese" of blogs!

Singletouchinputmapper:

The prototype is defined in InputReader.h:

Class Singletouchinputmapper:public Touchinputmapper {public:    singletouchinputmapper (inputdevice* device);    Virtual ~singletouchinputmapper ();    virtual void Reset (nsecs_t when);    virtual void process (const rawevent* rawevent);p rotected:    virtual void Synctouch (nsecs_t when, bool* Outhavepointerids);    virtual void configurerawpointeraxes ();    virtual bool Hasstylus () Const;private:    singletouchmotionaccumulator msingletouchmotionaccumulator;};

Inherited from the Touchinputmapper, the function implementation is all placed in the InputReader.cpp, first look at the first call into the process:

void Singletouchinputmapper::p rocess (const rawevent* rawevent) {    touchinputmapper::p rocess (rawevent);  Call the parent class of process    msingletouchmotionaccumulator.process (rawevent);  Synchronization of Data}

Continue with:

void Touchinputmapper::p rocess (const rawevent* rawevent) {    mcursorbuttonaccumulator.process (rawevent);    Mcursorscrollaccumulator.process (rawevent);    Mtouchbuttonaccumulator.process (rawevent);   These three accumulator further process the rawevent, the prototypes are in InputReader.cpp, and the corresponding information is extracted according to Rawevent->code    ALOGW ("Jscese DSP Touchinputmapper::p rocess event type==0x%x, code==0x%x, valude ==0x%x \ n ", Rawevent->type,rawevent->code, Rawevent->value);    if (Rawevent->type = = Ev_syn && Rawevent->code = = syn_report) {        sync (rawevent->when);//Sync    }}

Several of the above process are interested to see, will be in turn according to the code type to extract the corresponding information to save, such as Cursormotionaccumulator in the Mrelx, mrely represents the relative coordinate values

As a touch box I debug, this is the only touchbuttonaccumulator that Btn_touch a pressed or raised event value. abs_x. Abs_y is not read here. But in the back of the singletouchmotionaccumulator::p rocess .

The other input devices need to look at the code type that drives the specific escalation.

Touchinputmapper::sync:

From the above analysis can be seen. When a rawevent comes over, it will go through three process to extract the information before it detects if it is a synchronous sync raweent event.

This is why in the driver a complete event escalation, always first report some button res abs and the like, and finally a sync!

This synchronization function is relatively long only a few places to pay attention to:

void Touchinputmapper::sync (nsecs_t when) {ALOGW ("Touchinputmapper::sync");    Sync button state. Mcurrentbuttonstate = Mtouchbuttonaccumulator.getbuttonstate () |    Mcursorbuttonaccumulator.getbuttonstate ();    Sync Scroll State ....//Sync Touch State.    bool Havepointerids = true;    Mcurrentrawpointerdata.clear (); Synctouch (when, &havepointerids);//Call a subclass of Synctouch, here naturally call the singletouchmotionaccumulator of my Touch box Synctouch, update abs    Coordinate values, I'm here to put the data into mcurrentrawpointerdata for Cook ...//Reset state so we'll compute below.    Mcurrentfingeridbits.clear ();    Mcurrentstylusidbits.clear ();    Mcurrentmouseidbits.clear ();   Mcurrentcookedpointerdata.clear ();  First clear out ...//Cook pointer data. This call populates the MCURRENTCOOKEDPOINTERDATA structure//with cooked pointer data which has the same IDs and I        Ndices as the raw data.        The following code can use either the raw or cooked data, as needed.  Cookpointerdata (); This function does not follow, too pangBig, cook data, mostly generated Mcurrentcookedpointerdata.pointercoords,mcurrentcookedpointerdata.pointerproperties and Mcurrentcookedpointerdata.idtoindex  ... dispatchtouches (when, policyflags); To distribute ...//some operations such as data saving}

The normal handling here is to call the dispatchtouches function, and go inside is dispatchmotion:

void Touchinputmapper::d ispatchmotion (nsecs_t when, uint32_t policyflags, uint32_t Source, int32_t        action, int32_t Flags, int32_t metaState, int32_t buttonstate, int32_t edgeflags,        const pointerproperties* Properties, const pointercoords* coords,        const uint32_t* Idtoindex, BitSet32 idbits,        int32_t changedid, float xprecision, float Yprecision, nsecs_t downtime) {    pointercoords pointercoords[max_pointers];    Pointerproperties Pointerproperties[max_pointers];    uint32_t pointercount = 0;    .. Getlistener ()->notifymotion (&args);  Callback

This is the signeltouch of the walk, so eventually it will call Getlistener ()->notifymotion (&args), if it is a KeyDown event. Depending on the logic above, calling Synthesizebuttonkeys before Cookpointerdata calls to Context->getlistener ()->notifykey in turn ( &args);

Queuedinputlistener:

The above analysis of the notifymotion will eventually call into this class, this as the final handover maintenance class Inputreader link, review the construction of Inputread, you can look at:

---inputreader---inputreader::inputreader (const sp<eventhubinterface>& Eventhub,        const sp< inputreaderpolicyinterface>& policy,        Const sp<inputlistenerinterface>& Listener)   // Note here the last parameter ~ ... {    Mqueuedlistener = new Queuedinputlistener (listener);//Constructs a queuedinputlistener ...}

Here again we look at the first construct called/frameworks/base/services/input/inputmanager.cpp:

Inputmanager::inputmanager (    ... Mdispatcher = new Inputdispatcher (dispatcherpolicy);    Mreader = new Inputreader (Eventhub, Readerpolicy, mdispatcher);  You can see that the incoming is inputdispatcher, but the above directly with the Inputlistenerinterface, directly cast to the parent class pointer!  Notice here ...}

So when constructing queuedinputlistener in Inputreader, the parent pointer of Inputdispatcher is saved in the private member Minnerlistener

---queuedinputlistener---queuedinputlistener::queuedinputlistener (const sp<inputlistenerinterface>& Innerlistener):        Minnerlistener (Innerlistener) {}

Why doing this is a pure virtual function that should be called for subsequent calls. will be passed to the Inputdispatcher function. Implementation of a pass, C + + is like this, to see the whole. Just know where the designer's code went.

Go down the analysis process and you'll know why I said that.

Back in front, call queuedinputlistener::notifymotion, push this notifymotion into the margsqueue list queue, and then looponce ( the Mqueuedlistener->flush () will be called after the acquisition of the above event and distribution processing.

void Queuedinputlistener::flush () {    size_t count = Margsqueue.size ();    for (size_t i = 0; i < count; i++) {        notifyargs* args = margsqueue[i];        Args->notify (Minnerlistener);  Here, in turn, the Notify function of the different kinds of notify, called the above push, Notifyconfigurationchangedargs/  Notifykeyargs/notifymotionargs/ Notifyswitchargs/notifydeviceresetargs These kinds of        delete args;    }    Margsqueue.clear ();}

Here's an example of the notifymotion I do:

void notifymotionargs::notify (const sp<inputlistenerinterface>& Listener) Const {    listener-> Notifymotion (this);}

here it is. Another notifymotion call, this pure virtual function, two sub-class Queuedinputlistener Inputdispatcher are implemented, as the above analysis, the final call to Inputdispatcher In the Notifymotion!

After that, it's inputdispatcher, and it's not going to work. Follow up and say ~

Inputmapper Treatment of Linux/android--input system (eight)