Specifications

CHAPTER 2. DRIVERS AND INTERFACES 11

To enable the event interface the Linux kernel has to be compiled with INPUT EVDEV=y or

INPUT EVDEV=m. The driver evbug.c (INPUT EVBUG) can be used to debug the event interface.

If event debugging is enabled, all input events are printed to the system log via printk().

2.6 Advanced Conﬁguration and Power Interface

The Advanced Conﬁguration and Power Interface (ACPI) speciﬁcation [Acp04] deﬁnes diﬀerent

buttons as user input: a power button, a sleep button and a lid switch. While the power button

is mandatory according to the ACPI speciﬁcation, the sleep button and the lid switch are both

optional. The lid switch only applies to mobile computers. The operating system is responsible

for the action which is taken upon receiving an event from one of the buttons: it may invoke

suggestive functions of the operating system’s ACPI implementation, such as switching the

system to a sleep or power oﬀ state, but it also may ignore the button events at all.

The Linux ACPI implementation exports several interfaces to user space using the vir-

tual ﬁle system proc, usually mounted at /proc. The ACPI bus driver (bus.c, located in

drivers/acpi) creates the ACPI root entry /proc/acpi. ACPI drivers which want to oﬀer

an interface in user space create proc entries underneath this root entry. Most of these entries

are read-only. User space applications can use those interfaces to gather information. Some

ACPI drivers export interfaces which can be used for both gathering information and invoking

functions of the ACPI subsystem.

Most ACPI drivers are using the function acpi bus generate event() to report events.

This function is provided by the ACPI bus driver. Besides button events (button.c), ACPI

events include notiﬁcations about the thermal state of devices (thermal.c), the charging state

of batteries (battery.c), the state of the AC adapter (ac.c) and events issued by CPUs

(processor.c). However, the button events are the only events which can directly be invoked

by the user.

The interface for ACPI events (read-only) is realized by the driver event.c. User space ap-

plications can access this interface by reading /proc/acpi/event. If no user space pro cess is ac-

tually reading from the event interface, the ACPI events are not written to /proc/acpi/event

by the event driver. Whether a process is reading from the interface or not is determined by

checking the value of the variable event is open. As soon as a user space process invokes

the system call open(2) in order to access /proc/acpi/event, the event driver’s function

acpi system open event() is invoked. This function sets event is open to 1. Correspond-

ingly, event is open is set to 0 by acpi system close event() once the process stops reading

from the event interface.

ACPI events are volatile as long as no user space process is accessing the event inter-

face. But once a user space process reads from /proc/acpi/event, it receives the ACPI

events that occur, since the ﬁle descriptor was opened by the process. As read access to

/proc/acpi/event can not be concurrent, a user space application is responsible for the dis-

tribution of the ACPI events. Drivers generating ACPI events call the bus driver’s function

acpi bus generate event():

int acpi_bus_generate_event(struct acpi_device *device, u8 type, int data);

The calling function has to pass a pointer device to the ACPI device which has triggered

the event, an event type (type) and event data (data) as parameters. Only in case of a process