4. Reader thread _ Read events using Eventhub
Use INotify to monitor the creation and deletion of files under/dev/input
Use Epoll to monitor for data escalation
Details:
A, FD1 = Inotify_init ("/dev/input")
b, assuming that event0 and event1 are already in the input
FD2 = open ("/dev/input/event0")
Fd3= Open ("/dev/input/event1")
C, the use of epoll_wait monitoring fd1, FD2, fd3
D, if the data returned by Epoll_wait has FD1, indicates that a device node has been created or deleted, and if it is created, GetEvent creates a eawevent struct to represent the creation event, if FD2 or FD2, GetEvent will read the driver escalated Input_event event and use its construction eawevent to return
Reader threads: getting events, simple processing, passing to dispatcher threads
In Threadloop//inputreader.cpp
Mreader->looponce ()
Count = Meventhub->getevent ();//Get Event
Get Event Analysis:
Data for input events obtained by the application
struct eawevent{nsecs_t when;
int32_t DeviceID;
int32_t type;//Insert/unplug/Key class/Relative displacement class/absolute displacement class, etc.
int32_t Code;
int32_t value;
}
Data for input events reported by the driver
struct input_event{
struct Timeval;
__U16 type;
__U16 Code;
__S32 value;
}
So the application expands on the data that drives the output.
(Meventhub corresponds to the creation of Epoll and inotify to monitor when constructing)
Count = meventhub->getevent (int timeoutmillis,eawevent* buffer,size_tbuffersize)//inputreader.cpp
Scandeviceslocked ()//Scan Directory
Scandirlocked (Device_path)//scan "/dev/input"
Opendevicelocked (Devname)
loadconfigurationlocked (device)
loadkeymaplocked (device)
Device->keymap.load
adddevicelocked (device)
Createvirtualkeyboardlocked
Event->type = device_removed;
Event->type = device_added;
Eventltem = mpendingeventltems[mpendingeventindex++]
Deviceindex = Mdevices.indexofkey (eventItem.data.u32)
device* device = mdevice.valueat (Deviceindex)
Read (Device->fd,readbuffer ...)
Set Therawevent form Input_event
Epoll_wait (Mepollfd,mpendingeventitems,....)
5. Reader thread _ Core class and configuration file _ experiment
Reader thread Core class:
Meventhub Object
Mdevices objects are stored in each input device, storing the keyedvector< number,device*>
Device structure Information: Equipment FD (open (/dev/input/event) return) and information (Name/bus/vid/pid, which will open 3 profiles based on this information (Idc:input device config/keylayout: Keyboard layout/kcm:key Character Map), mapping information
Android input System Application layer key 1 with akeycode_1 = 8来, while in the Linux kernel key 1 is represented by the key_1=2, so there is a direct conversion between the two, using the keylayout is KL file to achieve, using the KL file is based on PID, VID, Device_name and other information to find a suitable xxxx.kl file
Experiment:
KL file Format:
Key + W
The code value in the kernel is the value in Android Akeycode_w
Create:
Su
Mkdir-p/data/system/devices/keylayout/
According to the DEVICE_NAME device name to find KL file, using the previously written application, in the program set up the Name=inputemulatorfrom100ask.net, where the. Number will be changed to _
Cp/system/usr/keylayout/generic.kl/data/system/devices/keylayout/inputemulatorfrom100ask_net.kl
Modify/DATA/SYSTEM/DEVICES/KEYLAYOUT/INPUTEMULATORFROM100ASK_NET.KL
Add these 2 lines:
Key 227 Star Star is represented on Android *
Key 228 POUND POUND on Android show #
Modify Permissions:
BusyBox chmod 777/data/system/devices-r
Restart
Su
BusyBox mount-t nfs-o nolock,vers=2 192.168.1.123:/work/nfs_root/data/mnt (mounts to/MNT will cause system card)
Insmod Inputemulator.ko
Send * key
SENDEVENT/DEV/INPUT/EVENT5 1 227 1
SENDEVENT/DEV/INPUT/EVENT5 1 227 0
SENDEVENT/DEV/INPUT/EVENT5 0 0 0
Send # Key
SENDEVENT/DEV/INPUT/EVENT5 1 228 1
SENDEVENT/DEV/INPUT/EVENT5 1 228 0
SENDEVENT/DEV/INPUT/EVENT5 0 0 0
Scancode ===> Android KeyCode simply means that a key has been pressed, such as linux227 for Star under Android, and that star represents the "*" character, as determined by Kcm:key Character Map, This KCM file is based on PID, VID, Device_name and other information to find a suitable xxxx.kcm file
KCM file Format:
Key B {
Label: ' B ' # The text printed on the key
Base: ' B ' # if there are no other keystrokes (SHIFT, CTRL, etc.) pressed at the same time, the corresponding character of this key is ' B '
Shift, CapsLock: ' B '
}
B means akeycode_b.
Experiment:
Mkdir-p/data/system/devices/keychars
cp/system/usr/keychars/generic.kcm/data/system/devices/keychars/inputemulatorfrom100ask_net.kcm
Modify:
Key STAR {
Label: ' * '
# Base: ' * '
Base: ' 1 '
}
Key POUND {
Label: ' # '
# Base: ' # '
Base: ' 2 '
}
BusyBox chmod 777/data/system/devices-r
Restart
Insmod Inputemulator.ko
Send * key, get 1
SENDEVENT/DEV/INPUT/EVENT5 1 227 1
SENDEVENT/DEV/INPUT/EVENT5 1 227 0
SENDEVENT/DEV/INPUT/EVENT5 0 0 0
Send # key to get 2
SENDEVENT/DEV/INPUT/EVENT5 1 228 1
SENDEVENT/DEV/INPUT/EVENT5 1 228 0
SENDEVENT/DEV/INPUT/EVENT5 0 0 0
Keylayout: Only used to indicate the driver escalation of the scancode corresponding to which Android button (akeycode_x)
Just means the button was pressed.
Which character it corresponds to, determined by the KCM file
KCM: Used to indicate which character the Android key (akeycode_x) corresponds to
Indicates which character corresponds to when another key is pressed at the same time
You can also use the combination key
SENDEVENT/DEV/INPUT/EVENT5 1 1 (shift+key_8)
SENDEVENT/DEV/INPUT/EVENT5 1 9 1
SENDEVENT/DEV/INPUT/EVENT5 1 9 0
SENDEVENT/DEV/INPUT/EVENT5 1 42 0
SENDEVENT/DEV/INPUT/EVENT5 0 0 0
SENDEVENT/DEV/INPUT/EVENT5 1 1 (shift+key_3)
SENDEVENT/DEV/INPUT/EVENT5 1 4 1
SENDEVENT/DEV/INPUT/EVENT5 1 4 0
SENDEVENT/DEV/INPUT/EVENT5 1 42 0
SENDEVENT/DEV/INPUT/EVENT5 0 0 0
6. Reader thread _ Core class and configuration file _ analysis
When Eventhub detects that a device node is created under/dev/input, it will open the device node, create the devices structure and load it onto the mdevices of the eventhub structure.
Members of the EVENTHUB structure:
{
mnextdeviceld:int32_t
Mdevices:keyedvector<int32_t,device*>
mopeningdevice:device*
mclosingdevice:device*
}
EventHub.cpp inside the opendevicelocked function:
(1) Open
(2) The IOCTL gets information: name, VID, PID, etc.
(3) New Device ()
(4) Load IDC file
(5) Loading KL and KCM files
Device struct Members:
{
Fd:int//=open ("/dev/input/event*")
Identifier:const inputdeviceidentifier//Properties: Name, bus, PID, vid, etc.
keybitmask[]:uint8_t
Configurationfile:string8//idc file name (XXX.IDC)
Configuration:propertymap*//IDC property, the value obtained from the IDC file
Keymap:keymap//Save Keylayout and KCM file information
}
Keymap Structural Body:
{
Keylayoutfile:string8//XXX.KL file name
keylayoutmap:sp<keylayoutmap>//XXX.KL File contents
Keycharactermapfile:string8//XXX.KL file name
keycharactermap;sp<keycharactermap>//XXX.KL File contents
}
Keylayoutmap Structural Body:
{
Mkeysbyscancode:keyedvector<int32_t,key>//int32_t is the kernel escalated Scancode,key is the struct {keycode (the corresponding value in Android); Flags}eg: <1,KEY{AKEYCODE_ESCAPE,flag}>/<2,KEY{AKEYCODE_1,flag}>, flag is mainly used for virtual keys, such as sliding on the keyboard to ignore escalation events
Mkeysbyusagecode:keyedvector<int32_t,key>
}
Keycharactermap Structural Body:
{
mkeys:keyedvector<int32_t,key*>//
int32_t is the corresponding value under Android, key is the struct {label, which does not work); Number;firstbehavior ()},firstbehavior is a behavior struct pointer, The base, shift, CapsLock (which is constructed outside of label) for each item in KCM constructs a behavior struct
{metaState (other keys pressed); character (the character of the value for Android); Fallbackkeycode};eg:base behavior{0, ' A ', Null},shift behavior{ Shift, "a", Null},capslock's Behavior{capslock, "a", null}
mkeysbyscancode:keyedvector<int32_t,int32_t>//function with the mkeysbyscancode:keyedvector in Keylayoutmap, no flag, Cannot handle virtual keys and seldom use this one
Mkeysbyusagecode:keyedvector<int32_t,int32_t>
}
Note: For each item inside the KCM file, if the value is Eg:ctrl fallback SEARCH, the Fallbackkeycode = Akeycode_search,fallbackkeycode for its behavior The role is when the report Ctrl + key character, if not unable to process, re-report a value Fallbackkeycode
7. Reader thread _ Simple processing
Processing based on the type of eawevent obtained
(1) ADD Device
(2) Remove Device
(3) Real input events
Processeventlocked (Meventbuffer,count)
Adddevicelocked (Rawevent->when,rawevent->deviceld)
InputDevice *device = createdevicelocked (Deviceld,...)
lnputdevice* device = new InputDevice (&mcontext,...)
Device->addmapper (New Keyboardinputmapper (Device,keyboardsource,keyboardtype))
Mdevices.add (Deviceid,device)//When a new input device is discovered, the device is not only added to the mdevices of Eventhub, but also to the inputreader of the mdevices structure. The Input_device structure is recorded in Inputreader's mdevices, with the data members having mid (which can be found from mdevices in Eventhub), Mmappers ( Handling escalated events with them)
Removedevicelocked (Rawevent->when,rawevent->deviceld)
Processeventsfordevicelocked (Deviceid,rawevent,batchsize)
Device->process (Rawevents,count)//device is the Input_device constructed at adddevice time.
inputmapper* mapper = mmappers[i]//finds the mapper of the corresponding event, and proxies it to process the data
Mapper->process (rawevent)
Geteventhub ()->mapkey (Getdeviceid (), Scancode,...) Convert the driver escalated Linux kernel layer code to the corresponding code in Android
Processkey
Notifykeyargs args (...) Use multiple data to construct args, then escalate the args data
Getlistener ()->notifykey (&args)//Notify a listener to process args, here listener must be dispatcher thread
Margsqueue.push (...)
Description: The Input_device structure under Mdevices in Inputreader is used to process the data
The device structure under Mdevices in Eventhub is used to read events to get data
Summarize:
Nativeinputmanager Structural Body
Inputreader Mreader
mreaderthread//threads, which provide only loops, are responsible for specific work by Mreader
Inputdispatcher Mdispatcher
mdispatcherthread//threads, which provide only loops, are responsible for specific work by Mdispatcher
Inputreader Structural Body
Eventhub meventhub//manages multiple input devices, and the device is saved in Mdevice
Mpolicy
InputDevice mdevices//also preserves the device, unlike the Mdevice in Eventhub, which provides mmapper input data processing functions
10.5 android Input System _reader Thread _ use Eventhub read event and core class and configuration file _ experiment _ Analysis