원문https://source.android.com/devices/tech/input/keyboard-devices.html#keyboard-classification

  밑줄 내용참고

Keyboard Devices



Android supports a variety of keyboard devices including special function keypads (volume and power controls), compact embedded QWERTY keyboards, and fully featured PC-style external keyboards.


This document decribes physical keyboards only. Refer to the Android SDK for information about soft keyboards (Input Method Editors).

Keyboard Classification


An input device is classified as a keyboard if either of the following conditions hold:

  • The input device reports the presence of any Linux key codes used on keyboards including 0 through 0xff orKEY_OK through KEY_MAX.

  • The input device reports the presence of any Linux key codes used on joysticks and gamepads including BTN_0 through BTN_9BTN_TRIGGER through BTN_DEAD, or BTN_A through BTN_THUMBR.

Joysticks are currently classified as keyboards because joystick and gamepad buttons are reported by EV_KEY events in the same way keyboard keys are reported. Thus joysticks and gamepads also make use of key map files for configuration. Refer to the section on Joystick Devices for more information.

Once an input device has been classified as a keyboard, the system loads the input device configuration file and keyboard layout for the keyboard.

The system then tries to determine additional characteristics of the device.

  • If the input device has any keys that are mapped to KEYCODE_Q, then the device is considered to have an alphabetic keypad (as opposed to numeric). The alphabetic keypad capability is reported in the resource Configuration object as KEYBOARD_QWERTY.

    -> 키 KEYCODE_Q 는 알파벳 문자 입력장치로 인식.

  • If the input device has any keys that are mapped to KEYCODE_DPAD_UPKEYCODE_DPAD_DOWNKEYCODE_DPAD_LEFT,KEYCODE_DPAD_RIGHT, and KEYCODE_DPAD_CENTER (all must be present), then the device is considered to have a directional keypad. The directional keypad capability is reported in the resource Configuration object asNAVIGATION_DPAD.

    -> KEYCODE_DPAD_UPKEYCODE_DPAD_DOWNKEYCODE_DPAD_LEFT,KEYCODE_DPAD_RIGHT, and KEYCODE_DPAD_CENTER 는 방향 키패드 입력장치로 인식

  • If the input device has any keys that are mapped to KEYCODE_BUTTON_A or other gamepad related keys, then the device is considered to have a gamepad.

    -> KEYCODE_BUTTON_A or other gamepad related keys 면 게임패드로 인식

Keyboard Driver Requirements


  1. Keyboard drivers should only register key codes for the keys that they actually support. Registering excess key codes may confuse the device classification algorithm or cause the system to incorrectly detect the supported keyboard capabilities of the device.

    -> 실제로 사용하기 위해선 key의 key code들을 등록해야만 한다. Key code들을 너무 많이 등록하면 제대로 인식 못하거나 Device에 혼란을 줄 수 있으므로 주의

  2. Keyboard drivers should use EV_KEY to report key presses, using a value of 0 to indicate that a key is released, a value of 1 to indicate that a key is pressed, and a value greater than or equal to 2 to indicate that the key is being repeated automatically.

    -> key press를 위해선 EV_KEY 를 사용해야한다. '0'은 key release, '1'은 key press, '2'이상은 반복적으로 인식한다.

  3. Android performs its own keyboard repeating. Auto-repeat functionality should be disabled in the driver.

    -> 안드로이드에선 자체적으로 keyboard repeating을 수행하므로, 드라이버에서 auto_repeat 은 중지해야한다. ( ? : auto repeat이 뭘 의미하지..??)

  4. Keyboard drivers may optionally indicate the HID usage or low-level scan code by sending EV_MSC with MSC_SCANCODE and a value indicating the usage or scan code when the key is pressed. This information is not currently used by Android.

  5. Keyboard drivers should support setting LED states when EV_LED is written to the device. The hid-input driver handles this automatically. At the time of this writing, Android uses LED_CAPSLOCKLED_SCROLLLOCK, andLED_NUMLOCK. These LEDs only need to be supported when the keyboard actually has the associated indicator lights.

  6. Keyboard drivers for embedded keypads (for example, using a GPIO matrix) should make sure to send EV_KEYevents with a value of 0 for any keys that are still pressed when the device is going to sleep. Otherwise keys might get stuck down and will auto-repeat forever.

Keyboard Operation (안드로이드에서 Keyboard 동작 요약)


  1. The EventHub reads raw events from the evdev driver and maps Linux key codes (sometimes referred to as scan codes) into Android key codes using the keyboard's key layout map.

    -> EventHub 는 evdev 드라이버에서 이벤트들을 읽고,  리눅스 Key code(또는 Scan Code)들을 'Keyboard Key layout map'을 사용해서 안드로이드 key로 매핑한다.

  2. The InputReader consumes the raw events and updates the meta key state. For example, if the left shift key is pressed or released, the reader will set or reset the META_SHIFT_LEFT_ON and META_SHIFT_ON bits accordingly.

  3. The InputReader notifies the InputDispatcher about the key event.

  4. The InputDispatcher asks the WindowManagerPolicy what to do with the key event by calling WindowManagerPolicy.interceptKeyBeforeQueueing. This method is part of a critical path that is responsible for waking the device when certain keys are pressed. The EventHub effectively holds a wake lock along this critical path to ensure that it will run to completion.

  5. If an InputFilter is currently in use, the InputDispatcher gives it a chance to consume or transform the key. The InputFilter may be used to implement low-level system-wide accessibility policies.

  6. The InputDispatcher enqueues the key for processing on the dispatch thread.

  7. When the InputDispatcher dequeues the key, it gives the WindowManagerPolicy a second chance to intercept the key event by calling WindowManagerPolicy.interceptKeyBeforeDispatching. This method handles system shortcuts and other functions.

  8. The InputDispatcher then identifies the key event target (the focused window) and waits for them to become ready. Then, the InputDispatcher delivers the key event to the application.

  9. Inside the application, the key event propagates down the view hierarchy to the focused view for pre-IME key dispatch.

  10. If the key event is not handled in the pre-IME dispatch and an IME is in use, the key event is delivered to the IME.

  11. If the key event was not consumed by the IME, then the key event propagates down the view hierarchy to the focused view for standard key dispatch.

  12. The application reports back to the InputDispatcher as to whether the key event was consumed. If the event was not consumed, the InputDispatcher calls WindowManagerPolicy.dispatchUnhandledKey to apply "fallback" behavior. Depending on the fallback action, the key event dispatch cycle may be restarted using a different key code. For example, if an application does not handle KEYCODE_ESCAPE, the system may redispatch the key event as KEYCODE_BACK instead.

Keyboard Configuration


Keyboard behavior is determined by the keyboard's key layout, key character map and input device configuration.

Refer to the following sections for more details about the files that participate in keyboard configuration:

Properties

The following input device configuration properties are used for keyboards.

keyboard.layout

Definition: keyboard.layout = <name>

Specifies the name of the key layout file associated with the input device, excluding the .kl extension. If this file is not found, the input system will use the default key layout instead.

Spaces in the name are converted to underscores during lookup.

Refer to the key layout file documentation for more details.

keyboard.characterMap

Definition: keyboard.characterMap = <name>

Specifies the name of the key character map file associated with the input device, excluding the .kcm extension. If this file is not found, the input system will use the default key character map instead.

Spaces in the name are converted to underscores during lookup.

Refer to the key character map file documentation for more details.

keyboard.orientationAware

Definition: keyboard.orientationAware = 0 | 1

Specifies whether the keyboard should react to display orientation changes.

  • If the value is 1, the directional keypad keys are rotated when the associated display orientation changes.

  • If the value is 0, the keyboard is immune to display orientation changes.

The default value is 0.

Orientation awareness is used to support rotation of directional keypad keys, such as on the Motorola Droid. For example, when the device is rotated clockwise 90 degrees from its natural orientation, KEYCODE_DPAD_UP is remapped to produce KEYCODE_DPAD_RIGHT since the 'up' key ends up pointing 'right' when the device is held in that orientation.

keyboard.builtIn

Definition: keyboard.builtIn = 0 | 1

Specifies whether the keyboard is the built-in (physically attached) keyboard.

The default value is 1 if the device name ends with -keypad0 otherwise.

The built-in keyboard is always assigned a device id of 0. Other keyboards that are not built-in are assigned unique non-zero device ids.

Using an id of 0 for the built-in keyboard is important for maintaining compatibility with theKeyCharacterMap.BUILT_IN_KEYBOARD field, which specifies the id of the built-in keyboard and has a value of 0. This field has been deprecated in the API but older applications might still be using it.

A special-function keyboard (one whose key character map specifies a type of SPECIAL_FUNCTION) will never be registered as the built-in keyboard, regardless of the setting of this property. This is because a special-function keyboard is by definition not intended to be used for general purpose typing.

Example Configurations

# This is an example input device configuration file for a built-in
# keyboard that has a DPad.

# The keyboard is internal because it is part of the device.
device
.internal = 1

# The keyboard is the default built-in keyboard so it should be assigned
# an id of 0.
keyboard
.builtIn = 1

# The keyboard includes a DPad which is mounted on the device.  As the device
# is rotated the orientation of the DPad rotates along with it, so the DPad must
# be aware of the display orientation.  This ensures that pressing 'up' on the
# DPad always means 'up' from the perspective of the user, even when the entire
# device has been rotated.
keyboard
.orientationAware = 1

Compatibility Notes

Prior to Honeycomb, the keyboard input mapper did not use any configuration properties. All keyboards were assumed to be physically attached and orientation aware. The default key layout and key character map was named qwerty instead of Generic. The key character map format was also very different and the framework did not support PC-style full keyboards or external keyboards.

When upgrading devices to Honeycomb, make sure to create or update the necessary configuration and key map files.

HID Usages, Linux Key Codes and Android Key Codes


The system refers to keys using several different identifiers, depending on the layer of abstraction.

For HID devices, each key has an associated HID usage. The Linux hid-input driver and related vendor and device-specific HID drivers are responsible for parsing HID reports and mapping HID usages to Linux key codes.

As Android reads EV_KEY events from the Linux kernel, it translates each Linux key code into its corresponding Android key code according to the key layout file of the device.
-> 안드로이드는 리눅스 커널에서 EV_KEY event 를 읽고, Device의 key layout file을 이용해 각 리눅스 Key code를 안드로이드 Key code로 번역한다.

When the key event is dispatched to an application, the android.view.KeyEvent instance reports the Linux key code as the value of getScanCode() and the Android key code as the value of getKeyCode(). For the purposes of the framework, only the value of getKeyCode() is important.

Note that the HID usage information is not used by Android itself or passed to applications.

Code Tables


The following tables show how HID usages, Linux key codes and Android key codes are related to one another.
-> HID가 어떻게 리눅스 키코드와 안드로이드 키코드가 연결되어 사용되는지 보여줌.

The LKC column specifies the Linux key code in hexadecimal.

The AKC column specifies the Android key code in hexadecimal.

The Notes column refers to notes that are posted after the table.

The Version column specifies the first version of the Android platform to have included this key in its default key map. Multiple rows are shown in cases where the default key map has changed between versions. The oldest version indicated is 1.6.

  • In Gingerbread (2.3) and earlier releases, the default key map was qwerty.kl. This key map was only intended for use with the Android Emulator and was not intended to be used to support arbitrary external keyboards. Nevertheless, a few OEMs added Bluetooth keyboard support to the platform and relied on qwerty.kl to provide the necessary keyboard mappings. Consequently these older mappings may be of interest to OEMs who are building peripherals for these particular devices. Note that the mappings are substantially different from the current ones, particularly with respect to the treatment of the HOME key. It is recommended that all new peripherals be developed according to the Honeycomb or more recent key maps (ie. standard HID).

  • As of Honeycomb (3.0), the default key map is Generic.kl. This key map was designed to support full PC style keyboards. Most functionality of standard HID keyboards should just work out of the box.

The key code mapping may vary across versions of the Linux kernel and Android. When changes are known to have occurred in the Android default key maps, they are indicated in the version column.

Device-specific HID drivers and key maps may apply different mappings than are indicated here.


+ Recent posts