Diploma Thesis University of Applied Sciences Augsburg Department of Computer Science Input Abstraction Layer Design and Implementation of an Extended Input Interface Submitted by Timo Hönig, Winter Semester 2004/2005 Examiner: Examiner: Supervisor: Prof. Dr. Hubert Högl Prof. Burkhard Stork Dipl. Inf. (univ.) Stefan Behlert The Diploma Thesis has been created in cooperation with SUSE Linux AG, Nuremberg.
Diploma Thesis University of Applied Sciences Augsburg Department of Computer Science I affirm that the diploma thesis is my own work and has never been used before, for any auditing purposes. All used sources, additional used information and citations are quoted as such.
Input Abstraction Layer Timo Hönig
c 2004, 2005 Timo Hönig ° All rights reserved. Timo Hönig, Johannes-Haag-Straße 2, D-86153 Augsburg 08 07 06 05 04 65432 First edition: Second impression, with corrections: 15. December 2004 9. January 2005 This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/2.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Contents Contents i 1 An 1.1 1.2 1.3 1 2 3 3 Introduction to Linux Input Current State of Input Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of the Diploma Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Drivers and Interfaces 2.1 Input Core . . . . . . . . . . . . . 2.2 Keyboard Device Drivers . . . . . 2.3 USB Input Device Drivers . . . . . 2.
CONTENTS 4 Design and Architecture 4.1 Event Data Flow . . . . . 4.2 Daemon . . . . . . . . . . 4.3 Modular Input Interface . 4.4 Abstract Output Interface ii . . . . 21 21 22 24 25 . . . . . . . . . . . . . . . . . . 27 28 29 29 30 33 35 36 37 38 39 42 43 46 47 48 49 52 54 6 Requirements Verification 6.1 Functional Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.
CONTENTS 1 B Survey: Current State of Linux Input Devices B.1 Announcement . . . . . . . . . . . . . . . . . . B.2 General . . . . . . . . . . . . . . . . . . . . . . B.3 Desktop Systems . . . . . . . . . . . . . . . . . B.4 Laptop Systems . . . . . . . . . . . . . . . . . . B.5 Demand of Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 1 An Introduction to Linux Input The Linux kernel offers drivers for a vast number of different input devices—drivers for keyboards, mice, joysticks, touch screens and others. Even though, many of these input devices can not be used with the GNU/Linux operating system. This severe problem is caused by input device drivers’ varying implementations: they are not following a common standard. It is in the nature of the process how free and open source development evolves by the course of time.
CHAPTER 1. AN INTRODUCTION TO LINUX INPUT 1.1 2 Current State of Input Devices The answers to the questions regarding desktop keyboards (Appendix B, §B.3) revealed that Linux beginners are not the only one unsatisfied with the current support for desktop keyboards. While 70% of the Linux beginners working on desktop systems are unhappy with the current situation, almost 50% of the experienced users demand better support for desktop keyboards, too.
CHAPTER 1. AN INTRODUCTION TO LINUX INPUT 3 Recent laptops offer various features like dynamic CPU frequency and adjustment of screen brightness to save power consumption. Such features are commonly controlled by function keys which are—as shown above—in many instances not working on Linux systems. It is not unusual that functions like switching between LCD and CRT are not working, too.
CHAPTER 1. AN INTRODUCTION TO LINUX INPUT 4 Throughout the text the notation term(n ) indicates that a reference manual is available for term. The value n determines the type of term: – 1: Executable programs or shell commands – 2: System calls (functions provided by the kernel) – 3: Library calls (functions within program libraries) E.g. open(2) indicates that open is a system call. The referenced manual can be read using the command man 2 open in a regular Linux console.
Chapter 2 Drivers and Interfaces This chapter discusses the available input device drivers and their user space interfaces. Several parts of the Linux kernel source code are examined to give both a decent understanding and an overview. Current issues regarding user input are addressed where applicable. All relevant kernel configuration options are described and mentioned at appropriate passages. As further reading, [Low04] deepens the configuration and compilation of the Linux kernel.
CHAPTER 2. DRIVERS AND INTERFACES 6 Input Device Device Driver Event Handler User Space Input Device Device Driver Input Core Event Handler Input Device Device Driver Event Handler Kernel Space Input Device Figure 2.1: Linux Input System function input register device() first. The driver calling input register device() must supply a pointer to a structure input dev as parameter. void input_register_device(struct input_dev *); The structure input dev is defined in
CHAPTER 2. DRIVERS AND INTERFACES 7 event to the input core, are named input event. Once an input device driver has reported an event by calling input event(), the input core generates a structure input event which is passed to the registered input event handlers. The function input event() is defined in .
CHAPTER 2. DRIVERS AND INTERFACES 8 events. The input events carry the scancodes, the event handler keyboard.c translates the scancodes to their corresponding keycodes. This mapping is necessary to operate one kind of keyboard with multiple languages. Only the keys’ imprint differs—the scancode of each key remains the same. Useful tools to debug scan- and keycodes are showkey(1), loadkeys(1), dumpkeys(1) and setkeycodes(8). The source package of these utilities is available from http://lct. sourceforge.
CHAPTER 2. DRIVERS AND INTERFACES USB Device USB HC USB HCI 9 USB HID Input Core USB HID Input USB Device USB Device Driver USB Device USB Device Driver USB Device Figure 2.2: Linux USB Input USB HID and USB HID input but use the input core driver, too. They are indicated as “USB Device Driver” in Figure 2.2. USB support for the Linux kernel is enabled by setting the configuration option CONFIG USB to either y (compile static into kernel) or m (compile as module).
CHAPTER 2. DRIVERS AND INTERFACES 10 Bluetooth devices (“BT Devices”) are connected to a Bluetooth host controller (“BT HC”) which is attached to the system as described above. The host controllers are driven by the corresponding Bluetooth host controller drivers. The Linux Bluetooth protocol stack BlueZ (http://www.bluez.
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.
CHAPTER 2. DRIVERS AND INTERFACES 12 reading from the ACPI event interface, the bus driver generates the actual ACPI event. An ACPI event has the following data structure (defined in
CHAPTER 2. DRIVERS AND INTERFACES 13 Input Event Drivers Drivers which are using the ACPI bus driver to report input events are the Asus/Medion ACPI driver (asus acpi.c) and the IBM ThinkPad ACPI driver (thinkpad acpi.c). On supported systems the Asus/Medion driver generates ACPI events with device class set to hotkey and bus id set to HOTK. The value for type depends on the key pressed. As previously mentioned data represents how often the corresponding key is pressed.
CHAPTER 2. DRIVERS AND INTERFACES Power Button ACPI Button Driver ACPI Bus Driver 14 ACPI Event Driver Sleep Button Proc Filesystem User Space /proc/acpi/event Process /proc/acpi/other Process Lid Switch Other Input Other ACPI Drivers Figure 2.4: Linux ACPI Input The event driver is part of the ACPI subsystem and does not need to be enabled explicitly in the kernel configuration. As mentioned above, user space is responsible for the distribution of the ACPI events.
CHAPTER 2. DRIVERS AND INTERFACES 15 set to 0x80, the value of data depends on which hotkey is pressed. E.g. the hotkey combination Fn-F4 creates the following ACPI event: pcc HKEY 00000080 00000084 Most Sony laptops have a proprietary programmable controller called “Sony Programmable I/O Control Device”. This device can be accessed using the Sony PI driver (CONFIG SONYPI) which creates the user space interface /dev/sonypi. Additional user space programs are required to utilize this interface.
Chapter 3 Requirements Specification The requirements specification is the basis upon which the design and architecture, as well as the implementation of the Input Abstraction Layer are built. The relevant kernel drivers’ interfaces are summed up and described in a more abstract way than they were discussed in the previous chapter. Moreover, the attributes of the Input Abstraction Layer’s output interface are described.
CHAPTER 3. REQUIREMENTS SPECIFICATION Driver/Interface name: User space interface: Data type: Permissions: Read access: Write access: 17 Event Interface /dev/input/eventn (minor 13, major 64+n) binary read and write access for root open(2), read(2) and ioctl(2) ioctl(2) Table 3.
CHAPTER 3.
CHAPTER 3. REQUIREMENTS SPECIFICATION 3.2 19 Functional Requirements The functional requirements are derived from the current problems regarding user input. Unattended Input Events The major problem is that many events received by the Linux kernel actually are not arriving at to user space applications. Thus, they can not be used. The first functional requirement is the implementation of a user space interface which is reporting to up until to now unattended events.
CHAPTER 3. REQUIREMENTS SPECIFICATION 3.3 20 Performance Requirements As mentioned in the introduction of this chapter, the Input Abstraction Layer is an autonomous background process which is always running. No matter whether there are any input events to be processed or not, the daemon has always to be poised, to work them up as soon as they occur.
Chapter 4 Design and Architecture This chapter describes the Input Abstraction Layer’s design and architecture. It connects the requirements specification (Chapter 3) with the actual implementation discussed in Chapter 5. Throughout this chapter, possible implementations are referenced and evaluated. Section §4.1 discusses the generic event data flow which is common for all input events.
CHAPTER 4. DESIGN AND ARCHITECTURE Hardware Event a) 22 Software Event User Action Input Device User Action Input Device User Action Input Device Driver User Interface Application b) c) Application Driver User Interface Application Figure 4.1: Common Event Data Flow notified about input events, too. This case is shown in Figure 4.
CHAPTER 4. DESIGN AND ARCHITECTURE 23 AllowOverride and Order are options for the directive Directory with their corresponding values. AllowOverride All Order deny, allow Samba uses a configuration file format which was derived from the .ini files used by Microsoft Windows 3.1. This format is divided into sections. Each section has one or more options with a corresponding value. The following example shows the sections [global] and [share1].
CHAPTER 4. DESIGN AND ARCHITECTURE 24 First, the configuration file is parsed and the included options are set. Secondly, the command line arguments are evaluated and the included options are set. Options previously set by parsing the configuration file are overwritten. In order to examine the runtime behavior of the Input Abstraction Layer, a multi level logging system is needed. Depending on which logging level is set, the daemon issues more or less debug output.
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.
CHAPTER 4. DESIGN AND ARCHITECTURE 26 the project lead. This emphasizes the will of implementing an independent IPC framework, that does not displease any Gnome or KDE developer, as Freedesktop.org is working on projects supporting the collaboration and interoperability of desktop environments. Beside the small amount of dependencies, D-BUS distinguishes itself by offering bindings for many high-level programming languages. This fact satisfies the fifth functional requirement (Chapter 3, §3.
Chapter 5 Implementation This chapter describes the implementation of the Input Abstraction Layer in detail. The actual process of the implementation was preceded by a comprehensive code review of miscellaneous open source projects. The review gave informative hints on how the Input Abstraction Layer’s requirements could be realized. Resulting from this, several parts of the Input Abstraction Layer’s implementation are derived from the reviewed source code.
CHAPTER 5. IMPLEMENTATION 28 The subsequent sections of this chapter separately discuss the implementation of the three components. Important attributes of the components are emphasized and the dynamic aspects are taken into account, too. In the end of this chapter several modules are discussed which impart the actual functionality of the Input Abstraction Layer. The complete source code is documented using Doxygen (http://www.doxygen.org/).
CHAPTER 5. IMPLEMENTATION 29 Modules use the structure IalEvent in conjunction with a wrapper function to report abstract input events. The library libial implements this wrapper function and sends the event using D-BUS. The meaning of the structure’s members is discussed in Section §5.2 and §5.3. All modules are based on two static data structures: ModuleData and ModuleOption. The main structure ModuleData represents the common ground on which every module for the Input Abstraction Layer is based on.
CHAPTER 5. IMPLEMENTATION 30 the first purposed hole in the deny policy: it allows all processes to connect to the system bus. Further, the D-BUS daemon parses additional configuration files located in the directory /etc/dbus-1/system.d/. System daemons utilizing D-BUS for interprocess communication store their respective D-BUS configuration in this directory. A D-BUS service is the basic requirement for interprocess communication using D-BUS.
CHAPTER 5. IMPLEMENTATION 31 /* Check whether D-BUS connection is already established. */ if (dbus_connection == NULL) { /* Connect to the D-BUS system message bus. */ dbus_connection = dbus_bus_get(DBUS_BUS_SYSTEM, &dbus_error); } The type of the global variable dbus connection is DBusConnection. It represents a D-BUS connection. The D-BUS function dbus get bus() establishes the connection and subsequently returns the established connection.
CHAPTER 5. IMPLEMENTATION 32 dbus message new signal() creates a new DBusMessage of type SIGNAL and returns a pointer to the created structure. The arguments specify the message path (/com/novell/Ial/Event), the D-BUS interface (com.novell.Ial.Event) and the signal name (event). These values are essential for the D-BUS daemon to process the D-BUS message. The message type SIGNAL is chosen since it matches the kind of an event.
CHAPTER 5. IMPLEMENTATION 33 void event_callback(DBusConnection *connection, DBusMessage *dbus_message, void *user_data) { /* Create abstract input event. */ IalEvent event; /* Read arguments from D-BUS message. */ dbus_message_get_args(dbus_message, &dbus_error, DBUS_TYPE_STRING, &event.sender, DBUS_TYPE_STRING, &event.source, DBUS_TYPE_STRING, &event.name, DBUS_TYPE_INT32, &event.raw, DBUS_TYPE_INVALID); } The abstract input event is represented by event using the IalEvent structure.
CHAPTER 5. IMPLEMENTATION 34 org) which is released under the terms of the Academic Free License version 2.0. The logging system is implemented by libial log.c and libial log.h. It provides four different priorities: LOGPRI ERROR, LOGPRI WARNING, LOGPRI INFO and LOGPRI DEBUG—with LOGPRI ERROR being the highest and LOGPRI DEBUG being the lowest priority.
CHAPTER 5. IMPLEMENTATION 35 The do {...} while(0) loop is run once and encapsulates the invocation of log setup() and log output(). Without this encapsulation, errors could occur if the macro is used in conjunction with an if-else construct. The function log setup() stores the values of the function arguments to variables used by the subsequently called function, log output(). The preprocessor can not dissolve FUNCTION since it is not a macro.
CHAPTER 5. IMPLEMENTATION 36 Data Structure Both data structures ModuleData and ModuleOption are declared in libial mod.h. The structure ModuleData is slightly shortened compared to the source code.
CHAPTER 5. IMPLEMENTATION 37 ModuleOption mod_options[] = { {"disable", "false", "disable=(true|false)"}, {"verbose", "true", "verbose=(true|false)"}, {NULL} }; The following code shows an example of how a module creates the ModuleData structure. The member options is a pointer to the array mod options. ModuleData mod_data = { .name = "Example Input Abstraction Layer Module", .token = "example_module", .version = "0.1", .author = "Timo Hoenig", .
CHAPTER 5. IMPLEMENTATION 38 When an input event occurs, the module reports this event by creating an abstract input event IalEvent followed by a call to the library’s function event send(). The following example illustrates this procedure: /* Create abstract input event. */ IalEvent event; /* Fill all members. */ event.sender = mod_data.token; event.source = "Interface Name"; event.name = "Brightness Up"; event.raw = 0x130; /* Send the event using libial.
CHAPTER 5. IMPLEMENTATION 39 Each stage is realized by a specific component of the Input Abstraction Layer daemon. Functions for the first and fifth stage are implemented by the module loader. Stage one performs the detection and verification of available modules. Each valid module is added to a double linked list. Once the modules are detected, stage two is invoked. The configuration file parser is responsible for setting up the configuration for both the daemon and the modules.
CHAPTER 5. IMPLEMENTATION 40 pass all checks performed by the module loader’s functions to be accepted as a valid Input Abstraction Layer module. filename mod_scan() filename, symbol mod_verify() dl_function() filename handle, symbol dlopen() Failure Failure Success Failure Success dlsym() Success Failure Success Failure Success Figure 5.5: Input Abstraction Layer Module Verification Verified modules are stored in a double linked list.
CHAPTER 5. IMPLEMENTATION 41 be subsequently invoked, since function references the module’s function mod get data(). Once called, it returns the required pointer to the module’s data structure ModuleData. The returned pointer is assigned to the new list element’s module member data: /* Assign the pointer to the module’s ModuleData to the member data.
CHAPTER 5. IMPLEMENTATION 42 Configuration File Parser The Input Abstraction Layer’s daemon configuration is stored in /etc/ial/iald.conf. It is formatted as an XML document. The document root has to be . Beneath of this document root, all configuration options for both the daemon and the modules are stored. Each child node of the document root is a configuration option. The configuration file parser conf parse file() evaluates all children nodes using functions of the library libxml2.
CHAPTER 5. IMPLEMENTATION 43 module = module_list_head; /* Iterate all modules, start at the list head. */ while(module) { if(node.token == module.token) { child = node.child; /* Iterate all module options for each child of the node. */ while(child) { while(option) { if(child.name == option.name) { /* Match found. */ option.value = child.
CHAPTER 5. IMPLEMENTATION 44 additional arguments, e.g. program -d 3 (program --debug 3) with 3 being the argument for the command line option -d (--debug). Parsing of the command line options is realized using getopt long(3). The usage of the function getopt long() requires the expected command line options to be known at compile time. Hence, this function can only be used to parse the daemon’s configuration options.
CHAPTER 5. IMPLEMENTATION 45 These functions are responsible for evaluating the supplied configuration options. The Input Abstraction Layer’s most important functions for this task are the ones handling the command line options of the modules. They are invoked by the command line options list, list-verbose and module-options. The command line options list and list-verbose provide information about the modules and their possible configuration options.
CHAPTER 5. IMPLEMENTATION 46 The string mod options consists of one or more strings with the format mod option. The function opt modules opts() parses the string mod options using string operations provided by the GNU C Library. One mod option supplies the configuration options for one module. To pass configuration options for several modules, a comma-separated list of mod option strings has to be passed as argument. The following example is based on the already discussed demonstration module (§5.3).
CHAPTER 5. IMPLEMENTATION 47 which is requested for creation. No additional flags are passed since the third argument is set to 0. If the D-BUS daemon is not able to create the requested service, the structure dbus error is filled with information. This structure is of type DBusError and represents a D-BUS exception. Module Invocation Once the connection to the system message bus is established and the service is acquired, the daemon is completely initialized.
CHAPTER 5. IMPLEMENTATION 48 Event Loop The start up of the daemon is completed by entering the main event loop. This event loop is implemented by the GLib library. In combination with functions provided by GLib it is possible to add callback functions to the event loop. A callback function is invoked as soon as a specified event occurs. The source of an event can be a timeout or the modification of a file descriptor (file, pipe or socket).
CHAPTER 5. IMPLEMENTATION 49 which should be observed. The second argument states the conditions that have to be met to trigger an event. In the example two conditions are supplied: G IO IN and G IO ERR. The condition G IO IN is fulfilled if data is pending to be read from the io channel. This implies that an event on the interface /dev/interface has happened. The second condition G IO ERR is fulfilled if an error occurred while reading from the io channel and therefore, from /dev/interface.
CHAPTER 5. IMPLEMENTATION 50 gap by reporting all input events of keyboards—whether there is a translation available for a key’s scancode or not. The source code of the module is found in the directory modules. The prefix libial evdev is common for all files belonging to the module. The event interface module can be enabled or disabled. This is the only configuration option provided by the module.
CHAPTER 5. IMPLEMENTATION 51 – Generate an abstract input event – Send the abstract input event Reading data from the event interface returns a structure input event (Chapter 2, §2.1). The structure’s member type gives information whether the occurred input event was a keypress or not. A keypress’ type has the value EV KEY. For security reasons, the module only reports input events of keys which are not blacklisted. Beside others, blacklisted keys are all alpha numeric keys.
CHAPTER 5. IMPLEMENTATION 52 Once the data structure is filled, the module sends the abstract input event by calling the library’s function event send(). Correspondingly, the event is delivered to the D-BUS interface of the Input Abstraction Layer. The creation and sending of an abstract output event for a concrete input event is illustrated by the following example. Granted that an input device has the name “AT Translated Set 2 keyboard” and offers a special key indicating a symbol for “E-Mail”.
CHAPTER 5. IMPLEMENTATION 53 default the module is enabled. Further, the loading function initializes the user space interface of the ACPI subsystem if disable equals false. This initialization routine first tries to access the user space interface /proc/acpi/event directly. If this approach fails, it is most likely that another process has already acquired the interface. If this process is the ACPI daemon acpid, another user space interface is available to receive the ACPI events.
CHAPTER 5. IMPLEMENTATION 54 The member raw is not available for ACPI events since they have no numeric representation. Hence, the value of raw is set to -1 for all events. Once the abstract input event event is set up by acpi event send(), it sends the event to the Input Abstraction Layer’s output interface by invoking the library’s function event send(). 5.7 Toshiba Module The Toshiba module libial toshiba is applicable for most recent Toshiba laptops (Appendix C, §C.8).
CHAPTER 5. IMPLEMENTATION 55 is similar to the translation of a scancode value to its corresponding description. The values for the function events received by polling the Toshiba ACPI driver’s user space interface are reported as a unique numeric value. The structure Key represents a function key combination.
Chapter 6 Requirements Verification This chapter compares the achieved goals with the requirements specification defined in Chapter 3. First, the verification of the functional requirements is performed. This part of the verification compares the implementation with the demanded functional requirements. Secondly, the performance requirements are verified. In order to verify whether the performance requirements are met as demanded, a kernel driver was implemented to measure the latency of input events.
CHAPTER 6. REQUIREMENTS VERIFICATION 6.2 57 Performance The performance requirements specify that the Input Abstraction Layer should only use a reasonable amount of system resources while running. To evaluate the consumption of system resources, the Input Abstraction Layer’s run-time behavior was observed with top(1). This program provides a dynamic real-time view of the processes’ resource consumption running on a system.
CHAPTER 6. REQUIREMENTS VERIFICATION 58 Figure 6.1 gives an overview of the time needed by an input event to reach a user space application. The user action on an input device triggers a hardware event which attains kernel space—the input device’s driver—either by generating an interrupt or by being polled. This period of time is denoted as t1 .
CHAPTER 6. REQUIREMENTS VERIFICATION 59 The variable event jiffies of type unsigned long is initialized with a zero. To make the variable accessible to other kernel drivers—the input device drivers—its symbol needs to be exported. This is done with the macro EXPORT SYMBOL. To measure t2 , the input device drivers are required to store the current value of jiffies into event jiffies once an input event occurs. To do so, the driver needs to include include/jiffies.
CHAPTER 6. REQUIREMENTS VERIFICATION 60 open("/proc/ial_event_received", O_RDONLY); This system call causes iallatency to store the current jiffies into receive jiffies.
CHAPTER 6. REQUIREMENTS VERIFICATION 61 The second test series was performed measuring the time intervals for ACPI buttons. Figure 6.3 shows the results of the passes for the ACPI button driver. At low system load, the minimum of t2 was tmin = 1ms and the maximum was tmax = 8ms. The average time interval is tavg = 2.33ms. The corresponding values for t2 at high system load are: tmin = 2ms and tmax = 17ms. The average time interval is tavg = 6.51ms.
CHAPTER 6. REQUIREMENTS VERIFICATION 62 limit of ttotal = 25ms is not exceeded, the measurement series’ maximum of t2 under high system load is used: ttotal = t1 + tmax The result for the keyboard events using the AT and PS/2 keyboard driver is: ttotal = t1 + tmax = 2ms + 14ms = 16ms The result for ACPI events processed by the ACPI button driver is: ttotal = t1 + tmax = 2ms + 17ms = 19ms The result for ACPI Toshiba drivers’ input events depend on the polling frequency.
Chapter 7 Open Source Development Methodology The Input Abstraction Layer is entirely built upon Free and Open Source Software (FOSS). On the one hand, it depends on FOSS projects such as the C compiler of the GNU Compiler Collection (GCC), GLib and D-BUS. On the other hand, the Input Abstraction Layer itself is a FOSS project. This chapter outlines the development methodology of open source software on the basis of the Input Abstraction Layer.
CHAPTER 7. OPEN SOURCE DEVELOPMENT METHODOLOGY 7.1 64 Licenses All FOSS projects are released under the terms of a FOSS license. Both the free software movement and open source software movement have a list of approved licenses which they consider to match with their attitudes. The Free Software Foundation (FSF) provides a list of the qualified free software licenses in [Fsf04b]. A list of software licenses approved by the Open Source Initiative (OSI) is found in [OSS04].
CHAPTER 7. OPEN SOURCE DEVELOPMENT METHODOLOGY 65 This is the actual citation of Paragraph 10 of the Academic Free License. This clause should prevent a licensee from suing the licensor and using his work at the same time. The Academic Free License is accepted as an open source license according to the Open Source Initiative. The license is not classified as free software license by the Free Software Foundation since it is not GPL-compatible. 7.
CHAPTER 7. OPEN SOURCE DEVELOPMENT METHODOLOGY 66 A software project always needs a decent documentation—for both end users and developers. The Input Abstraction Layer’s source code is documented using Doxygen (Appendix D, §D.2). For this purpose, Doxygen is a powerful tool to generate the documentation while coding. The documentation is done by commenting the source code with a specific syntax. Doxygen afterwards parses the source code and generates the documentation.
CHAPTER 7. OPEN SOURCE DEVELOPMENT METHODOLOGY 67 – Freshmeat, http://www.freshmeat.net – Gnome Files, http://www.gnomefiles.org – KDE Apps, http://www.kde-apps.org The Input Abstraction Layer is hosted by Berlios. At present the following services have been set up. Additional services will be extended as required by the course of time: – Home page, http://ial.berlios.de – Doxygen documentation, http://ial.berlios.de/doc – Subversion repository, svn://svn.berlios.
Chapter 8 Conclusion The creation of the Input Abstraction Layer helps GNU/Linux to fulfill the users’ claim for an operating system that just works. Due to its basic approach, the Input Abstraction Layer ensures to report a wide range of different input events. Thus, the functionality of the Input Abstraction Layer affects several fields of application. The achieved goals and the remaining efforts are recapitulated in the following paragraphs. 8.
CHAPTER 8. CONCLUSION 69 Beside the study of source code, it was essential to spot the edge conditions the resulting program will run in. These edge conditions are of particular relevance for the acceptance by both users and developers, especially in the decision regarding the interprocess communication, focused on a fluent integration of the Input Abstraction Layer into GNU/Linux. 8.2 Future Work The efforts made so far have created a solid groundwork for upcoming challenges.
Appendix A Utilized Free and Open Source Software The diploma thesis has been accomplished using free and open source software exclusively. This chapter contains a comprehensive list of the utilized applications and their area of application. Additionally, the licenses of the applications are specified. A.1 Typesetting The diploma thesis is typeset with teTeX which is a TEX distribution that consists only of free software.
APPENDIX A. UTILIZED FREE AND OPEN SOURCE SOFTWARE A.3 71 Statistical Calculations Both the survey (Appendix B) and the latency measurements (Chapter 6, §6.2) have been evaluated using Gnumeric. Gnumeric is a powerful spreadsheet software and offers the possibility to generate graphs. Generated graphs can be exported to SVG. Gnumeric is released under the terms of the GPL and is available from http://www.gnome.org/projects/. A.
Appendix B Survey: Current State of Linux Input Devices The survey “Current State of Linux Input Devices” has been completed by 305 participants. The duration of the survey was five days starting on the 13th of October 2004. The evaluation of the survey’s results mentioned below is performed in Chapter 1, §1.1. B.1 Announcement The survey was announced sending the following e-mail: Subject: Current State of Linux Input Devices From: Timo Hoenig
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES 73 SVN: http://svn.berlios.de/viewcvs/ial/ This e-mail was sent to the following mailing lists: – Linux Laptop, – Debian Laptop, – Debian User, – Fedora Desktop, – Gentoo Desktop, – Gnome, – KDE, – Dell Laptop,
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES Question 3 (single choice, mandatory): Where do you use Linux? Field of Application Home Work Both 0.00% 20.00% 40.00% 60.00% 80.00% 100.00% Question 4 (single choice, mandatory): Which kernel are you running? Kernel Version Linux 2.4 Linux 2.6 Other Don’t know 0.00% 20.00% 40.00% 60.00% 80.00% 100.00% Question 5 (single choice, mandatory): Do you compile your own kernel? Kernel Compiled by Hand Yes No 0.00% 20.00% 40.00% 60.00% 80.
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES Question 7 (multiple choice, mandatory): Which window manager(s) do you prefer? Afterstep Blackbox CTWM/TWM Enlightenment Fluxbox FVWM IceWM Kahakai Kwin MetaCity Openbox Oroborus Pekwm Sawfish SWM Waimea Window Maker XFCE Other 0.00% 20.00% 40.00% 60.00% 80.00% 100.00% Question 8 (single choice, mandatory): On what kind of system do you run Linux? Keyboard Type Desktop Laptop Both 0.00% 20.00% 40.00% 60.00% 80.00% 100.
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES B.3 76 Desktop Systems Questions asked in this section are about keyboards used on desktop systems running Linux. Question 9 (multiple choice, mandatory): What kind of keyboard(s) are you using? Desktop Keyboard Standard Keyboard Multimedia Keyboard Other 0.00% 20.00% 60.00% 100.
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES B.4 77 Laptop Systems Questions asked in this section are about built-in keyboards used on mobile systems running Linux. Question 13 (single choice, mandatory): Are the function keys working as supposed? Amount of working Laptop Special and Function Keys All Some None 0.00% 20.00% 40.00% 60.00% 80.00% 100.
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES B.5 78 Demand of Features Questions asked in this section are about features demanded by the participants of the survey. Question 16 (single choice, optional): Would you like to have an on screen display (e.g. for screen brightness, volume)? On Screen Display Must have Would like to have Neutral Don’t need it 0.00% 20.00% 40.00% 60.00% 80.00% 100.
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES 79 Question 19 (single choice, optional): Would you like to be able to change the screen brightness using the appropriate function keys? Change Brightness Must have Would like to have Neutral Don’t need it 0.00% 20.00% 40.00% 60.00% 80.00% 100.
Appendix C Linux Function Key Support for Laptops Chapter 2 discusses several Linux input device driver for mobile computers. The subsequent lists contain the laptop models supported by each driver. These lists are not exhaustive, though they contain all models which are definitely supported. C.
APPENDIX C. LINUX FUNCTION KEY SUPPORT FOR LAPTOPS 81 – Latitude C400, C510, C600, C610, C800, C810, C840, CPiA, CPx J750GT, D600, D800 and X200 C.4 Hewlett Packard OmniBook Driver – HP OmniBook XE2 – HP OmniBook XE3 GF, GC, GD, GE and compatible – HP OmniBook XE4500 and compatible – HP OmniBook 500, 510, 4150, 6000 and 6100 – Fujitsu Amilo D – Recent Toshiba Satellite laptops which do not have a Toshiba BIOS C.
APPENDIX C. LINUX FUNCTION KEY SUPPORT FOR LAPTOPS C.
Appendix D Source Code The printed edition the diploma thesis is supplemented by a CD-ROM. This CD-ROM contains the source code of the Linux kernel version 2.6.9, the source code of the Input Abstraction Layer and the Input Abstraction Layer Latency kernel driver. Additionally, the diploma thesis is included as source and as PDF file in the directory /thesis. Beside the unpacked source code, all programs are included as archives in the directory /archives.
APPENDIX D. SOURCE CODE 84 CD-ROM: Linux 2.6.9 (unpacked, unmodified): /linux/linux-2.6.9 Linux 2.6.9 (unpacked, with IAL Latency patch): /linux/linux-2.6.9 iallatency Linux 2.6.9 (archive, unmodified): /archives/linux-2.6.9.tar.gz Internet: Linux 2.6.9 (archive): http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.gz D.2 Input Abstraction Layer The Input Abstraction Layer’s source code can be obtained using Subversion.
APPENDIX D. SOURCE CODE 85 If the source code is obtained using Subversion, it is required to run ./autogen.sh prior to ./configure. The last command make install needs to be executed with root privileges. The Input Abstraction Layer Daemon iald is installed to the directory /usr/sbin/. The modules are stored in the directory /usr/lib/ial/modules. The configuration files are copied to the directories /etc/iald and /etc/dbus-1/system.d.
APPENDIX D. SOURCE CODE 86 The kernel has to be recompiled with the configuration option INPUT IALLATENCY either set to y (compile static) or m (compile as module). Further information is supplied by the documentation of the Input Abstraction Layer Latency driver. This documentation is found in the file README and is part of the driver’s package. A user space application for setting received jiffies is included by the Input Abstraction Layer (/usr/bin/iallatency).
Appendix E Copyright c 2004, 2005 Timo Hönig Copyright ° All rights reserved. The diploma thesis is licensed under the Creative Commons Attribution License. A summary of the license is given below, followed by the full legal text. E.1 Commons Deed Creative Commons – Commons Deed Attribution 2.0 You are free: • to copy, distribute, display, and perform the work • to make derivative works • to make commercial use of the work Under the following conditions: Attribution.
APPENDIX E. COPYRIGHT E.2 88 Legal Code Creative Commons – Legal Code Attribution 2.0 CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN ”AS-IS” BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM ITS USE.
APPENDIX E. COPYRIGHT 89 2. Fair Use Rights. Nothing in this license is intended to reduce, limit, or restrict any rights arising from fair use, first sale or other limitations on the exclusive rights of the copyright owner under copyright law or other applicable laws. 3. License Grant.
APPENDIX E. COPYRIGHT 90 b.
APPENDIX E. COPYRIGHT 91 by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. d. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent. e. This License constitutes the entire agreement between the parties with respect to the Work licensed here.
Abbreviations ACPI Advanced Configuration and Power Interface AFL Academic Free License AGPL Affero General Public License CLI Command Line Interface CRT Cathode Ray Tube CTAN Comprehensive TeX Archive Network DCOP Desktop Communications Protocol HCI Hardware Control Interface FDL GNU Free Documentation License FIFO First In First Out FSH Filesystem Hierarchy Standard GPG GNU Privacy Guard GPL GNU General Public License GUI Graphical User Interface HID Human Interface Device 92
ABBREVIATIONS HIDP Human Interface Device Protocol IPC Interprocess Communication L2CAP Logical Link Control and Adaptation Protocol LCD Liquid Crystal Display LGPL GNU Lesser General Public License LPPL LaTeX Project Public License LSB Linux Standard Base LPPL LaTeX Project Public License NVRAM Non-Volatile Random Access Memory PDF Portable Document Format SCI System Control Interface SMM System Management Mode SVG Scalable Vector Graphics UCCASS Unit Command Climate Assessment and Survey System USB Unive
Glossary Advanced Configuration and Power Interface The Advanced Configuration and Power Interface (ACPI) specification is an open industry standard developed by HP, Intel, Microsoft, Phoenix and Toshiba that defines common interfaces for hardware recognition, motherboard and device configuration and power management [Wik04a] [Hoe04].
GLOSSARY 95 Hotplug Hotplug lets you plug in new devices and use them immediately. That means that users won’t need to learn so much system administration; systems will at least partially autoconfigure themselves. Initially, hotplug included support for USB and PCI (Cardbus) devices, and could automatically configure some common network interfaces. Updated versions include IEEE 1394 (Firewire/i.Link) support and can download firmware to USB devices that need it.
Bibliography Print Publications [CSF04] Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. Version Control with Subversion. O’Reilly. June 2004. (ISBN 0-596-00448-6), 2004. Available free of charge from http://svnbook.red-bean.com/. [FB03] Karl Fogel, Moshe Bar. Open Source Development with CVS. Paraglyph Press. July 2003. (ISBN 1-932111-81-6), 2003. Available free of charge from http://cvsbook.red-bean.com/. [Hoe04] Timo Hönig. ACPI Implementation in Linux 2.6: The Small Sleeper.
BIBLIOGRAPHY 97 Online Ressources [Acp04] Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Ltd., Toshiba Corporation. Advanced Configuration and Power Interface Specification v3.0. September 2004. (Available from http://www.acpi.info/spec.htm) [Aff02] Affero Inc. Affero General Public License. March 2002. (Available from http://www.affero.org/oagpl.html) [Fsh04] Filesystem Hierarchy Standard Group. Filesystem Hierarchy Standard v2.3. 2004.
BIBLIOGRAPHY 98 [Ros04] Lawrence E. Rosen. The Academic Free License v. 2.1. Mai 2004. (Available from http://www.rosenlaw.com/afl21.htm) [Sig04] Bluetooth Special Interest Group (SIG). Bluetooth Specification Documents. October 2004. (Available from http://www.bluetooth.org/spec/ Note: Registration required.) [Usb01] USB Implementers Forum. Device Class Definition for Human Interface Devices (HID). June 2001. (Available from http://www.usb.org/ developers/devclass_docs/HID1_11.
INDEX 99 Index A ACPI . . . . . . . . . . . . . . . . . . . . . . . . 11 – 14, 52 f, 94 buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 event driver . . . . . . . . . . . . . . . . . . . . . . . . . . 11 f events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 f interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 subsystem . . . . . . . . . . . . . . . . . . . . . . . . . .
INDEX Panasonic Hotkey Driver (ACPI) . . 14, 81 Sony Programmable I/O . . . . . . . . . . . . . 14 f Toshiba (ACPI) . . . . . . . . . . . . . . . . . . . 13, 82 Toshiba (SMM) . . . . . . . . . . . . . . . . . . 14 f, 82 USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 dumpkeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 dynamically loaded shared libraries . . . . 24, 35 E evdev callback() function. . . . . . . . . . . . . . . . . .50 event data flow. . .
INDEX Gnome Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 GNU Autotools . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 GNU C Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 GNU coding standards . . . . . . . . . . . . . . . . . . . . 43 GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 68 Gnumeric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 GPG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INDEX keycode . . . . . . . . . . . . . . . . . . . . . see keycode scancode . . . . . . . . . . . . . . . . . . . see scancode Sun Type 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Sun Type 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 VAXstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 keycode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 f, 16, 49 keymap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 f L L2CAP . . . . . .
INDEX 103 Sourceforge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 X statistical calculations . . . . . . . . . . . . . . . . . . . . . 71 XML . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 25, 38, 95 Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65, 84 survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 ff, 71 f announcement . . . . . . . . . . . . . . . . . . . . . . . . 72 desktop systems. . . . . . . . . . . . . . . . . . . . . . . .
