Documentation/input/input-programming.rst

Source file repositories/reference/linux-study-clean/Documentation/input/input-programming.rst

File Facts

System
Linux kernel
Corpus path
Documentation/input/input-programming.rst
Extension
.rst
Size
13653 bytes
Lines
368
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: exported/initcall integration point
Status
integration implementation candidate

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

module_init(button_init);
    module_exit(button_exit);

What the example does
~~~~~~~~~~~~~~~~~~~~~

First it has to include the <linux/input.h> file, which interfaces to the
input subsystem. This provides all the definitions needed.

In the _init function, which is called either upon module load or when
booting the kernel, it grabs the required resources (it should also check
for the presence of the device).

Then it allocates a new input device structure with input_allocate_device()
and sets up input bitfields. This way the device driver tells the other
parts of the input systems what it is - what events can be generated or
accepted by this input device. Our example device can only generate EV_KEY
type events, and from those only BTN_0 event code. Thus we only set these
two bits. We could have used::

	set_bit(EV_KEY, button_dev->evbit);
	set_bit(BTN_0, button_dev->keybit);

as well, but with more than single bits the first approach tends to be
shorter.

Then the example driver registers the input device structure by calling::

	input_register_device(button_dev);

This adds the button_dev structure to linked lists of the input driver and
calls device handler modules _connect functions to tell them a new input
device has appeared. input_register_device() may sleep and therefore must
not be called from an interrupt or with a spinlock held.

While in use, the only used function of the driver is::

	button_interrupt()

which upon every interrupt from the button checks its state and reports it
via the::

	input_report_key()

call to the input system. There is no need to check whether the interrupt
routine isn't reporting two same value events (press, press for example) to
the input system, because the input_report_* functions check that
themselves.

Then there is the::

	input_sync()

call to tell those who receive the events that we've sent a complete report.
This doesn't seem important in the one button case, but is quite important
for example for mouse movement, where you don't want the X and Y values
to be interpreted separately, because that'd result in a different movement.

dev->open() and dev->close()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In case the driver has to repeatedly poll the device, because it doesn't
have an interrupt coming from it and the polling is too expensive to be done
all the time, or if the device uses a valuable resource (e.g. interrupt), it
can use the open and close callback to know when it can stop polling or
release the interrupt and when it must resume polling or grab the interrupt
again. To do that, we would add this to our example driver::

    static int button_open(struct input_dev *dev)
    {

Annotation

Implementation Notes