Page 2 - Diploma Thesis
Diploma Thesis University of Applied Sciences AugsburgDepartment 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. Timo H¨onig
Page 3 - Input Abstraction Layer
Page 8 - Chapter 1; An Introduction to Linux Input
Chapter 1 An Introduction to Linux Input The Linux kernel offers drivers for a vast number of different input devices—drivers for key-boards, mice, joysticks, touch screens and others. Even though, many of these input devicescan not be used with the GNU/Linux operating system. This severe problem is...
Page 9 - Current State of Input Devices
CHAPTER 1. AN INTRODUCTION TO LINUX INPUT 2 1.1 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 key-boards. While 70% of the Linux beginners...
Page 10 - Ob jective
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 keyswhich are—as shown above—in many instances not working on Linux systems. I...
Page 12 - Chapter 2; Drivers and Interfaces; Input Core
Chapter 2 Drivers and Interfaces This chapter discusses the available input device drivers and their user space interfaces. Severalparts of the Linux kernel source code are examined to give both a decent understanding andan overview. Current issues regarding user input are addressed where applicable...
Page 14 - Keyboard Device Drivers
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 def...
Page 15 - USB Input Device Drivers
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 ofkeyboard with multiple languages. Only the keys’ imprint differs—the scancode of ea...
Page 16 - Bluetooth Input Device Drivers
CHAPTER 2. DRIVERS AND INTERFACES 9 USB HC USB HCI USB HID Input Core USB HID Input USB Device USB Device USB Device USB Device USB Device Driver USB Device Driver Figure 2.2: Linux USB Input USB HID and USB HID input but use the input core driver, too. They are indicated as “USBDevice Driver” in Fi...
Page 17 - Event Interface
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 thecorresponding Bluetooth host controller drivers. The Linux Bluetooth protocol stack B...
Page 18 - Advanced Configuration and Power Interface
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 vi...
Page 19 - Button Driver
CHAPTER 2. DRIVERS AND INTERFACES 12 reading from the ACPI event interface, the bus driver generates the actual ACPI event. AnACPI event has the following data structure (defined in <acpi/acpi bus.h> ): struct acpi_bus_event { struct list_head node;acpi_device_class device_class;acpi_bus_id bu...
Page 20 - Input Event Drivers; Subsystem Overview
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 ACPIdriver ( asus acpi.c ) and the IBM ThinkPad ACPI driver ( thinkpad acpi.c ). On supported systems the Asus/Medion driver generates ACPI events with devi...
Page 21 - Other Interfaces
CHAPTER 2. DRIVERS AND INTERFACES 14 ACPI Event Driver ACPI Bus Driver Power Button Sleep Button Lid Switch Other Input Proc Filesystem ACPI Button Driver /proc/acpi/event /proc/acpi/other Other ACPI Drivers User Space Process Process Figure 2.4: Linux ACPI Input The event driver is part of the ACPI...
Page 23 - Chapter 3; Requirements Specification; Required Interfaces; Input Event Interface
Chapter 3 Requirements Specification The requirements specification is the basis upon which the design and architecture, as wellas 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 dis...
Page 24 - ACPI Event Interface; Specific Event Interfaces
CHAPTER 3. REQUIREMENTS SPECIFICATION 17 Driver/Interface name: Event Interface User space interface: /dev/input/event n (minor 13, ma jor 64+ n ) Data type: binary Permissions: read and write access for root Read access: open(2) , read(2) and ioctl(2) Write access: ioctl(2) Table 3.1: Event Interfa...
Page 25 - Output Interface
CHAPTER 3. REQUIREMENTS SPECIFICATION 18 User space interface: /dev/i8k (minor 10, ma jor 144) Driver/Interface name: Dell SMM Driver Data type: string Permissions: read access for all users Access method: open(2) and read(2) User space interface: /dev/nvram (minor 10, ma jor 144) Driver/Interface n...
Page 26 - Functional Requirements; Unattended Input Events; Unified Data Representation
CHAPTER 3. REQUIREMENTS SPECIFICATION 19 3.2 Functional Requirements The functional requirements are derived from the current problems regarding user input. Unattended Input Events The ma jor problem is that many events received by the Linux kernel actually are not arrivingat to user space applicati...
Page 27 - Performance Requirements
CHAPTER 3. REQUIREMENTS SPECIFICATION 20 3.3 Performance Requirements As mentioned in the introduction of this chapter, the Input Abstraction Layer is an autonomousbackground process which is always running. No matter whether there are any input eventsto be processed or not, the daemon has always to...
Page 28 - Chapter 4; Design and Architecture; Event Data Flow
Chapter 4 Design and Architecture This chapter describes the Input Abstraction Layer’s design and architecture. It connects therequirements specification (Chapter 3) with the actual implementation discussed in Chapter 5.Throughout this chapter, possible implementations are referenced and evaluated. ...
Page 29 - Daemon
CHAPTER 4. DESIGN AND ARCHITECTURE 22 User Action Input Device Hardware Event Software Event a) b) c) Driver User Interface Application User Action Input Device Application User Action Input Device Driver User Interface Application Figure 4.1: Common Event Data Flow notified about input events, too....
Page 31 - Modular Input Interface
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 previouslyset by parsing the configuration file are overwritten. In order to examine the runtim...
Page 32 - Abstract Output Interface
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 devicedrivers that provide a user space interface (shown as “Input Interface”). Each m...
Page 34 - Chapter 5; Implementation
Chapter 5 Implementation This chapter describes the implementation of the Input Abstraction Layer in detail. The actualprocess of the implementation was preceded by a comprehensive code review of miscellaneousopen source pro jects. The review gave informative hints on how the Input Abstraction Layer...
Page 35 - Common Data Structures
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 aspectsare taken into account, too. In the end of this chapter several modules are discussed which...
Page 36 - Library
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....
Page 37 - Programming Interface
CHAPTER 5. IMPLEMENTATION 30 the first purposed hole in the deny policy: it allows all processes to connect to the systembus. 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...
Page 40 - Logging System
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.sende...
Page 42 - Modules
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 func...
Page 43 - Data Structure
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. typedef struct ModuleOption_s { const char *name;char value[MAX_BUF];const char *descr; } ModuleOpti...
Page 44 - Input Events
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 mem...
Page 46 - Module Loader
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 oneperforms the detection and verification of available modules. Each valid module is added to adoubl...
Page 49 - Configuration File Parser
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 <ialdconfig> . Beneath of this document root, all configuration options for both the daemo...
Page 50 - Command Line Interface
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) { /* ...
Page 54 - Module Invocation
CHAPTER 5. IMPLEMENTATION 47 which is requested for creation. No additional flags are passed since the third argument isset 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 ...
Page 55 - Event Loop
CHAPTER 5. IMPLEMENTATION 48 Event Loop The start up of the daemon is completed by entering the main event loop. This event loopis implemented by the GLib library. In combination with functions provided by GLib it ispossible to add callback functions to the event loop. A callback function is invoked...
Page 56 - Event Interface Module
CHAPTER 5. IMPLEMENTATION 49 which should be observed. The second argument states the conditions that have to be metto 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 impl...
Page 59 - ACPI Module
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 eve...
Page 61 - Toshiba Module
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...
Page 63 - Chapter 6; Requirements Verification; Functional Achievements
Chapter 6 Requirements Verification This chapter compares the achieved goals with the requirements specification defined in Chap-ter 3. First, the verification of the functional requirements is performed. This part of theverification compares the implementation with the demanded functional requireme...
Page 64 - Performance
CHAPTER 6. REQUIREMENTS VERIFICATION 57 6.2 Performance The performance requirements specify that the Input Abstraction Layer should only use areasonable amount of system resources while running. To evaluate the consumption of systemresources, the Input Abstraction Layer’s run-time behavior was obse...
Page 69 - Quality and Security
CHAPTER 6. REQUIREMENTS VERIFICATION 62 limit of t total = 25ms is not exceeded, the measurement series’ maximum of t 2 under high system load is used: t total = t 1 + t max The result for the keyboard events using the AT and PS/2 keyboard driver is: t total = t 1 + t max = 2ms + 14ms = 16ms The res...
Page 70 - Chapter 7
Chapter 7 Open Source DevelopmentMethodology The Input Abstraction Layer is entirely built upon Free and Open Source Software (FOSS).On the one hand, it depends on FOSS pro jects such as the C compiler of the GNU CompilerCollection (GCC), GLib and D-BUS. On the other hand, the Input Abstraction Laye...
Page 71 - Licenses
CHAPTER 7. OPEN SOURCE DEVELOPMENT METHODOLOGY 64 7.1 Licenses All FOSS pro jects are released under the terms of a FOSS license. Both the free softwaremovement and open source software movement have a list of approved licenses which theyconsider to match with their attitudes. The Free Software Foun...
Page 72 - Tools and Services
CHAPTER 7. OPEN SOURCE DEVELOPMENT METHODOLOGY 65 This is the actual citation of Paragraph 10 of the Academic Free License. This clause shouldprevent a licensee from suing the licensor and using his work at the same time. The AcademicFree License is accepted as an open source license according to th...
Page 73 - Collaborative Environment
CHAPTER 7. OPEN SOURCE DEVELOPMENT METHODOLOGY 66 A software pro ject always needs a decent documentation—for both end users and develop- ers. 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 docum...
Page 75 - Chapter 8; Conclusion; Achievements
Chapter 8 Conclusion The creation of the Input Abstraction Layer helps GNU/Linux to fulfill the users’ claim foran operating system that just works. Due to its basic approach, the Input Abstraction Layerensures to report a wide range of different input events. Thus, the functionality of the InputAbs...
Page 76 - Future Work
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 byboth users and developers, especially in the decision regarding the interprocess communicat...
Page 77 - Appendix A; Typesetting; Figures
Appendix A Utilized Free and Open SourceSoftware The diploma thesis has been accomplished using free and open source software exclusively. Thischapter contains a comprehensive list of the utilized applications and their area of application.Additionally, the licenses of the applications are specified...
Page 78 - Statistical Calculations
APPENDIX A. UTILIZED FREE AND OPEN SOURCE SOFTWARE 71 A.3 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 pos-sibility to generate graphs. Generated gr...
Page 79 - Appendix B; Announcement
Appendix B Survey: Current State of LinuxInput 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 13 th of October 2004. The evaluation of the survey’s results mentioned below is performed in Chapt...
Page 80 - General
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, <[email protected]> – Debian Laptop, <[email protected]> – Debian User, <[email protected]> – Fedora Desktop, <...
Page 83 - Desktop Systems
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES 76 B.3 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 0.00% 20.00% 60.00% 100.00% Sta...
Page 84 - Laptop Systems
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES 77 B.4 Laptop Systems Questions asked in this section are about built-in keyboards used on mobile systems runningLinux. Question 13 (single choice, mandatory): Are the function keys working as supposed? Amount of working Laptop Special and Fun...
Page 85 - Demand of Features
APPENDIX B. SURVEY: CURRENT STATE OF LINUX INPUT DEVICES 78 B.5 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)? O...
Page 87 - Appendix C; Acer System Management Mode Driver; Dell System Management Mode Driver
Appendix C Linux Function Key Support forLaptops Chapter 2 discusses several Linux input device driver for mobile computers. The subsequentlists contain the laptop models supported by each driver. These lists are not exhaustive, thoughthey contain all models which are definitely supported. C.1 Acer ...
Page 88 - Hewlett Packard OmniBook Driver
APPENDIX C. LINUX FUNCTION KEY SUPPORT FOR LAPTOPS 81 – Latitude C400, C510, C600, C610, C800, C810, C840, CPiA, CPx J750GT, D600, D800and 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,...
Page 89 - Toshiba ACPI Driver; Toshiba System Management Mode Driver
APPENDIX C. LINUX FUNCTION KEY SUPPORT FOR LAPTOPS 82 C.8 Toshiba ACPI Driver – Toshiba Libretto L5W – Toshiba Portege 2000, 2010, 3440CT, 4000, 7020CT and R100 – Toshiba Satellite 1410-303, 1410-604 and 1800-821 – Toshiba Satellite 2405, 2410-303, 2410-304S, 2410-514, 2450-401 and 2450-S203 – Toshi...
Page 90 - Appendix D; Source Code; Linux Kernel
Appendix D Source Code The printed edition the diploma thesis is supplemented by a CD-ROM. This CD-ROM containsthe source code of the Linux kernel version 2.6.9, the source code of the Input AbstractionLayer and the Input Abstraction Layer Latency kernel driver. Additionally, the diploma thesisis in...
Page 92 - Latency Kernel Driver
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 module...
Page 94 - Appendix E; Copyright; Commons Deed; Creative Commons – Commons Deed Attribution 2.0
Appendix E Copyright Copyright c ° 2004, 2005 Timo H¨onig All rights reserved. The diploma thesis is licensed under the Creative Commons Attribution License. A summaryof the license is given below, followed by the full legal text. E.1 Commons Deed Creative Commons – Commons Deed Attribution 2.0 You ...
Page 95 - Legal Code; Creative Commons – Legal Code Attribution 2.0
APPENDIX E. COPYRIGHT 88 E.2 Legal Code Creative Commons – Legal Code Attribution 2.0 CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PRO-VIDE LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATEAN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THISINFORMATION ON AN ”AS-...
Page 99 - Abbreviations
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 Documenta...
Page 101 - Glossary
Glossary Advanced Configuration and Power Interface The Advanced Configuration and Power Interface (ACPI) specification is an open in-dustry standard developed by HP, Intel, Microsoft, Phoenix and Toshiba that definescommon interfaces for hardware recognition, motherboard and device configuration an...
Page 103 - Bibliography; Print Publications
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 ...
Page 104 - Online Ressources
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] Affe...
Page 106 - Index
INDEX 99 Index AACPI . . . . . . . . . . . . . . . . . . . . . . . . 11 – 14, 52 f, 94 buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14event driver . . . . . . . . . . . . . . . . . . . . . . . . . . 11 fe...
