Specifications

CHAPTER 4. DESIGN AND ARCHITECTURE 25
Figure 4.3 shows the modular input interface. Incoming input events are shown as dotted
arrows on the left of the figure. Input events are reported to the various kernel input device
drivers that provide a user space interface (shown as “Input Interface”). Each module (“IAL
Module”) is responsible for one input interface. The execution of the module is controlled
by the event loop of the Input Abstraction Layer. The modules report occurring events to
the output interface using a function provided by the daemon. The dotted arrows on the
right indicate the subsequent event flow to user space applications, which are using the Input
Abstraction Layer’s output interface.
Input Interface
Input Interface
Kernel Space Input Abstraction Layer (User Space)
Output Interface
Device Driver
Device Driver
IAL Module
Event Loop
IAL Module
Figure 4.3: Modular Input Interface
4.4 Abstract Output Interface
Input events received by the modules are reported using the daemon’s output interface. The
actual abstraction is done by the modules—not by the daemon. A module translates concrete
events read from the kernel drivers’ interface to abstract events. These abstract events are sent
to the abstract output interface provided by the daemon. This interface is accessible to all
user space processes which want to receive input events, as demanded by the second functional
requirement. This implies the need for an interprocess communication (IPC) between the
daemon and user space applications.
Linux provides a number of different methods for interprocess communication: signals,
named and unnamed pipes, message queues, semaphores, shared memory and sockets. The
two major Linux desktop environments for the X Window System—Gnome and KDE—have
their own IPC frameworks. Gnome is using ORBit, a CORBA 2.4-compliant Object Request
Broker. KDE is using Desktop Communications Proto col (DCOP) for IPC. DCOP depends
on the Qt framework. Both, ORBit and DCOP are built upon existing IPC mechanisms to
offer a better and more comfortable API to user space programs, which want to communicate
with each other. Another approach for interprocess communication is the message bus system
D-BUS which was recently introduced. D-BUS can neither be assigned to Gnome nor to KDE.
In contrast to ORBit and DCOP, D-BUS merely depends on an XML parser, such as
the aforementioned libxml2. This parser is required by D-BUS to parse its configuration
files. D-BUS was designed to offer a low latency and low overhead IPC protocol for any
application—with no focus on a specific desktop environment or programming language. The
D-BUS protocol is a binary protocol and therefore, messages do not have to be serialized. This
benefits the efficiency of D-BUS. Freedesktop.org (http://www.freedesktop.org/) serves as