A working console and keyboard during the initial boot image execution is needed to enter a password for encrypted file systems; it also helps while debugging. This section discusses the kernel input layer and how it can be supported during image generation. The console is a designated terminal, where kernel output goes, and that is the initial I/O device for /sbin/init. Like all terminal devices, it provides a number of functions: you can read and write to it, plus it has a number of ioctl() functions to manage line buffering, interrupt characters and baudrate or parity where applicable. Terminals come in different types: it can be a VT100 or terminal emulator connected via an RS232 cable, or it can be a combination of a CRT and a keyboard. The keyboard can be connected via USB or it can talk a byte oriented protocol via a legacy UART chip. The CRT is managed in two layers. The top layer, "virtual terminal", manages a two dimensional array describing which letter should go in which position of the screen. In fact, there are a number of different arrays, and which one is actually visible on the screen is selected by a keyboard combination. Below the virtual terminals is a layer that actually places the letters on the screen. This can be done a letter at a time, using a VGA interface, or the letters can be painted pixel by pixel, using a frame buffer. Below the terminal concept we find the input layer. This provides a unified interface to the various user input devices: mouse, keyboard, PC speaker, joystick, tablet. These input devices not only generate data, they can also receive input from the computer. As an example, the keyboard needs computer input to operate the NUM LOCK indicator. Hardware devices such as keyboards register themselves with the input layer, describing their capabilities (I can send relative position, have two buttons and no LEDs), and the input layer assigns a handler to the hardware device. The handler presents the device to upper layers, either as a char special file or as the input part of a terminal device. This is not a one-to-one mapping: every mouse gets its own handler, but keyboard and PC speaker share a handler, so it looks to userland like you have a keyboard that can do "beep". In addition to handlers for specific type of upper layers (mouse, joystick, touch screen) there is a generic handler that provides a character device file such as /dev/input/event0 for every input device detected; input events are presented through these devices in a unified format. The input layer generates hotplug events for these generic event handlers; hotplug uses modules.inputmap to load a module containing a suitable upper layer event handler. The keyboard handler is a special case that does not occur in this map, so for image generation there is little to be learned from hotplug input support. To guarantee a working console, yaird should examine /dev/console, determine whether it's RS232 or hardware directly connected to the computer, and then load modules for either serial port, or for virtual terminals, the input layer and any hardware underlying it. Unfortunately, /dev/console does not give a hint what is below the terminal interface, and unfortunately, lots of input devices are legacy hardware that is hard to probe and only sketchily described by sysfs in kernel 2.6.10. This means that a guarantee for a working console cannot be made, which is why distribution kernels come with components such as the keyboard and serial port driver compiled into the kernel. We can do something else though: provide modules for keyboard devices provided the kernel provides correct information. That covers the case of USB keyboards, and that's something that's not compiled into distribution kernels, so that the administrator has to add modules explictly in order to get the keyboard working in the initial boot image. Lets examine the sources of information we have to find which input hardware we have to support. In /sys/class/input, all input devices are enumerated. Mostly, these only contain a dev file containing major/minor number, but USB devices also have a device symlink into /sys/devices identifying the underlying hardware. In kernel 2.6.15, /sys/class/input is far more complete. It has links from class device to hardware devices, and hardware devices such as atkbd and psmouse have a 'modalias' file that can be fed to modprobe. This contains everything that's in /proc/bus/input/devices, in a nice accessible manner. As an aside, can we do all device probing based on the modalias file? This would mean we no longer would have to distinguish between sysfs format for usb and pci, making the code simpler. The tricky part is to distinguish between modules compiled in and modules simply missing from the kernel: dealing with "FATAL: Module ... not found". As a first step, we could simply assume that aliases that cannot be resolved refer to compiled in modules; this is in essence what the current scan of eg modules.usbmap does. In /boot/menu/grub.lst, kernel options can be defined that determine whether to use a serial line as console and whether to use a frame buffer. The consequence is that it is fundamentally impossible to determine by looking at the hardware alone what's needed to get an image that will boot without problems. This probably means we'll have to consider supplying some modules in the image that will only get loaded depending on kernel options. The file /proc/bus/input/devices gives a formatted overview of all known input devices; entries look like this: I: Bus=0003 Vendor=413c Product=2003 Version=0100 N: Name="DELL DELL USB Keyboard" P: Phys=usb-0000:00:1d.7-4.1/input1 H: Handlers=kbd event2 B: EV=100003 B: KEY=7f f0000 0 3878 d801d101 1e0000 0 0 0 Here the "I" line shows identification information passed to the input layer by the hardware driver that is used to look up the appropiate handler. "N" is a printable name provided by the hardware driver. "P" is a hint at location in a bus of the device; note how this line is completely unrelated to the location of the hardware in /sys/devices. The H (Handlers) line is obvious; The B lines specify capabilities of the device, plus extra information for each capability. Known capabilities include: Capability Description SYN Input event is completed KEY Key press/release event REL Relative measure, as in mouse movement ABS Absolute position, as in graphics tablet MSC Miscelanious SND Beep REP Set hardware repeat FF Don't know PWR Power event: on/off switch pressed. FF_STATUS Don't know. Finally, let's consider some kernel configuration defines, the corresponding modules and their function. This could be used as a start to check whether all components required to make an operational console are available on the generated image: Define Module Description VT (bool) Support multiple virtual terminals, irrespective of what hardware is used to display letters from the virtual terminal on the CRT. VT_CONSOLE (bool) Make the VT a candidate for console output. The alternative is a serial line to a VT100 or terminal emulator VGA_CONSOLE (bool) Display a terminal on CRT using the VGA interface. FRAMEBUFFER_CONSOLE fbcon Display a terminal on a framebuffer, painting letters a pixel at a time. This has to know about fonts. FB_VESA vesafb Implement a framebuffer based on VESA (a common standard for PC graphic cards), a place where an X server or the framebuffer console can write pixels to be displayed on CRT. There are many different framebuffer modules that optimise for different graphics cards. Note that while vesafb and other drivers such as intelfb can be built as a module, they only function correctly when built into the kernel. Most framebuffer modules depend on three other modules to function correctly: cfbfillrect, cfbcopyarea, cfbimgblt. ATKBD atkbd Interpret input from a standard AT or PS/2 keyboard. Other keyboards use other byte codes, see for example the Acorn keyboard (rpckbd). SERIO serio Module that manages a stream of bytes from and to an IO port. It includes a kernel thread (kseriod) that handles the queue needed to talk to slow ports. It is normally used for dedicated IO ports talking to PS/2 mouse and keyboard, but can also be interfaced to serial ports (COM1, COM2). The atkbd driver uses a serio driver to communicate with the keyboard. SERIO_I8042 i8042 Implement a serio stream on top of the i8042 chip, the chip that connects the standard AT keyboard and PS/2 mouse to the computer. This is legacy hardware: it's not connected via PCI but directly to the 'platform bus'. When a chip such as i8042 that implements serio is detected, it registers itself with the input layer. The input layer then lets drivers that use serio (such as atkbd and psmouse) probe whether a known device is connected via the chip; if such a device is found, it is registered as a new input device. SERIAL_8250 serial Support for serial ports (COM1, COM2) on PC hardware. Lots of other configuration options exist to support multiple cards and fiddle with interrupts. If compiled in rather than modular, a further option, SERIAL_8250_CONSOLE, allows using the serial port as a console. USB_HID usbhid Driver for USB keyboards and mice. Another define, USB_HIDINPUT, needs to be true for these devices to actually work. USB_KBD usbkbd Severely limited form of USB keyboard; uses the "boot protocol". This conflicts with the complete driver. The following figure gives an example of how the various modules can fit together.

In practical terms, a first step toward a more robust boot image is to support new keyboard types, such as USB keyboards. The following algorithm should do that. Interpret /proc/bus/input/devices. Look for devices that have handler kbd and that have buttons. Mice and the PC speaker don't match that criterium, keyboards do. You could interpret the name field of such devices if you're interested in supporting legacy keyboards. The devices that have handler 'kbd' also have a handler 'event\d', where input is presented in a generalised event format; look up this device in /sys/class/input/event\d/. If it's got a device symlink, load the hardware drivers for that hardware device (most likely it's usbhid plus a usb core driver). Don't bother with a mknod, the input is handled via /dev/console. Otherwise it's presumable a legacy device; you could check for the existence of /sys/devices/platform/i8042/serio\d/, or you could just assume the appropriate driver to be compiled in. Implement support for /etc/hotplug/blacklist, since some USB keyboards publish two interfaces (full HID and the limited boot protocol), the input layer makes both visible in /proc/bus/input/devices and the corresponding modules are mutually conflicting. The blacklist is used to filter out one of these modules.