linux/android--Input Subsystem input_event delivery

In the previous LINUX/ANDROID--USB touch screen driver-usbtouchscreen, how to add the input device type touchscreen driver to kernel is documented.

This is the most low-level device driver in the entire input system, the upper layer is the Linux kernel Management drive input system, kernel source location:/kernel/drivers/input/input.c

Writing is not easy, reprint need to indicate the source: http://blog.csdn.net/jscese/article/details/42099381

To the present has been fully tuned, can be used, and now record the time of contact with the Android input input system, first look at an online level map, pretty good:

The Usbtouchscreen in the previous blog is the location of the corresponding I²c module, while the core of input in kernel is input.c.

Input_dev:

This structure describes the information about an input device, and the usbtouch_probe in the Usbtouchscreen driver initializes Input_devas part of the Usbtouch device.

Will do a series of initialization of Input_dev, set parameters and so on, specifically refer to the previous blog

The INPUT_DEV structure is prototyped as follows, as defined in/kernel/include/linux/input.h:

/** * struct input_dev-represents an input device * @name: Name of the device * @phys: Physical path to the device in th E System Hierarchy * @uniq: Unique identification code for the device (if device has it) * @id: ID of the device (struct I NPUT_ID) * @propbit: Bitmap of device properties and quirks * @evbit: Bitmap of types of events supported by the device (E V_key, *ev_rel, etc.) * @keybit: Bitmap of Keys/buttons this device have * @relbit: bitmap of relative axes for the device * @absbit: Bitmap of a Bsolute axes for the device * @mscbit: Bitmap of miscellaneous events supported by the device * @ledbit: Bitmap of LEDs PR Esent on the device * @sndbit: Bitmap of sound effects supported by the device * @ffbit: Bitmap of force feedback effects Supported by the device * @swbit: Bitmap of switches present on the device * @hint_events_per_packet: Average number of EV Ents generated by the *device in a packet (between Ev_syn/syn_report events). Used by *event handlers to estimate size of thE buffer needed to the hold *events. * @keycodemax: Size of keycode table * @keycodesize: size of elements in keycode table * @keycode: Map of Scancodes to key Codes for the device * @getkeycode: Optional Legacy method to retrieve current keymap. * @setkeycode: Optional method to alter the KEYMAP, used to implement *sparse keymaps. If not supplied default mechanism would be used. *the method is being called when holding event_lock and thus must *not sleep * @ff: Force Feedback structure Associated W ITH the device if device *supports force feedback effects * @repeat_key: Stores key code of the last key pressed; Used to implement *software AutoRepeat * @timer: Timer for Software autorepeat * @rep: Current values for autorepeat param  Eters (delay, rate) * @mt: Pointer to array of structs Input_mt_slot holding current values *of tracked contacts * @mtsize: Number of MT Slots the device uses * @slot: MT slot currently being transmitted * @trkid: Stores MT tracking ID for the C urrent Contact * @absinfo: Array of &struct input_absinfo elements holding information *about absolute axes (current value, Min, Max, Flat, fuzz, *resolution) * @key: Reflects current state of device ' s keys/buttons * @led: Reflects current state of device ' S LEDs * @snd: Reflects current state's sound effects * @sw: Reflects current state of device ' s switches * @open: This Me Thod is called when the very first user calls *input_open_device ().  The driver must prepare the device *to start generating events (start polling thread, *request an IRQ, submit URB, etc.) * @close: This method was called when the very last user calls *input_close_device (). * @flush: Purges the device. Most commonly used to get rid of force *feedback effects loaded into the device when disconnecting *from it * @event: even T handler for events sent _to_ the device, like ev_led *or ev_snd. The device is expected-carry out of the requested *action (turn on a LEDs, play sound, etc) The call was protected *by @event_lock and must not Sleep * @grab: Input handle that currently have the device grabbed (via *eviocgrab ioctl). When a handle grabs a device it becomes sole *recipient for all input events coming from the device * @event_lock: this SP Inlock is was taken when input core receives *and processes a new event for the device (in Input_event ()).  *code that accesses and/or modifies parameters of a device * (such as keymap or Absmin, Absmax, Absfuzz, etc.) after device *has been registered with the input core must take the this lock. * @mutex: Serializes calls to open (), close () and flush () methods * @users: Stores number of users (input handlers) that O pened this *device.  It is used by Input_open_device () and Input_close_device () *to Make sure that Dev->open () are only called when the first *user opens device and Dev->close () is called when the very *last user closes the device * @going_away: Marks devices That is in a middle of unregistering and *causes input_open_device* () fail With-enodev. * @sync: Set to%true WHEn there were no new events since last Ev_syn * @dev: Driver model's view of this device * @h_list: List of input handles associated with the device. When *accessing the list Dev->mutex must is held * @node: used to place the device onto Input_dev_list */struct input_d EV {const char *name;const char *phys;const char *uniq;struct input_id id;unsigned long propbit[bits_to_longs (input_prop_ CNT)];unsigned long evbit[bits_to_longs (ev_cnt)];unsigned long keybit[bits_to_longs (key_cnt)];unsigned long relbit[ Bits_to_longs (rel_cnt)];unsigned long absbit[bits_to_longs (abs_cnt)];unsigned long mscbit[bits_to_longs (MSC_CNT)]; unsigned long ledbit[bits_to_longs (led_cnt)];unsigned long sndbit[bits_to_longs (snd_cnt)];unsigned long Ffbit[bits_ To_longs (ff_cnt)];unsigned long swbit[bits_to_longs (sw_cnt)];unsigned int hint_events_per_packet;unsigned int keycodemax;unsigned int keycodesize;void *keycode;int (*setkeycode) (struct Input_dev *dev, const struct INPUT_KEYMAP_ Entry *ke, unsigned int *old_keycoDE); Int (*getkeycode) (struct Input_dev *dev, struct input_keymap_entry *ke); struct Ff_device *ff;unsigned int Repeat_key ; struct timer_list timer;int rep[rep_cnt];struct input_mt_slot *mt;int mtsize;int slot;int trkid;struct input_absinfo * absinfo;unsigned long Key[bits_to_longs (key_cnt)];unsigned long led[bits_to_longs (led_cnt)];unsigned long snd[BITS_ To_longs (snd_cnt)];unsigned long sw[bits_to_longs (sw_cnt)];int (*open) (struct input_dev *dev); void (*close) (struct Input_dev *dev); int (*flush) (struct Input_dev *dev, struct file *file); int (*event) (struct Input_dev *dev, unsigned int ty PE, unsigned int code, int value), struct Input_handle __rcu *grab;spinlock_t event_lock;struct Mutex mutex;unsigned int US Ers;bool going_away;bool sync;struct device dev;struct list_headh_list;struct list_headnode;};

My explanation may also be misleading, the source of the comments above is the best explanation, is to describe a input device related information.

Each input device needs to initialize a INPUT_DEV structure to describe some of the features of this device, and then register it with Input_register_device on the device bus for subsequent use

You can go to the system running directory under /proc/bus/input cat devices to view the registered input device on the bus

Input_event:

The device driver section is passed up to the triggering event, and in the case of Usbtouchscreen, the callback function is:

/***************************************************************************** * Generic part */static void Usbtouch _PROCESS_PKT (struct Usbtouch_usb *usbtouch, unsigned char *pkt, int len) {struct Usbtou     Ch_device_info *type = usbtouch->type;    if (!type->read_data (Usbtouch, PKT)) return; Input_report_key (Usbtouch->input, Btn_touch, Usbtouch->touch); Escalate touch type.        Touch is pressed if (swap_xy) {input_report_abs (Usbtouch->input, abs_x, usbtouch->y);    Input_report_abs (Usbtouch->input, abs_y, usbtouch->x);        } else {input_report_abs (usbtouch->input, abs_x, usbtouch->x); Input_report_abs (Usbtouch->input, abs_y, usbtouch->y);    Escalation absolute Coordinate value} if (type->max_press) input_report_abs (Usbtouch->input, Abs_pressure, usbtouch->press);   Input_sync (Usbtouch->input); Synchronous Operation}

You can see the escalation of events through input_report_* to Input.c, which is the Arrow 9 in the above hierarchy, initially in/kernel/include/linux/input.h:

static inline void Input_report_key (struct input_dev *dev, unsigned int code, int value) {input_event (dev, ev_key, code,!!) value);} static inline void Input_report_rel (struct input_dev *dev, unsigned int code, int value) {input_event (dev, Ev_rel, code, VA Lue);} static inline void Input_report_abs (struct input_dev *dev, unsigned int code, int value) {input_event (dev, ev_abs, code, VA Lue);}

Can see the different report are called into the input_event, but the transfer of the parameters of different, the next thing is all left to input.c to do!

/** * Input_event ()-Report New input event * @dev: Device that generated the event * @type: Type of the event * @code: E  Vent code * @value: Value of the event * * This function should is used by drivers implementing various input * devices to Report input events. See also Input_inject_event (). * * Note:input_event () May is safely used right after input device is * allocated with input_allocate_device (), even BEF Ore it is registered * with Input_register_device (), but the event would not reach any of the * input handlers.  Such early invocation of Input_event () May is used * to ' seed ' initial state of a switch or initial position of absolute * Axis, etc. */void input_event (struct Input_dev *dev, unsigned int type, unsigned int code, int value) {Unsigne    D long Flags; if (is_event_supported (type, dev->evbit, Ev_max)) {//determines if it is the event type at the time of registration, the event type is set when the Input_dev is registered when driving probe Spin_ Lock_irqsave (&dev->event_lock, flags); Spin lock Yoke add_input_randomness (type,code, value);  Input_handle_event (dev, type, code, value); Further processing of the transmitted event Spin_unlock_irqrestore (&dev->event_lock, flags);//Unlock}}

You can see here the first is filtering the event type, which is also initialized in the probe in Usbtouchscreen!

There are several types:

/* * Event types */#define Ev_syn0x00#define ev_key0x01#define ev_rel0x02#define ev_abs0x03#define ev_msc0x04#define EV_ Sw0x05#define ev_led0x11#define ev_snd0x12#define ev_rep0x14#define ev_ff0x15#define EV_PWR0x16#define EV_FF_ Status0x17#define ev_max0x1f#define ev_cnt (ev_max+1)

Input_handle_event:

The input_event is transferred into this handle processing by the above. This will be categorized according to type:

static void Input_handle_event (struct input_dev *dev, unsigned int type, unsigned int code, int value) { int disposition = input_ignore_event; Initial to do not process switch (type) {case Ev_syn:switch (code) {Case syn_config:disposition = INPUT            _pass_to_all;        Break                Case Syn_report:if (!dev->sync) {Dev->sync = true;            disposition = input_pass_to_handlers; } break, ... case ev_key:if (is_event_supported (Code, Dev->keybit, Key_max) &&//Key code Supported by Keybit!! Test_bit (code, DEV->KEY)! = value) {//key is the keyboard current all key state, test code corresponding key state, value transmitted the key state of the event.  This sentence indicates that the key state should change if (value! = 2) {__change_bit (code, Dev->key);                Change the value of key to change the key state.  if (value) input_start_autorepeat (dev, code); If the key value is pressed, the key operation starts again.                Specific will not repeat, Input_start_autorepeat will also be based on evbit in the case of duplicate events and other judgments.              Else      Input_stop_autorepeat (Dev);            If you release the button, you should stop repeating the key operation.        } disposition = Input_pass_to_handlers;            } break, ... case ev_abs:if (is_event_supported (Code, Dev->absbit, Abs_max)//same as above to see if support is supported  disposition = input_handle_abs_event (dev, code, &value); This function can be followed up to see, is to be filtered, the first time is not to return to the input_ignore_event, after the same time if there is the same ABS coordinates will be filtered out, return ignore//err ("Jscese display disposition V        Lue ==0x%x,code==0x%x, value== 0x%x\n ", disposition,code,value);    Break, ...}    if (disposition! = input_ignore_event && Type! = Ev_syn) Dev->sync = false;     if ((Disposition & Input_pass_to_device) && dev->event) dev->event (dev, type, code, value);  if (disposition & input_pass_to_handlers) input_pass_event (dev, type, code, value); A deeper call, and ultimately a call to the event (* *) method}

This first records the entire input system from the device driver to the upper layer of the relationship, as well as from the driver calls in the kernel to the input system in the transfer process, although see called input.c in some of the functions passed, but to the input core is still not much concept,

The next chapter of the analysis of input this core module ~

linux/android--Input Subsystem input_event delivery