How modules are linked

As mentioned earlier, there are three types of modules:

Device-layer module

Responsible for communicating with a hardware or software device. It typically has no knowledge of the format of the data from the device; it's responsible only for getting data.

Protocol-layer module

Interprets the data it gets from a device module according to a specific protocol.

Filter module

Provides any further data manipulation common to a specific class of event bus.

Modules are linked together according to the command-line parameters passed into the input driver. The command line has the following format:

devi-driver_name [options] protocol [protocol_options]
    [device [device_options]] [filter [filter_options]]

In this example:

devi-hirun ps2 kb -2 &

the elements are as follows:

hirun

the "high-runner" input driver, which contains mouse and keyboard drivers used in most desktop systems.

ps2

specifies the PS/2 mouse protocol, a three-byte protocol indicating mouse movement and button states.

kb

specifies the kb device module, which can communicate with a standard PC 8042-type keyboard controller.

-2

specifies an option to the kb module, telling it to set up communication to its second (or auxiliary) port, which is for a PS/2 mouse.

You don't need to specify a filter module, because the three classes of event bus lines are represented by three modules, called rel, abs, and keyboard. When the input driver parses the command line, it can tell from the ps2 module that it needs to link in the rel filter-module. The only time you would explicitly specify a filter module on the command line is if you need to pass it optional command-line parameters. For example:

devi-hirun ps2 kb -2 rel -G2

This tells the relative filter module to multiply X and Y coordinates passed in by 2, effectively providing a gain factor (a faster-moving mouse).