Some of the input devices previously written were driven by a character device. The problem is that the great gods of the Linux open source community see this large number of input devices so fragmented, there is a mechanism for the wood to achieve a decentralized, different types of input devices unified drive, so the input subsystem appears.
Benefits of input Subsystem Introduction:
(1) Unify the processing functions of similar input devices with different physical forms. For example, various mice, whether PS/2, USB, or Bluetooth, are treated the same.
(2) provides a simple event interface for distributing input reports to user applications. Your driver does not have to create, manage/dev nodes, and associated access methods. It is therefore convenient to invoke the input API to send mouse movements, keyboard keys, or touch events to user space. Applications such as Windows X can seamlessly run on the event interface provided by the input subsystem.
(3) The general part of the input driver is extracted, and the driver is simplified and the consistency is provided. For example, the input subsystem provides a collection of low-level drivers (becoming Serio) that support access to hardware inputs such as serial ports and keyboard controllers.
The subsystem consists of two types of drives that run after the previous one: input event driver and input device driver.
Input event-driven interface for the responsible and application;
The input device driver is responsible for communication with the underlying input device.
Both input event-driven and input-device drivers can leverage the efficient, reusable core of the input subsystem for the services provided.
What we need to achieve is input device driver.
First, in the Linux kernel source code drivers/input.c is the input subsystem, its file_operation only one open function. In the open function, the file_operation structure is re-specified, which realizes read, write and other functions.
Linux Embedded Drive Learning Path (16) input Subsystem