XkbGetKeyboardByName.man [plain text]
'\" t
.\" Copyright (c) 1999 - Sun Microsystems, Inc.
.\" All rights reserved.
.\"
.\" Permission is hereby granted, free of charge, to any person obtaining a
.\" copy of this software and associated documentation files (the
.\" "Software"), to deal in the Software without restriction, including
.\" without limitation the rights to use, copy, modify, merge, publish,
.\" distribute, and/or sell copies of the Software, and to permit persons
.\" to whom the Software is furnished to do so, provided that the above
.\" copyright notice(s) and this permission notice appear in all copies of
.\" the Software and that both the above copyright notice(s) and this
.\" permission notice appear in supporting documentation.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
.\" OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
.\" HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL
.\" INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING
.\" FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
.\" NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
.\" WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
.\" Except as contained in this notice, the name of a copyright holder
.\" shall not be used in advertising or otherwise to promote the sale, use
.\" or other dealings in this Software without prior written authorization
.\" of the copyright holder.
.\"
.TH XkbGetKeyboardByName __libmansuffix__ __xorgversion__ "XKB FUNCTIONS"
.SH NAME
XkbGetKeyboardByName \- Build a new keyboard description from a set of named
components, and to optionally have the server use the resulting description to
replace an active one
.SH SYNOPSIS
.B XkbDescPtr XkbGetKeyboardByName
(
.I dpy,
.I device_spec,
.I names,
.I want,
.I need,
.I load
)
.br
Display * \fIdpy\fP\^;
.br
unsigned int \fIdevice_spec\fP\^;
.br
XkbComponentNamesPtr \fInames\fP\^;
.br
unsigned int \fIwant\fP\^;
.br
unsigned int \fIneed\fP\^;
.br
Bool \fIload\fP\^;
.if n .ti +5n
.if t .ti +.5i
.SH ARGUMENTS
.TP
.I \- dpy
connection to X server
.TP
.I \- device_spec
device ID, or XkbUseCoreKbd
.TP
.I \- names
names of components to fetch
.TP
.I \- want
desired structures in returned record
.TP
.I \- need
mandatory structures in returned record
.TP
.I \- load
True => load into
.I device_spec
.SH DESCRIPTION
.LP
A client may request that the server fetch one or more components from its
database and use those components to build a new server keyboard description.
The new keyboard description may be built from scratch, or it may be built
starting with the current keyboard description for a particular device. Once the
keyboard description is built, all or part of it may be returned to the client.
The parts returned to the client need not include all of the parts used to build
the description. At the time it requests the server to build a new keyboard
description, a client may also request that the server use the new description
internally to replace the current keyboard description for a specific device, in
which case the behavior of the device changes accordingly.
To build a new keyboard description from a set of named components, and to
optionally have the server use the resulting description to replace an active
one, use
.I XkbGetKeyboardByName.
.I names
contains a set of expressions describing the keyboard components the
server should use to build the new keyboard description.
.I want
and
.I need
are bit fields describing the parts of the resulting keyboard description that
should be present in the returned XkbDescRec.
The individual fields in
.I names
are
.I component expressions
composed of keyboard component names (no wildcarding as may be used in
.I XkbListComponents),
the special component name symbol `%', and the special operator characters `+'
and `|'. A component expression is parsed left to right, as follows:
.IP \(bu 5
The special component name "computed" may be used in keycodes component
expressions and refers to a component consisting of a set of keycodes computed
automatically by the server as needed.
.IP \(bu 5
The special component name "canonical" may be used in types component
expressions and refers to a partial component defining the four standard key
types: ALPHABETIC, ONE_LEVEL, TWO_LEVEL, and KEYPAD.
.IP \(bu 5
The special component name `%' refers to the keyboard description for the device
specified in device_spec or the keymap names component. If a keymap names
component is specified that does not begin with `+' or `|' and does not contain
`%', then `%' refers to the description generated by the keymap names component.
Otherwise, it refers to the keyboard description for device_spec.
.IP \(bu 5
The `+' operator specifies that the following component should override the
currently assembled description; any definitions that are present in both
components are taken from the second.
.IP \(bu 5
The `|' operator specifies that the next specified component should augment the
currently assembled description; any definitions that are present in both
components are taken from the first.
.IP \(bu 5
If the component expression begins with an operator, a leading `%' is implied.
.IP \(bu 5
If any unknown or illegal characters appear anywhere in the expression, the
entire expression is invalid and is ignored.
For example, if
.I names->symbols
contained the expression "+de", it specifies that
the default member of the "de" class of symbols should be applied to the current
keyboard mapping, overriding any existing definitions (it could also be written
"+de(default)").
Here is a slightly more involved example: the expression
"acme(ascii)+de(basic)|iso9995-3" constructs a German (de) mapping for the ASCII
keyboard supplied by the "acme" vendor. The new definition begins with the
symbols for the ASCII keyboard for Acme
.I (acme(ascii)),
overrides them with definitions for the basic German keyboard
.I (de(basic)),
and then applies the definitions from the default iso9995-3 keyboard
.I (iso9995-3)
to any undefined keys or groups of keys (part three of the iso9995 standard
defines a common set of bindings for the secondary group, but allows national
layouts to override those definitions where necessary).
.B NOTE
The interpretation of the above expression components (acme, ascii, de, basic,
iso9995-3) is not defined by Xkb; only the operations and their ordering are.
Note that the presence of a keymap
.I names
component that does not contain `%' (either explicit or implied by virtue of an
expression starting with an operator) indicates a description that is
independent of the keyboard description for the device specified in
.I device_spec.
The same is true of requests in which the keymap names component is empty and
all five other names components contain expressions void of references to `%'.
Requests of this form allow you to deal with keyboard definitions independent of
any actual device.
The server parses all non-NULL fields in
.I names
and uses them to build a keyboard description. However, before parsing the
expressions in
.I names,
the server ORs the bits in
.I want
and
.I need
together and examines the result in relationship to the expressions in
.I names.
Table 1 identifies the components that are required for each of the possible
bits in
.I want
or
.I need.
If a required component has not been specified in the
.I names structure (the corresponding field is NULL), the server substitutes the
expression "%", resulting in the component values being taken from
.I device_spec.
In addition, if
.I load
is True, the server modifies
.I names
if necessary (again using a "%" entry) to ensure all of the following fields are
non-NULL:
.I types, keycodes, symbols,
and
.I compat.
.bp
.TS
c s s
l l l.
Table 1 Want and Need Mask Bits and Required Names Components
_
want or need mask bit Required names Components value
_
XkbGBN_TypesMask Types (1L<<0)
XkbGBN_CompatMapMask Compat (1L<<1)
XkbGBN_ClientSymbolsMask Types + Symbols + Keycodes (1L<<2)
XkbGBN_ServerSymbolsMask Types + Symbols + Keycodes (1L<<3)
XkbGBN_SymbolsMask Symbols (1L<<1)
XkbGBN_IndicatorMapMask Compat (1L<<4)
XkbGBN_KeyNamesMask Keycodes (1L<<5)
XkbGBN_GeometryMask Geometry (1L<<6)
XkbGBN_OtherNamesMask Types + Symbols + Keycodes + Compat + Geometry (1L<<7)
XkbGBN_AllComponentsMask (0xff)
.TE
.I need
specifies a set of keyboard components that the server must be able to
resolve in order for
.I XkbGetKeyboardByName
to succeed; if any of the components specified in
.I need
cannot be successfully resolved,
.I XkbGetKeyboardByName
fails.
.I want
specifies a set of keyboard components that the server should attempt to
resolve, but that are not mandatory. If the server is unable to resolve any of
these components,
.I XkbGetKeyboardByName
still succeeds. Bits specified in
.I want
that are also specified in
.I need
have no effect in the context of
.I want.
If
.I load
is True, the server updates its keyboard description for
.I device_spec
to match the result of the keyboard description just built. If load is False,
the
server's description for device
.I device_spec
is not updated. In all cases, the parts specified by
.I want
and
.I need
from the just-built keyboard description are returned.
The
.I names
structure in an XkbDescRec keyboard description record contains one field for
each of the five component types used to build a keyboard description. When a
keyboard description is built from a set of database components, the
corresponding fields in this
.I names
structure are set to match the expressions used to build the component.
Building a New Keyboard Description from the Server Database
The information returned to the client in the XkbDescRec is essentially the
result of a series of calls to extract information from a fictitious device
whose description matches the one just built. The calls corresponding to each of
the mask bits are summarized in Table 2, together with the XkbDescRec
components that are filled in.
.TS
c s s
l l l.
Table 2 XkbDescRec Components Returned for Values of Want & Needs
_
Request (want+need) Fills in Xkb components Equivalent Function Call
_
XkbGBN_TypesMask map.types XkbGetUpdatedMap(dpy, XkbTypesMask, Xkb)
XkbGBN_ServerSymbolsMask server XkbGetUpdatedMap(dpy,
XkbAllClientInfoMask, Xkb)
XkbGBN_ClientSymbolsMask map, including map.types
XkbGetUpdatedMap(dpy, XkbAllServerInfoMask, Xkb)
XkbGBN_IndicatorMaps indicators XkbGetIndicatorMap(dpy,
XkbAllIndicators, Xkb)
XkbGBN_CompatMapMask compat XkbGetCompatMap(dpy, XkbAllCompatMask, Xkb)
XkbGBN_GeometryMask geom XkbGetGeometry(dpy, Xkb)
XkbGBN_KeyNamesMask names.keys XkbGetNames(dpy, XkbKeyNamesMask |
names.key_aliases XkbKeyAliasesMask, Xkb)
XkbGBN_OtherNamesMask names.keycodes XkbGetNames(dpy, XkbAllNamesMask &
names.geometry ~(XkbKeyNamesMask | XkbKeyAliasesMask),
names.symbols Xkb)
names.types
map.types[*].lvl_names[*]
names.compat
names.vmods
names.indicators
names.groups
names.radio_groups
names.phys_symbols
.TE
There is no way to determine which components specified in
.I want
(but not in
.I need)
were actually fetched, other than breaking the call into successive calls to
.I XkbGetKeyboardByName
and specifying individual components.
.I XkbGetKeyboardByName
always sets
.I min_key_code
and
.I max_key_code
in the returned XkbDescRec structure.
.I XkbGetKeyboardByName
is synchronous; it sends the request to the server to build a new keyboard
description and waits for the reply. If successful, the return value is
non-NULL.
.I XkbGetKeyboardByName
generates a BadMatch protocol error if errors are encountered when building the
keyboard description.
.SH STRUCTURES
.LP
The complete description of an Xkb keyboard is given by an XkbDescRec. The
component
structures in the XkbDescRec represent the major Xkb components outlined in
Figure 1.1.
.nf
typedef struct {
struct _XDisplay * display; /\(** connection to X server */
unsigned short flags; /\(** private to Xkb, do not modify */
unsigned short device_spec; /\(** device of interest */
KeyCode min_key_code; /\(** minimum keycode for device */
KeyCode max_key_code; /\(** maximum keycode for device */
XkbControlsPtr ctrls; /\(** controls */
XkbServerMapPtr server; /\(** server keymap */
XkbClientMapPtr map; /\(** client keymap */
XkbIndicatorPtr indicators; /\(** indicator map */
XkbNamesPtr names; /\(** names for all components */
XkbCompatMapPtr compat; /\(** compatibility map */
XkbGeometryPtr geom; /\(** physical geometry of keyboard */
} XkbDescRec, *XkbDescPtr;
.fi
The
.I display
field points to an X display structure. The
.I flags field is private to the library: modifying
.I flags
may yield unpredictable results. The
.I device_spec
field specifies the device identifier of the keyboard input device, or
XkbUseCoreKeyboard, which specifies the core keyboard device. The
.I min_key_code
and
.I max_key_code
fields specify the least and greatest keycode that can be returned by the
keyboard.
Each structure component has a corresponding mask bit that is used in function
calls to
indicate that the structure should be manipulated in some manner, such as
allocating it
or freeing it. These masks and their relationships to the fields in the
XkbDescRec are
shown in Table 3.
.TS
c s s
l l l
l l l.
Table 3 Mask Bits for XkbDescRec
_
Mask Bit XkbDescRec Field Value
_
XkbControlsMask ctrls (1L<<0)
XkbServerMapMask server (1L<<1)
XkbIClientMapMask map (1L<<2)
XkbIndicatorMapMask indicators (1L<<3)
XkbNamesMask names (1L<<4)
XkbCompatMapMask compat (1L<<5)
XkbGeometryMask geom (1L<<6)
XkbAllComponentsMask All Fields (0x7f)
.TE
.SH DIAGNOSTICS
.TP 15
.B BadMatch
A compatible version of Xkb was not available in the server or an argument has
correct type and range, but is otherwise invalid
.SH "SEE ALSO"
.BR XkbListComponents (__libmansuffix__)