USB Keyboard Client Device Driver

Purpose

Supports the Universal Serial Bus (USB) keyboard devices.

Syntax

#include <sys/usbdi.h>

Description

The keyboard client consists of a back end that interfaces with the USB system driver (USBD) and a front end that interfaces with the AIX® applications such as the low function terminal (LFT) and X server applications. The USB keyboard client driver has no knowledge of the underlying USB adapter hardware. Instead, the client driver sends control requests to the USB keyboard through the USBD and receives input events through the USBD. The keyboard client driver identifies itself as a generic keyboard driver by setting the devid field in its Object Data Manager (ODM) predefined data to 030101. The parent device of the keyboard client is the pseudo device, usb0. The keyboard client does not have any child. Each keyboard device that is connected to the AIX system is represented as /dev/kbd0, /dev/kbd1, and so on.

The USB keyboard client driver supports the attachment of multiple USB keyboard devices. Each device is enumerated in the ODM and is marked as available. The client driver treats all keyboards as a single logical device. Light-emitting diode (LED) settings are sent to all keyboards and input events from all keyboards are sent to a single input ring. State tracking by the client driver ensures that a key does not generate consecutive break events and that typematic delay and repeat are handled appropriately.

Special files (for example, /dev/kbd0, /dev/kbd1, and so on) are created for each USB keyboard device. If there is at least one available USB keyboard device, an application (typically the LFT or X server application) can open any one of the USB keyboard special files.

Special treatment for the keyboard is provided by the USB system device driver configuration method because of the strict configuration and ordering rules of the graphics subsystem. When both the USB host controller and the graphics adapter are in an available state and no existing keyboard is present, the USBD ensures that at least one USB keyboard instance is defined. The USB keyboard client driver uses the USBD_OPEN_DEVICE_EXT ioctl operation to open the device that generates a valid handle even when no USB keyboard is attached to the system. The EAGAIN value is returned by the ioctl operation if there is no keyboard device and the client driver treats the device as disconnected. When you plug in a USB keyboard, a reconnect call back is made to the keyboard client by the USBD and the device is initialized allowing input events to flow to the LFT and X server applications.

Device-dependent subroutines

The USB adapter device driver supports only the open, close, ioctl, and config subroutines.

open and close subroutines

The open subroutine is used to create a channel between the caller and the keyboard client driver. The keyboard special file supports two such channels. The open subroutine call is processed normally except that the OFlag and Mode parameters are ignored. The keyboard supports an fp_open request from a kernel process. The keyboard client driver is multiplexed for an orderly change of control between the LFT and the X server applications. The most recently opened keyboard channel is the active channel to which the input events are sent. Only one channel can be open in the kernel mode at a time. The USB keyboard client supports the attachment of multiple USB keyboard devices. Thus, one or more special files can be defined. If there is at least one available USB keyboard device, an application (typically the LFT or the X server) can open any one special file of the USB keyboard because the keyboard client driver ignores the minor number specification. However, only two channels can be defined regardless of the number of available USB keyboard devices.

The close subroutine call is used to end a channel.

Read and write operations

The keyboard client driver does not support read and write operations. A read or write operation to the special file of the driver behaves as if a read operation or a write operation was made to the /dev/null file.

ioctl subroutine

The keyboard device driver supports the following ioctl suboperations:
Operation Description
IOCINFO Returns a devinfo structure, which is defined in the sys/devinfo.h header file, that describes the device. The first field of the structure (devtype) is set to the DD_INPUT value; the remaining structure is set to zero.
KSQUERYID Queries keyboard device identifier.
KSQUERYSV Queries keyboard service vector.
KSREGRING Registers input ring.
KSRFLUSH Flushes input ring.
KSLED Sets or resets keyboard LEDs.
KSVOLUME Sets alarm volume.
KSALARM Sounds alarm.
KSTRATE Sets typematic rate.
KSTDELAY Sets typematic delay.
KSKAP Enables or disables keep-alive poll.