The core protocol provides requests to control the pitch, volume and duration of the keyboard bell and a request to explicitly sound the bell. The X Keyboard Extension allows clients to disable the audible bell, attach a symbolic name to a bell request or receive an event when the keyboard bell is rung. Clients can ask to receive XkbBellNotify event when a bell is requested by a client or generated by the server. Bells can be sounded due to core protocol Bell requests, X Input Extension DeviceBell requests, X Keyboard Extension XkbBell requests or for reasons internal to the server such as the XKB AccessXFeedback control. Bell events caused by the XkbBell request or by the AccessXFeedback control include an optional window and symbolic name for the bell. If present, the window makes it possible to provide some kind of visual indication of which window caused the sound. The symbolic name can report some information about the reason the bell was generated and makes it possible to generate a distinct sound for each type of bell. The global AudibleBell boolean control for a keyboard indicates whether bells sent to that device should normally cause the server to generate a sound. Applications which provide "sound effects" for the various named bells will typically disable the server generation of bells to avoid burying the user in sounds. When the AudibleBell control is active, all bells caused by core protocol Bell and X Input Extension DeviceBell requests cause the server to generate a sound, as do all bells generated by the XKB AccessXFeedback control. Bells requested via the X kbBell request normally cause a server-generated sound, but clients can ask the server not to sound the default keyboard bell. When the AudibleBell control is disabled, the server generates a sound only for bells that are generated using the XkbBell request and which specify forced delivery of the bell. The XkbBell request allows clients to specify a symbolic name which is reported in the bell events they cause. Bells generated by the AccessXFeedback control of this extension also include a symbolic name, but all kinds of feedback cause a single event even if they sound multiple tones. The X server is permitted to use symbolic bell names (when present) to generate sounds other than simple tones, but it is not required to do so. Aside from those used by the XKB AccessXFeedback control (see The AccessXFeedback Control), this extension does not specify bell names or their interpretation. Under some circumstances, some kind of quiet audio feedback is useful, but a normal keyboard bell is not. For example, a quiet "launch effect" can be helpful to let the user know that an application has been started, but a loud bell would simply be annoying. To simplify generation of these kinds of effects, the XkbBell request allows clients to specify "event only" bells. The X server never generates a normal keyboard bell for "event only" bells, regardless of the setting of the global AudibleBell control. If the X server generates different sounds depending bell name, it is permitted to generate a sound even for "event only" bells. This field is intended simply to weed out "normal" keyboard bells. Occasionally, it is useful to force the server to generate a sound. For example, a client could "filter" server bells, generating sound effects for some but sounding the normal server bell for others. Such a client needs a way to tell the server that the requested bell should be generated regardless of the setting of the AudibleBell control. To simplify this process, clients which call the XkbBell request can specify that a bell is forced. A forced bell always causes a server generated sound and never causes a XkbBellNotify event. Because forced bells do not cause bell notify events, they have no associated symbolic name or event window.