Input: convert input-programming doc into ReST format

~~~~~~~~~~~~~~~~~~~~~~~~~

Programming input drivers

Programming input drivers

~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~

1. Creating an input device driver

Creating an input device driver

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============================

1.0 The simplest example

The simplest example

~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~

Here comes a very simple example of an input device driver. The device has

Here comes a very simple example of an input device driver. The device has

just one button and the button is accessible at i/o port BUTTON_PORT. When

just one button and the button is accessible at i/o port BUTTON_PORT. When

pressed or released a BUTTON_IRQ happens. The driver could look like:

pressed or released a BUTTON_IRQ happens. The driver could look like::

    #include <linux/input.h>

    #include <linux/input.h>

    #include <linux/module.h>

    #include <linux/module.h>

    module_init(button_init);

    module_init(button_init);

    module_exit(button_exit);

    module_exit(button_exit);

1.1 What the example does

What the example does

~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~

First it has to include the <linux/input.h> file, which interfaces to the

First it has to include the <linux/input.h> file, which interfaces to the

input subsystem. This provides all the definitions needed.

input subsystem. This provides all the definitions needed.

parts of the input systems what it is - what events can be generated or

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

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

type events, and from those only BTN_0 event code. Thus we only set these

two bits. We could have used

two bits. We could have used::

	set_bit(EV_KEY, button_dev.evbit);

	set_bit(EV_KEY, button_dev.evbit);

	set_bit(BTN_0, button_dev.keybit);

	set_bit(BTN_0, button_dev.keybit);

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

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

shorter.

shorter.

Then the example driver registers the input device structure by calling

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

	input_register_device(&button_dev);

	input_register_device(&button_dev);

device has appeared. input_register_device() may sleep and therefore must

device has appeared. input_register_device() may sleep and therefore must

not be called from an interrupt or with a spinlock held.

not be called from an interrupt or with a spinlock held.

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

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

	button_interrupt()

	button_interrupt()

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

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

via the

via the::

	input_report_key()

	input_report_key()

the input system, because the input_report_* functions check that

the input system, because the input_report_* functions check that

themselves.

themselves.

Then there is the

Then there is the::

	input_sync()

	input_sync()

for for example mouse movement, where you don't want the X and Y values

for for example mouse movement, where you don't want the X and Y values

to be interpreted separately, because that'd result in a different movement.

to be interpreted separately, because that'd result in a different movement.

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

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In case the driver has to repeatedly poll the device, because it doesn't

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

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 (eg. interrupt), it

all the time, or if the device uses a valuable resource (eg. interrupt), it

can use the open and close callback to know when it can stop polling or

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

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:

again. To do that, we would add this to our example driver::

    static int button_open(struct input_dev *dev)

    static int button_open(struct input_dev *dev)

    {

    {

The open() callback should return a 0 in case of success or any nonzero value

The open() callback should return a 0 in case of success or any nonzero value

in case of failure. The close() callback (which is void) must always succeed.

in case of failure. The close() callback (which is void) must always succeed.

1.3 Basic event types

Basic event types

~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~

The most simple event type is EV_KEY, which is used for keys and buttons.

The most simple event type is EV_KEY, which is used for keys and buttons.

It's reported to the input system via:

It's reported to the input system via::

	input_report_key(struct input_dev *dev, int code, int value)

	input_report_key(struct input_dev *dev, int code, int value)

absolute coordinate systems.

absolute coordinate systems.

Having the device report EV_REL buttons is as simple as with EV_KEY, simply

Having the device report EV_REL buttons is as simple as with EV_KEY, simply

set the corresponding bits and call the

set the corresponding bits and call the::

	input_report_rel(struct input_dev *dev, int code, int value)

	input_report_rel(struct input_dev *dev, int code, int value)

However EV_ABS requires a little special care. Before calling

However EV_ABS requires a little special care. Before calling

input_register_device, you have to fill additional fields in the input_dev

input_register_device, you have to fill additional fields in the input_dev

struct for each absolute axis your device has. If our button device had also

struct for each absolute axis your device has. If our button device had also

the ABS_X axis:

the ABS_X axis::

	button_dev.absmin[ABS_X] = 0;

	button_dev.absmin[ABS_X] = 0;

	button_dev.absmax[ABS_X] = 255;

	button_dev.absmax[ABS_X] = 255;

	button_dev.absfuzz[ABS_X] = 4;

	button_dev.absfuzz[ABS_X] = 4;

	button_dev.absflat[ABS_X] = 8;

	button_dev.absflat[ABS_X] = 8;

Or, you can just say:

Or, you can just say::

	input_set_abs_params(button_dev, ABS_X, 0, 255, 4, 8);

	input_set_abs_params(button_dev, ABS_X, 0, 255, 4, 8);

that the thing is precise and always returns to exactly the center position

that the thing is precise and always returns to exactly the center position

(if it has any).

(if it has any).

1.4 BITS_TO_LONGS(), BIT_WORD(), BIT_MASK()

BITS_TO_LONGS(), BIT_WORD(), BIT_MASK()

~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

These three macros from bitops.h help some bitfield computations:

These three macros from bitops.h help some bitfield computations::

	BITS_TO_LONGS(x) - returns the length of a bitfield array in longs for

	BITS_TO_LONGS(x) - returns the length of a bitfield array in longs for

			   x bits

			   x bits

	BIT_WORD(x)	 - returns the index in the array in longs for bit x

	BIT_WORD(x)	 - returns the index in the array in longs for bit x

	BIT_MASK(x)	 - returns the index in a long for bit x

	BIT_MASK(x)	 - returns the index in a long for bit x

1.5 The id* and name fields

The id* and name fields

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~

The dev->name should be set before registering the input device by the input

The dev->name should be set before registering the input device by the input

device driver. It's a string like 'Generic button device' containing a

device driver. It's a string like 'Generic button device' containing a

The id and name fields can be passed to userland via the evdev interface.

The id and name fields can be passed to userland via the evdev interface.

1.6 The keycode, keycodemax, keycodesize fields

The keycode, keycodemax, keycodesize fields

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

These three fields should be used by input devices that have dense keymaps.

These three fields should be used by input devices that have dense keymaps.

The keycode is an array used to map from scancodes to input system keycodes.

The keycode is an array used to map from scancodes to input system keycodes.

rely on kernel's default implementation of setting and querying keycode

rely on kernel's default implementation of setting and querying keycode

mappings.

mappings.

1.7 dev->getkeycode() and dev->setkeycode()

dev->getkeycode() and dev->setkeycode()

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

getkeycode() and setkeycode() callbacks allow drivers to override default

getkeycode() and setkeycode() callbacks allow drivers to override default

keycode/keycodesize/keycodemax mapping mechanism provided by input core

keycode/keycodesize/keycodemax mapping mechanism provided by input core

and implement sparse keycode maps.

and implement sparse keycode maps.

1.8 Key autorepeat

Key autorepeat

~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~

... is simple. It is handled by the input.c module. Hardware autorepeat is

... is simple. It is handled by the input.c module. Hardware autorepeat is

not used, because it's not present in many devices and even where it is

not used, because it's not present in many devices and even where it is

autorepeat for your device, just set EV_REP in dev->evbit. All will be

autorepeat for your device, just set EV_REP in dev->evbit. All will be

handled by the input system.

handled by the input system.

1.9 Other event types, handling output events

Other event types, handling output events

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The other event types up to now are:

The other event types up to now are:

EV_LED - used for the keyboard LEDs.

- EV_LED - used for the keyboard LEDs.

EV_SND - used for keyboard beeps.

- EV_SND - used for keyboard beeps.

They are very similar to for example key events, but they go in the other

They are very similar to for example key events, but they go in the other

direction - from the system to the input device driver. If your input device

direction - from the system to the input device driver. If your input device

driver can handle these events, it has to set the respective bits in evbit,

driver can handle these events, it has to set the respective bits in evbit,

*and* also the callback routine:

*and* also the callback routine::

    button_dev->event = button_event;

    button_dev->event = button_event;

int button_event(struct input_dev *dev, unsigned int type, unsigned int code, int value);

    int button_event(struct input_dev *dev, unsigned int type,

		     unsigned int code, int value)

    {

    {

	    if (type == EV_SND && code == SND_BELL) {

	    if (type == EV_SND && code == SND_BELL) {

		    outb(value, BUTTON_BELL);

		    outb(value, BUTTON_BELL);