# Key Event Processing Overview

There are three steps to processing each key event in the X server, and at least three in the client. This section describes each of these steps briefly; the following sections describe each step in more detail.

1. First, the server applies global keyboard controls to determine whether the key event should be processed immediately, deferred, or ignored. For example, the SlowKeys control can cause a key event to be deferred until the slow keys delay has elapsed while the RepeatKeys control can cause multiple X events from a single physical key press if the key is held down for an extended period. The global keyboard controls affect all of the keys on the keyboard and are described in Global Keyboard Controls.

2. Next, the server applies per-key behavior. Per key-behavior can be used to simulate or indicate some special kinds of key behavior. For example, keyboard overlays, in which a key generates an alternate keycode under certain circumstances, can be implemented using per-key behavior. Every key has a single behavior, so the effect of key behavior does not depend on keyboard modifier or group state, though it might depend on global keyboard controls. Per-key behaviors are described in detail in Key Behavior.

3. Finally, the server applies key actions. Logically, every keysym on the keyboard has some action associated with it. The key action tells the server what to do when an event which yields the corresponding keysym is generated. Key actions might change or suppress the event, generate some other event, or change some aspect of the server. Key actions are described in Key Actions.

If the global controls, per-key behavior and key action combine to cause a key event, the client which receives the event processes it in several steps.

1. First the client extracts the effective keyboard group and a set of modifiers from the state field of the event. See Computing A State Field from an XKB State for details.

2. Using the modifiers and effective keyboard group, the client selects a symbol from the list of keysyms bound to the key. Determining the KeySym Associated with a Key Event discusses symbol selection.

3. If necessary, the client transforms the symbol and resulting string using any modifiers that are "left over" from the process of looking up a symbol. For example, if the Lock modifier is left over, the resulting keysym is capitalized according to the capitalization rules specified by the system. See Transforming the KeySym Associated with a Key Event for a more detailed discussion of the transformations defined by XKB.

4. Finally, the client uses the keysym and remaining modifiers in an application-specific way. For example, applications based on the X toolkit might apply translations based on the symbol and modifiers reported by the first three steps.