Input Device Functions
You can use the Xlib input device functions to:
Grab the pointer and individual buttons on the pointer
Grab the keyboard and individual keys on the keyboard
Resume event processing
Move the pointer
Set the input focus
Manipulate the keyboard and pointer settings
Manipulate the keyboard encoding
Pointer Grabbing
Xlib provides functions that you can use to control input from the pointer,
which usually is a mouse.
Usually, as soon as keyboard and mouse events occur,
the X server delivers them to the appropriate client,
which is determined by the window and input focus.
The X server provides sufficient control over event delivery to
allow window managers to support mouse ahead and various other
styles of user interface.
Many of these user interfaces depend on synchronous delivery of events.
The delivery of pointer and keyboard events can be controlled
independently.
When mouse buttons or keyboard keys are grabbed, events
will be sent to the grabbing client rather than the normal
client who would have received the event.
If the keyboard or pointer is in asynchronous mode,
further mouse and keyboard events will continue to be processed.
If the keyboard or pointer is in synchronous mode, no
further events are processed until the grabbing client
allows them (see
).
The keyboard or pointer is considered frozen during this
interval.
The event that triggered the grab can also be replayed.
Note that the logical state of a device (as seen by client applications)
may lag the physical state if device event processing is frozen.
Active grab
There are two kinds of grabs:
active and passive.
An active grab occurs when a single client grabs the keyboard and/or pointer
explicitly (see
and
).
Passive grab
A passive grab occurs when clients grab a particular keyboard key
or pointer button in a window,
and the grab will activate when the key or button is actually pressed.
Passive grabs are convenient for implementing reliable pop-up menus.
For example, you can guarantee that the pop-up is mapped
before the up pointer button event occurs by
grabbing a button requesting synchronous behavior.
The down event will trigger the grab and freeze further
processing of pointer events until you have the chance to
map the pop-up window.
You can then allow further event processing.
The up event will then be correctly processed relative to the
pop-up window.
For many operations,
there are functions that take a time argument.
The X server includes a timestamp in various events.
One special time, called
CurrentTime
Time
CurrentTime,
represents the current server time.
The X server maintains the time when the input focus was last changed,
when the keyboard was last grabbed,
when the pointer was last grabbed,
or when a selection was last changed.
Your
application may be slow reacting to an event.
You often need some way to specify that your
request should not occur if another application has in the meanwhile
taken control of the keyboard, pointer, or selection.
By providing the timestamp from the event in the request,
you can arrange that the operation not take effect
if someone else has performed an operation in the meanwhile.
A timestamp is a time value, expressed in milliseconds.
It typically is the time since the last server reset.
Timestamp values wrap around (after about 49.7 days).
The server, given its current time is represented by timestamp T,
always interprets timestamps from clients by treating half of the timestamp
space as being later in time than T.
One timestamp value, named
CurrentTime,
is never generated by the server.
This value is reserved for use in requests to represent the current server time.
For many functions in this section,
you pass pointer event mask bits.
The valid pointer event mask bits are:
ButtonPressMask,
ButtonReleaseMask,
EnterWindowMask,
LeaveWindowMask,
PointerMotionMask,
PointerMotionHintMask,
Button1MotionMask,
Button2MotionMask,
Button3MotionMask,
Button4MotionMask,
Button5MotionMask,
ButtonMotionMask,
and
KeymapStateMask.
For other functions in this section,
you pass keymask bits.
The valid keymask bits are:
ShiftMask,
LockMask,
ControlMask,
Mod1Mask,
Mod2Mask,
Mod3Mask,
Mod4Mask,
and
Mod5Mask.
To grab the pointer, use
.
Grabbingpointer
Pointergrabbing
XGrabPointer
int XGrabPointer
Display *display
Window grab_window
Bool owner_events
unsignedint event_mask
intpointer_mode, keyboard_mode
Window confine_to
Cursor cursor
Time time
display
Specifies the connection to the X server.
grab_window
Specifies the grab window.
owner_events
Specifies a Boolean value that indicates whether the pointer
events are to be reported as usual or reported with respect to the grab window
if selected by the event mask.
event_mask
Specifies which pointer events are reported to the client.
The mask is the bitwise inclusive OR of the valid pointer event mask bits.
pointer_mode
Specifies further processing of pointer events.
You can pass
GrabModeSync
or
GrabModeAsync.
keyboard_mode
Specifies further processing of keyboard events.
You can pass
GrabModeSync
or
GrabModeAsync.
confine_to
Specifies the window to confine the pointer in or
None.
cursor
Specifies the cursor that is to be displayed during the grab or
None.
time
Specifies the time.
You can pass either a timestamp or
CurrentTime.
The
function actively grabs control of the pointer and returns
GrabSuccess
if the grab was successful.
Further pointer events are reported only to the grabbing client.
overrides any active pointer grab by this client.
If owner_events is
False,
all generated pointer events
are reported with respect to grab_window and are reported only if
selected by event_mask.
If owner_events is
True
and if a generated
pointer event would normally be reported to this client,
it is reported as usual.
Otherwise, the event is reported with respect to the
grab_window and is reported only if selected by event_mask.
For either value of owner_events, unreported events are discarded.
If the pointer_mode is
GrabModeAsync,
pointer event processing continues as usual.
If the pointer is currently frozen by this client,
the processing of events for the pointer is resumed.
If the pointer_mode is
GrabModeSync,
the state of the pointer, as seen by
client applications,
appears to freeze, and the X server generates no further pointer events
until the grabbing client calls
or until the pointer grab is released.
Actual pointer changes are not lost while the pointer is frozen;
they are simply queued in the server for later processing.
If the keyboard_mode is
GrabModeAsync,
keyboard event processing is unaffected by activation of the grab.
If the keyboard_mode is
GrabModeSync,
the state of the keyboard, as seen by
client applications,
appears to freeze, and the X server generates no further keyboard events
until the grabbing client calls
or until the pointer grab is released.
Actual keyboard changes are not lost while the pointer is frozen;
they are simply queued in the server for later processing.
If a cursor is specified, it is displayed regardless of what
window the pointer is in.
If
None
is specified,
the normal cursor for that window is displayed
when the pointer is in grab_window or one of its subwindows;
otherwise, the cursor for grab_window is displayed.
If a confine_to window is specified,
the pointer is restricted to stay contained in that window.
The confine_to window need have no relationship to the grab_window.
If the pointer is not initially in the confine_to window,
it is warped automatically to the closest edge
just before the grab activates and enter/leave events are generated as usual.
If the confine_to window is subsequently reconfigured,
the pointer is warped automatically, as necessary,
to keep it contained in the window.
The time argument allows you to avoid certain circumstances that come up
if applications take a long time to respond or if there are long network
delays.
Consider a situation where you have two applications, both
of which normally grab the pointer when clicked on.
If both applications specify the timestamp from the event,
the second application may wake up faster and successfully grab the pointer
before the first application.
The first application then will get an indication that the other application
grabbed the pointer before its request was processed.
generates
EnterNotify
and
LeaveNotify
events.
Either if grab_window or confine_to window is not viewable
or if the confine_to window lies completely outside the boundaries of the root
window,
fails and returns
GrabNotViewable.
If the pointer is actively grabbed by some other client,
it fails and returns
AlreadyGrabbed.
If the pointer is frozen by an active grab of another client,
it fails and returns
GrabFrozen.
If the specified time is earlier than the last-pointer-grab time or later
than the current X server time, it fails and returns
GrabInvalidTime.
Otherwise, the last-pointer-grab time is set to the specified time
(CurrentTime
is replaced by the current X server time).
can generate
BadCursor,
BadValue,
and
BadWindow
errors.
To ungrab the pointer, use
.
Ungrabbingpointer
Pointerungrabbing
XUngrabPointer
XUngrabPointer
Display *display
Time time
display
Specifies the connection to the X server.
time
Specifies the time.
You can pass either a timestamp or
CurrentTime.
The
function releases the pointer and any queued events
if this client has actively grabbed the pointer from
,
,
or from a normal button press.
does not release the pointer if the specified
time is earlier than the last-pointer-grab time or is later than the
current X server time.
It also generates
EnterNotify
and
LeaveNotify
events.
The X server performs an
UngrabPointer
request automatically if the event window or confine_to window
for an active pointer grab becomes not viewable
or if window reconfiguration causes the confine_to window to lie completely
outside the boundaries of the root window.
To change an active pointer grab, use
.
Pointergrabbing
Changingpointer grab
XChangeActivePointerGrab
XChangeActivePointerGrab
Display *display
unsignedint event_mask
Cursor cursor
Time time
display
Specifies the connection to the X server.
event_mask
Specifies which pointer events are reported to the client.
The mask is the bitwise inclusive OR of the valid pointer event mask bits.
cursor
Specifies the cursor that is to be displayed or
None.
time
Specifies the time.
You can pass either a timestamp or
CurrentTime.
The
function changes the specified dynamic parameters if the pointer is actively
grabbed by the client and if the specified time is no earlier than the
last-pointer-grab time and no later than the current X server time.
This function has no effect on the passive parameters of an
.
The interpretation of event_mask and cursor is the same as described in
.
can generate
BadCursor
and
BadValue
errors.
To grab a pointer button, use
.
Grabbingbuttons
Buttongrabbing
XGrabButton
XGrabButton
Display *display
unsignedint button
unsignedint modifiers
Window grab_window
Bool owner_events
unsignedint event_mask
intpointer_mode, keyboard_mode
Window confine_to
Cursor cursor
display
Specifies the connection to the X server.
button
Specifies the pointer button that is to be (Bu or
AnyButton.
modifiers
Specifies the set of keymasks or
AnyModifier.
The mask is the bitwise inclusive OR of the valid keymask bits.
grab_window
Specifies the grab window.
owner_events
Specifies a Boolean value that indicates whether the pointer
events are to be reported as usual or reported with respect to the grab window
if selected by the event mask.
event_mask
Specifies which pointer events are reported to the client.
The mask is the bitwise inclusive OR of the valid pointer event mask bits.
pointer_mode
Specifies further processing of pointer events.
You can pass
GrabModeSync
or
GrabModeAsync.
keyboard_mode
Specifies further processing of keyboard events.
You can pass
GrabModeSync
or
GrabModeAsync.
confine_to
Specifies the window to confine the pointer in or
None.
cursor
Specifies the cursor that is to be displayed or
None.
The
function establishes a passive grab.
In the future,
the pointer is actively grabbed (as for
),
the last-pointer-grab time is set to the time at which the button was pressed
(as transmitted in the
ButtonPress
event), and the
ButtonPress
event is reported if all of the following conditions are true:
The pointer is not grabbed, and the specified button is logically pressed
when the specified modifier keys are logically down,
and no other buttons or modifier keys are logically down.
The grab_window contains the pointer.
The confine_to window (if any) is viewable.
A passive grab on the same button/key combination does not exist
on any ancestor of grab_window.
The interpretation of the remaining arguments is as for
.
The active grab is terminated automatically when the logical state of the
pointer has all buttons released
(independent of the state of the logical modifier keys).
Note that the logical state of a device (as seen by client applications)
may lag the physical state if device event processing is frozen.
This request overrides all previous grabs by the same client on the same
button/key combinations on the same window.
A modifiers of
AnyModifier
is equivalent to issuing the grab request for all
possible modifier combinations (including the combination of no modifiers).
It is not required that all modifiers specified have currently assigned
KeyCodes.
A button of
AnyButton
is equivalent to
issuing the request for all possible buttons.
Otherwise, it is not required that the specified button currently be assigned
to a physical button.
If some other client has already issued an
with the same button/key combination on the same window, a
BadAccess
error results.
When using
AnyModifier
or
AnyButton,
the request fails completely,
and a
BadAccess
error results (no grabs are
established) if there is a conflicting grab for any combination.
has no effect on an active grab.
can generate
BadCursor,
BadValue,
and
BadWindow
errors.
To ungrab a pointer button, use
.
Ungrabbingbuttons
Buttonungrabbing
XUngrabButton
XUngrabButton
Display *display
unsignedint button
unsignedint modifiers
Window grab_window
display
Specifies the connection to the X server.
button
Specifies the pointer button that is to be (Bu or
AnyButton.
modifiers
Specifies the set of keymasks or
AnyModifier.
The mask is the bitwise inclusive OR of the valid keymask bits.
grab_window
Specifies the grab window.
The
function releases the passive button/key combination on the specified window if
it was grabbed by this client.
A modifiers of
AnyModifier
is
equivalent to issuing
the ungrab request for all possible modifier combinations, including
the combination of no modifiers.
A button of
AnyButton
is equivalent to issuing the
request for all possible buttons.
has no effect on an active grab.
can generate
BadValue
and
BadWindow
errors.
Keyboard Grabbing
Xlib provides functions that you can use to grab or ungrab the keyboard
as well as allow events.
For many functions in this section,
you pass keymask bits.
The valid keymask bits are:
ShiftMask,
LockMask,
ControlMask,
Mod1Mask,
Mod2Mask,
Mod3Mask,
Mod4Mask,
and
Mod5Mask.
To grab the keyboard, use
.
Keyboardgrabbing
Grabbingkeyboard
XGrabKeyboard
int XGrabKeyboard
Display *display
Window grab_window
Bool owner_events
intpointer_mode, keyboard_mode
Time time
display
Specifies the connection to the X server.
grab_window
Specifies the grab window.
owner_events
Specifies a Boolean value that indicates whether the keyboard events
are to be reported as usual.
pointer_mode
Specifies further processing of pointer events.
You can pass
GrabModeSync
or
GrabModeAsync.
keyboard_mode
Specifies further processing of keyboard events.
You can pass
GrabModeSync
or
GrabModeAsync.
time
Specifies the time.
You can pass either a timestamp or
CurrentTime.
The
function actively grabs control of the keyboard and generates
FocusIn
and
FocusOut
events.
Further key events are reported only to the
grabbing client.
overrides any active keyboard grab by this client.
If owner_events is
False,
all generated key events are reported with
respect to grab_window.
If owner_events is
True
and if a generated
key event would normally be reported to this client, it is reported
normally; otherwise, the event is reported with respect to the
grab_window.
Both
KeyPress
and
KeyRelease
events are always reported,
independent of any event selection made by the client.
If the keyboard_mode argument is
GrabModeAsync,
keyboard event processing continues
as usual.
If the keyboard is currently frozen by this client,
then processing of keyboard events is resumed.
If the keyboard_mode argument is
GrabModeSync,
the state of the keyboard (as seen by client applications) appears to freeze,
and the X server generates no further keyboard events until the
grabbing client issues a releasing
call or until the keyboard grab is released.
Actual keyboard changes are not lost while the keyboard is frozen;
they are simply queued in the server for later processing.
If pointer_mode is
GrabModeAsync,
pointer event processing is unaffected
by activation of the grab.
If pointer_mode is
GrabModeSync,
the state of the pointer (as seen by client applications) appears to freeze,
and the X server generates no further pointer events
until the grabbing client issues a releasing
call or until the keyboard grab is released.
Actual pointer changes are not lost while the pointer is frozen;
they are simply queued in the server for later processing.
If the keyboard is actively grabbed by some other client,
fails and returns
AlreadyGrabbed.
If grab_window is not viewable,
it fails and returns
GrabNotViewable.
If the keyboard is frozen by an active grab of another client,
it fails and returns
GrabFrozen.
If the specified time is earlier than the last-keyboard-grab time
or later than the current X server time,
it fails and returns
GrabInvalidTime.
Otherwise, the last-keyboard-grab time is set to the specified time
(CurrentTime
is replaced by the current X server time).
can generate
BadValue
and
BadWindow
errors.
To ungrab the keyboard, use
.
Keyboardungrabbing
Ungrabbingkeyboard
XUngrabKeyboard
XUngrabKeyboard
Display *display
Time time
display
Specifies the connection to the X server.
time
Specifies the time.
You can pass either a timestamp or
CurrentTime.
The
function
releases the keyboard and any queued events if this client has it actively grabbed from
either
or
.
does not release the keyboard and any queued events
if the specified time is earlier than
the last-keyboard-grab time or is later than the current X server time.
It also generates
FocusIn
and
FocusOut
events.
The X server automatically performs an
UngrabKeyboard
request if the event window for an
active keyboard grab becomes not viewable.
To passively grab a single key of the keyboard, use
.
Keygrabbing
Grabbingkeys
XGrabKey
XGrabKey
Display *display
int keycode
unsignedint modifiers
Window grab_window
Bool owner_events
intpointer_mode, keyboard_mode
display
Specifies the connection to the X server.
keycode
Specifies the KeyCode or
AnyKey.
modifiers
Specifies the set of keymasks or
AnyModifier.
The mask is the bitwise inclusive OR of the valid keymask bits.
grab_window
Specifies the grab window.
owner_events
Specifies a Boolean value that indicates whether the keyboard events
are to be reported as usual.
pointer_mode
Specifies further processing of pointer events.
You can pass
GrabModeSync
or
GrabModeAsync.
keyboard_mode
Specifies further processing of keyboard events.
You can pass
GrabModeSync
or
GrabModeAsync.
The
function establishes a passive grab on the keyboard.
In the future,
the keyboard is actively grabbed (as for
),
the last-keyboard-grab time is set to the time at which the key was pressed
(as transmitted in the
KeyPress
event), and the
KeyPress
event is reported if all of the following conditions are true:
The keyboard is not grabbed and the specified key
(which can itself be a modifier key) is logically pressed
when the specified modifier keys are logically down,
and no other modifier keys are logically down.
Either the grab_window is an ancestor of (or is) the focus window,
or the grab_window is a descendant of the focus window and contains the pointer.
A passive grab on the same key combination does not exist
on any ancestor of grab_window.
The interpretation of the remaining arguments is as for
.
The active grab is terminated automatically when the logical state of the
keyboard has the specified key released
(independent of the logical state of the modifier keys).
Note that the logical state of a device (as seen by client applications)
may lag the physical state if device event processing is frozen.
A modifiers argument of
AnyModifier
is equivalent to issuing the request for all
possible modifier combinations (including the combination of no
modifiers).
It is not required that all modifiers specified have
currently assigned KeyCodes.
A keycode argument of
AnyKey
is equivalent to issuing
the request for all possible KeyCodes.
Otherwise, the specified keycode must be in
the range specified by min_keycode and max_keycode in the connection
setup,
or a
BadValue
error results.
If some other client has issued a
with the same key combination on the same window, a
BadAccess
error results.
When using
AnyModifier
or
AnyKey,
the request fails completely,
and a
BadAccess
error results (no grabs are established)
if there is a conflicting grab for any combination.
can generate
BadAccess,
BadValue,
and
BadWindow
errors.
To ungrab a key, use
.
Keyungrabbing
Ungrabbingkeys
XUngrabKey
XUngrabKey
Display *display
int keycode
unsignedint modifiers
Window grab_window
display
Specifies the connection to the X server.
keycode
Specifies the KeyCode or
AnyKey.
modifiers
Specifies the set of keymasks or
AnyModifier.
The mask is the bitwise inclusive OR of the valid keymask bits.
grab_window
Specifies the grab window.
The
function releases the key combination on the specified window if it was grabbed
by this client.
It has no effect on an active grab.
A modifiers of
AnyModifier
is equivalent to issuing
the request for all possible modifier combinations
(including the combination of no modifiers).
A keycode argument of
AnyKey
is equivalent to issuing the request for all possible key codes.
can generate
BadValue
and
BadWindow
errors.
Resuming Event Processing
The previous sections discussed grab mechanisms with which processing
of events by the server can be temporarily suspended. This section
describes the mechanism for resuming event processing.
To allow further events to be processed when the device has been frozen, use
.
XAllowEvents
XAllowEvents
Display *display
int event_mode
Time time
display
Specifies the connection to the X server.
event_mode
Specifies the event mode.
You can pass
AsyncPointer,
SyncPointer,
AsyncKeyboard,
SyncKeyboard,
ReplayPointer,
ReplayKeyboard,
AsyncBoth,
or
SyncBoth.
time
Specifies the time.
You can pass either a timestamp or
CurrentTime.
The
function releases some queued events if the client has caused a device
to freeze.
It has no effect if the specified time is earlier than the last-grab
time of the most recent active grab for the client or if the specified time
is later than the current X server time.
Depending on the event_mode argument, the following occurs:
AsyncPointer
If the pointer is frozen by the client,
pointer event processing continues as usual.
If the pointer is frozen twice by the client on behalf of two separate grabs,
AsyncPointer
thaws for both.
AsyncPointer
has no effect if the pointer is not frozen by the client,
but the pointer need not be grabbed by the client.
SyncPointer
If the pointer is frozen and actively grabbed by the client,
pointer event processing continues as usual until the next
ButtonPress
or
ButtonRelease
event is reported to the client.
At this time,
the pointer again appears to freeze.
However, if the reported event causes the pointer grab to be released,
the pointer does not freeze.
SyncPointer
has no effect if the pointer is not frozen by the client
or if the pointer is not grabbed by the client.
ReplayPointer
If the pointer is actively grabbed by the client and is frozen as the result of
an event having been sent to the client (either from the activation of an
or from a previous
with mode
SyncPointer
but not from an
),
the pointer grab is released and that event is completely reprocessed.
This time, however, the function ignores any passive grabs at or above
(toward the root of) the grab_window of the grab just released.
The request has no effect if the pointer is not grabbed by the client
or if the pointer is not frozen as the result of an event.
AsyncKeyboard
If the keyboard is frozen by the client,
keyboard event processing continues as usual.
If the keyboard is frozen twice by the client on behalf of two separate grabs,
AsyncKeyboard
thaws for both.
AsyncKeyboard
has no effect if the keyboard is not frozen by the client,
but the keyboard need not be grabbed by the client.
SyncKeyboard
If the keyboard is frozen and actively grabbed by the client,
keyboard event processing continues as usual until the next
KeyPress
or
KeyRelease
event is reported to the client.
At this time,
the keyboard again appears to freeze.
However, if the reported event causes the keyboard grab to be released,
the keyboard does not freeze.
SyncKeyboard
has no effect if the keyboard is not frozen by the client
or if the keyboard is not grabbed by the client.
ReplayKeyboard
If the keyboard is actively grabbed by the client and is frozen
as the result of an event having been sent to the client (either from the
activation of an
or from a previous
with mode
SyncKeyboard
but not from an
),
the keyboard grab is released and that event is completely reprocessed.
This time, however, the function ignores any passive grabs at or above
(toward the root of)
the grab_window of the grab just released.
The request has no effect if the keyboard is not grabbed by the client
or if the keyboard is not frozen as the result of an event.
SyncBoth
If both pointer and keyboard are frozen by the client,
event processing for both devices continues as usual until the next
ButtonPress,
ButtonRelease,
KeyPress,
or
KeyRelease
event is reported to the client for a grabbed device
(button event for the pointer, key event for the keyboard),
at which time the devices again appear to freeze.
However, if the reported event causes the grab to be released,
then the devices do not freeze (but if the other device is still
grabbed, then a subsequent event for it will still cause both devices
to freeze).
SyncBoth
has no effect unless both pointer and keyboard
are frozen by the client.
If the pointer or keyboard is frozen twice
by the client on behalf of two separate grabs,
SyncBoth
thaws for both (but a subsequent freeze for
SyncBoth
will only freeze each device once).
AsyncBoth
If the pointer and the keyboard are frozen by the
client, event processing for both devices continues as usual.
If a device is frozen twice by the client on behalf of two separate grabs,
AsyncBoth
thaws for both.
AsyncBoth
has no effect unless both
pointer and keyboard are frozen by the client.
AsyncPointer,
SyncPointer,
and
ReplayPointer
have no effect on the
processing of keyboard events.
AsyncKeyboard,
SyncKeyboard,
and
ReplayKeyboard
have no effect on the
processing of pointer events.
It is possible for both a pointer grab and a keyboard grab (by the same
or different clients) to be active simultaneously.
If a device is frozen on behalf of either grab,
no event processing is performed for the device.
It is possible for a single device to be frozen because of both grabs.
In this case,
the freeze must be released on behalf of both grabs before events can
again be processed.
If a device is frozen twice by a single client,
then a single
releases both.
can generate a
BadValue
error.
Moving the Pointer
Although movement of the pointer normally should be left to the
control of the end user, sometimes it is necessary to move the
pointer to a new position under program control.
To move the pointer to an arbitrary point in a window, use
.
XWarpPointer
XWarpPointer
Display *display
Windowsrc_w, dest_w
intsrc_x, src_y
unsignedintsrc_width, src_height
intdest_x, dest_y
display
Specifies the connection to the X server.
src_w
Specifies the source window or
None.
dest_w
Specifies the destination window or
None.
src_x
src_y
src_width
src_height
Specify a rectangle in the source window.
dest_x
dest_y
Specify the x and y coordinates within the destination window.
If dest_w is
None,
moves the pointer by the offsets (dest_x, dest_y) relative to the current
position of the pointer.
If dest_w is a window,
moves the pointer to the offsets (dest_x, dest_y) relative to the origin of
dest_w.
However, if src_w is a window,
the move only takes place if the window src_w contains the pointer
and if the specified rectangle of src_w contains the pointer.
The src_x and src_y coordinates are relative to the origin of src_w.
If src_height is zero,
it is replaced with the current height of src_w minus src_y.
If src_width is zero,
it is replaced with the current width of src_w minus src_x.
There is seldom any reason for calling this function.
The pointer should normally be left to the user.
If you do use this function, however, it generates events just as if the user
had instantaneously moved the pointer from one position to another.
Note that you cannot use
to move the pointer outside the confine_to window of an active pointer grab.
An attempt to do so will only move the pointer as far as the closest edge of the
confine_to window.
can generate a
BadWindow
error.
Controlling Input Focus
Xlib provides functions that you can use to set and get the input focus.
The input focus is a shared resource, and cooperation among clients is
required for correct interaction. See the
Inter-Client Communication Conventions Manual
for input focus policy.
To set the input focus, use
.
XSetInputFocus
XSetInputFocus
Display *display
Window focus
int revert_to
Time time
display
Specifies the connection to the X server.
focus
Specifies the window,
PointerRoot,
or
None.
revert_to
Specifies where the input focus reverts to if the window becomes not
viewable.
You can pass
RevertToParent,
RevertToPointerRoot,
or
RevertToNone.
time
Specifies the time.
You can pass either a timestamp or
CurrentTime.
The
function changes the input focus and the last-focus-change time.
It has no effect if the specified time is earlier than the current
last-focus-change time or is later than the current X server time.
Otherwise, the last-focus-change time is set to the specified time
(CurrentTime
is replaced by the current X server time).
causes the X server to generate
FocusIn
and
FocusOut
events.
Depending on the focus argument,
the following occurs:
If focus is
None,
all keyboard events are discarded until a new focus window is set,
and the revert_to argument is ignored.
If focus is a window,
it becomes the keyboard's focus window.
If a generated keyboard event would normally be reported to this window
or one of its inferiors, the event is reported as usual.
Otherwise, the event is reported relative to the focus window.
If focus is
PointerRoot,
the focus window is dynamically taken to be the root window of whatever screen
the pointer is on at each keyboard event.
In this case, the revert_to argument is ignored.
The specified focus window must be viewable at the time
is called,
or a
BadMatch
error results.
If the focus window later becomes not viewable,
the X server
evaluates the revert_to argument to determine the new focus window as follows:
If revert_to is
RevertToParent,
the focus reverts to the parent (or the closest viewable ancestor),
and the new revert_to value is taken to be
RevertToNone.
If revert_to is
RevertToPointerRoot
or
RevertToNone,
the focus reverts to
PointerRoot
or
None,
respectively.
When the focus reverts,
the X server generates
FocusIn
and
FocusOut
events, but the last-focus-change time is not affected.
can generate
BadMatch,
BadValue,
and
BadWindow
errors.
To obtain the current input focus, use
.
XGetInputFocus
XGetInputFocus
Display *display
Window *focus_return
int *revert_to_return
display
Specifies the connection to the X server.
focus_return
Returns the focus window,
PointerRoot,
or
None.
revert_to_return
Returns the current focus state
(RevertToParent,
RevertToPointerRoot,
or
RevertToNone).
The
function returns the focus window and the current focus state.
Manipulating the Keyboard and Pointer Settings
Xlib provides functions that you can use to
change the keyboard control, obtain a list of the auto-repeat keys,
turn keyboard auto-repeat on or off, ring the bell,
set or obtain the pointer button or keyboard mapping,
and obtain a bit vector for the keyboard.
Keyboardbell volume
Keyboardkeyclick volume
Keyboardbit vector
Mouseprogramming
This section discusses
the user-preference options of bell, key click,
pointer behavior, and so on.
The default values for many of these options are server dependent.
Not all implementations will actually be able to control all of these
parameters.
The
function changes control of a keyboard and operates on a
XKeyboardControl
structure:
/* Mask bits for ChangeKeyboardControl */
#define KBBellPercent (1L<<0)
#define KBBellPitch (1L<<1)
#define KBBellDuration (1L<<2)
#define KBLed (1L<<3)
#define KBLedMode (1L<<4)
#define KBKey (1L<<5)
#define KBAutoRepeatMode (1L<<6)
/* Values */
typedef struct {
int key_click_percent;
int bell_percent;
int bell_pitch;
int bell_duration;
int led;
int led_mode; /* LedModeOn, LedModeOff */
int key;
int auto_repeat_mode; /* AutoRepeatModeOff, AutoRepeatModeOn,
AutoRepeatModeDefault */
} XKeyboardControl;
The key_click_percent member sets the volume for key clicks between 0 (off)
and 100 (loud) inclusive, if possible.
A setting of -1 restores the default.
Other negative values generate a
BadValue
error.
The bell_percent sets the base volume for the bell between 0 (off) and 100
(loud) inclusive, if possible.
A setting of -1 restores the default.
Other negative values generate a
BadValue
error.
The bell_pitch member sets the pitch (specified in Hz) of the bell, if possible.
A setting of -1 restores the default.
Other negative values generate a
BadValue
error.
The bell_duration member sets the duration of the
bell specified in milliseconds, if possible.
A setting of -1 restores the default.
Other negative values generate a
BadValue
error.
If both the led_mode and led members are specified,
the state of that LED is changed, if possible.
The led_mode member can be set to
LedModeOn
or
LedModeOff.
If only led_mode is specified, the state of
all LEDs are changed, if possible.
At most 32 LEDs numbered from one are supported.
No standard interpretation of LEDs is defined.
If led is specified without led_mode, a
BadMatch
error results.
If both the auto_repeat_mode and key members are specified,
the auto_repeat_mode of that key is changed (according to
AutoRepeatModeOn,
AutoRepeatModeOff,
or
AutoRepeatModeDefault),
if possible.
If only auto_repeat_mode is
specified, the global auto_repeat_mode for the entire keyboard is
changed, if possible, and does not affect the per-key settings.
If a key is specified without an auto_repeat_mode, a
BadMatch
error results.
Each key has an individual mode of whether or not it should auto-repeat
and a default setting for the mode.
In addition,
there is a global mode of whether auto-repeat should be enabled or not
and a default setting for that mode.
When global mode is
AutoRepeatModeOn,
keys should obey their individual auto-repeat modes.
When global mode is
AutoRepeatModeOff,
no keys should auto-repeat.
An auto-repeating key generates alternating
KeyPress
and
KeyRelease
events.
When a key is used as a modifier,
it is desirable for the key not to auto-repeat,
regardless of its auto-repeat setting.
A bell generator connected with the console but not directly on a
keyboard is treated as if it were part of the keyboard.
The order in which controls are verified and altered is server-dependent.
If an error is generated, a subset of the controls may have been altered.
XChangeKeyboardControl
XChangeKeyboardControl
Display *display
unsignedlong value_mask
XKeyboardControl *values
display
Specifies the connection to the X server.
value_mask
Specifies which controls to change.
This mask is the bitwise inclusive OR of the valid control mask bits.
values
Specifies one value for each bit set to 1 in the mask.
The
function controls the keyboard characteristics defined by the
XKeyboardControl
structure.
The value_mask argument specifies which values are to be changed.
can generate
BadMatch
and
BadValue
errors.
To obtain the current control values for the keyboard, use
.
XGetKeyboardControl
XGetKeyboardControl
Display *display
XKeyboardState *values_return
display
Specifies the connection to the X server.
values_return
Returns the current keyboard controls in the specified
XKeyboardState
structure.
The
function returns the current control values for the keyboard to the
XKeyboardState
structure.
XGetKeyboardControl
XKeyboardState
typedef struct {
int key_click_percent;
int bell_percent;
unsigned int bell_pitch, bell_duration;
unsigned long led_mask;
int global_auto_repeat;
char auto_repeats[32];
} XKeyboardState;
For the LEDs,
the least significant bit of led_mask corresponds to LED one,
and each bit set to 1 in led_mask indicates an LED that is lit.
The global_auto_repeat member can be set to
AutoRepeatModeOn
or
AutoRepeatModeOff.
The auto_repeats member is a bit vector.
Each bit set to 1 indicates that auto-repeat is enabled
for the corresponding key.
The vector is represented as 32 bytes.
Byte N (from 0) contains the bits for keys 8N to 8N + 7
with the least significant bit in the byte representing key 8N.
To turn on keyboard auto-repeat, use
.
XAutoRepeatOn
XAutoRepeatOn
Display *display
display
Specifies the connection to the X server.
The
function turns on auto-repeat for the keyboard on the specified display.
To turn off keyboard auto-repeat, use
.
XAutoRepeatOff
XAutoRepeatOff
Display *display
display
Specifies the connection to the X server.
The
function turns off auto-repeat for the keyboard on the specified display.
To ring the bell, use
.
XBell
XBell
Display *display
int percent
display
Specifies the connection to the X server.
percent
Specifies the volume for the bell,
which can range from -100 to 100 inclusive.
The
function rings the bell on the keyboard on the specified display, if possible.
The specified volume is relative to the base volume for the keyboard.
If the value for the percent argument is not in the range -100 to 100
inclusive, a
BadValue
error results.
The volume at which the bell rings
when the percent argument is nonnegative is:
base - [(base * percent) / 100] + percent
The volume at which the bell rings
when the percent argument is negative is:
base + [(base * percent) / 100]
To change the base volume of the bell, use
.
can generate a
BadValue
error.
To obtain a bit vector that describes the state of the keyboard, use
.
XQueryKeymap
XQueryKeymap
Display *display
char keys_return[32]
display
Specifies the connection to the X server.
keys_return
Returns an array of bytes that identifies which keys are pressed down.
Each bit represents one key of the keyboard.
The
function returns a bit vector for the logical state of the keyboard,
where each bit set to 1 indicates that the corresponding key is currently
pressed down.
The vector is represented as 32 bytes.
Byte N (from 0) contains the bits for keys 8N to 8N + 7
with the least significant bit in the byte representing key 8N.
Note that the logical state of a device (as seen by client applications)
may lag the physical state if device event processing is frozen.
To set the mapping of the pointer buttons, use
.
XSetPointerMapping
int XSetPointerMapping
Display *display
unsignedchar map[]
int nmap
display
Specifies the connection to the X server.
map
Specifies the mapping list.
nmap
Specifies the number of items in the mapping list.
The
function sets the mapping of the pointer.
If it succeeds, the X server generates a
MappingNotify
event, and
returns
MappingSuccess.
Element map[i] defines the logical button number for the physical button
i+1.
The length of the list must be the same as
would return,
or a
BadValue
error results.
A zero element disables a button, and elements are not restricted in
value by the number of physical buttons.
However, no two elements can have the same nonzero value,
or a
BadValue
error results.
If any of the buttons to be altered are logically in the down state,
returns
MappingBusy,
and the mapping is not changed.
can generate a
BadValue
error.
To get the pointer mapping, use
.
XGetPointerMapping
int XGetPointerMapping
Display *display
unsignedchar map_return[]
int nmap
display
Specifies the connection to the X server.
map_return
Returns the mapping list.
nmap
Specifies the number of items in the mapping list.
The
function returns the current mapping of the pointer.
Pointer buttons are numbered starting from one.
returns the number of physical buttons actually on the pointer.
The nominal mapping for a pointer is map[i]=i+1.
The nmap argument specifies the length of the array where the pointer
mapping is returned, and only the first nmap elements are returned
in map_return.
To control the pointer's interactive feel, use
.
XChangePointerControl
XChangePointerControl
Display *display
Booldo_accel, do_threshold
intaccel_numerator, accel_denominator
int threshold
display
Specifies the connection to the X server.
do_accel
Specifies a Boolean value that controls whether the values for
the accel_numerator or accel_denominator are used.
do_threshold
Specifies a Boolean value that controls whether the value for the
threshold is used.
accel_numerator
Specifies the numerator for the acceleration multiplier.
accel_denominator
Specifies the denominator for the acceleration multiplier.
threshold
Specifies the acceleration threshold.
The
function defines how the pointing device moves.
The acceleration, expressed as a fraction, is a
multiplier for movement.
For example,
specifying 3/1 means the pointer moves three times as fast as normal.
The fraction may be rounded arbitrarily by the X server.
Acceleration
only takes effect if the pointer moves more than threshold pixels at
once and only applies to the amount beyond the value in the threshold argument.
Setting a value to -1 restores the default.
The values of the do_accel and do_threshold arguments must be
True
for the pointer values to be set,
or the parameters are unchanged.
Negative values (other than -1) generate a
BadValue
error, as does a zero value
for the accel_denominator argument.
can generate a
BadValue
error.
To get the current pointer parameters, use
.
XGetPointerControl
XGetPointerControl
Display *display
int*accel_numerator_return, *accel_denominator_return
int *threshold_return
display
Specifies the connection to the X server.
accel_numerator_return
Returns the numerator for the acceleration multiplier.
accel_denominator_return
Returns the denominator for the acceleration multiplier.
threshold_return
Returns the acceleration threshold.
The
function returns the pointer's current acceleration multiplier
and acceleration threshold.
Manipulating the Keyboard Encoding
A KeyCode represents a physical (or logical) key.
KeyCodes lie in the inclusive range [8,255].
A KeyCode value carries no intrinsic information,
although server implementors may attempt to encode geometry
(for example, matrix) information in some fashion so that it can
be interpreted in a server-dependent fashion.
The mapping between keys and KeyCodes cannot be changed.
A KeySym is an encoding of a symbol on the cap of a key.
The set of defined KeySyms includes the ISO Latin character sets (1-4),
Katakana, Arabic, Cyrillic, Greek, Technical,
Special, Publishing, APL, Hebrew, Thai, Korean
and a miscellany of keys found
on keyboards (Return, Help, Tab, and so on).
To the extent possible, these sets are derived from international
standards.
In areas where no standards exist,
some of these sets are derived from Digital Equipment Corporation standards.
The list of defined symbols can be found in
.
Files
Headers
Unfortunately, some C preprocessors have
limits on the number of defined symbols.
If you must use KeySyms not
in the Latin 1-4, Greek, and miscellaneous classes,
you may have to define a symbol for those sets.
Most applications usually only include
,
Files
Headers
which defines symbols for ISO Latin 1-4, Greek, and miscellaneous.
A list of KeySyms is associated with each KeyCode.
The list is intended to convey the set of symbols on the corresponding key.
If the list (ignoring trailing
NoSymbol
entries) is
a single KeySym ``K'',
then the list is treated as if it were the list
``K NoSymbol K NoSymbol''.
If the list (ignoring trailing
NoSymbol
entries) is a pair of KeySyms ``K1 K2'',
then the list is treated as if it were the list ``K1 K2 K1 K2''.
If the list (ignoring trailing
NoSymbol
entries) is a triple of KeySyms ``K1 K2 K3'',
then the list is treated as if it were the list ``K1 K2 K3 NoSymbol''.
When an explicit ``void'' element is desired in the list,
the value
VoidSymbol
can be used.
The first four elements of the list are split into two groups of KeySyms.
Group 1 contains the first and second KeySyms;
Group 2 contains the third and fourth KeySyms.
Within each group,
if the second element of the group is
NoSymbol,
then the group should be treated as if the second element were
the same as the first element,
except when the first element is an alphabetic KeySym ``K''
for which both lowercase and uppercase forms are defined.
In that case,
the group should be treated as if the first element were
the lowercase form of ``K'' and the second element were
the uppercase form of ``K''.
The standard rules for obtaining a KeySym from a
KeyPress
event make use of only the Group 1 and Group 2 KeySyms;
no interpretation of other KeySyms in the list is given.
Which group to use is determined by the modifier state.
Switching between groups is controlled by the KeySym named MODE SWITCH,
by attaching that KeySym to some KeyCode and attaching
that KeyCode to any one of the modifiers
Mod1
through
Mod5.
This modifier is called the group modifier.
For any KeyCode,
Group 1 is used when the group modifier is off,
and Group 2 is used when the group modifier is on.
The
Lock
modifier is interpreted as CapsLock when the KeySym named XK_Caps_Lock
is attached to some KeyCode and that KeyCode is attached to the
Lock
modifier. The
Lock
modifier is interpreted as ShiftLock when the KeySym named XK_Shift_Lock
is attached to some KeyCode and that KeyCode is attached to the
Lock
modifier. If the
Lock
modifier could be interpreted as both
CapsLock and ShiftLock, the CapsLock interpretation is used.
The operation of keypad keys is controlled by the KeySym named XK_Num_Lock,
by attaching that KeySym to some KeyCode and attaching that KeyCode to any
one of the modifiers
Mod1
through
Mod5.
This modifier is called the
numlock modifier. The standard KeySyms with the prefix ``XK_KP_''
in their
name are called keypad KeySyms; these are KeySyms with numeric value in
the hexadecimal range 0xFF80 to 0xFFBD inclusive. In addition,
vendor-specific KeySyms in the hexadecimal range 0x11000000 to 0x1100FFFF
are also keypad KeySyms.
Within a group, the choice of KeySym is determined by applying the first
rule that is satisfied from the following list:
The numlock modifier is on and the second KeySym is a keypad KeySym. In
this case, if the
Shift
modifier is on, or if the
Lock
modifier is on and
is interpreted as ShiftLock, then the first KeySym is used, otherwise the
second KeySym is used.
The
Shift
and
Lock
modifiers are both off. In this case, the first
KeySym is used.
The
Shift
modifier is off, and the
Lock
modifier is on and is
interpreted as CapsLock. In this case, the first KeySym is used, but if
that KeySym is lowercase alphabetic, then the corresponding uppercase
KeySym is used instead.
The
Shift
modifier is on, and the
Lock
modifier is on and is interpreted
as CapsLock. In this case, the second KeySym is used, but if that KeySym
is lowercase alphabetic, then the corresponding uppercase KeySym is used
instead.
The
Shift
modifier is on, or the
Lock
modifier is on and is interpreted
as ShiftLock, or both. In this case, the second KeySym is used.
No spatial geometry of the symbols on the key is defined by
their order in the KeySym list,
although a geometry might be defined on a
server-specific basis.
The X server does not use the mapping between KeyCodes and KeySyms.
Rather, it merely stores it for reading and writing by clients.
To obtain the legal KeyCodes for a display, use
.
XDisplayKeycodes
XDisplayKeycodes
Display *display
int*min_keycodes_return, *max_keycodes_return
display
Specifies the connection to the X server.
min_keycodes_return
Returns the minimum number of KeyCodes.
max_keycodes_return
Returns the maximum number of KeyCodes.
The
function returns the min-keycodes and max-keycodes supported by the
specified display.
The minimum number of KeyCodes returned is never less than 8,
and the maximum number of KeyCodes returned is never greater than 255.
Not all KeyCodes in this range are required to have corresponding keys.
To obtain the symbols for the specified KeyCodes, use
.
XGetKeyboardMapping
KeySym *XGetKeyboardMapping
Display *display
KeyCode first_keycode
int keycode_count
int *keysyms_per_keycode_return
display
Specifies the connection to the X server.
first_keycode
Specifies the first KeyCode that is to be (Kc.
keycode_count
Specifies the number of KeyCodes that are to be returned.
keysyms_per_keycode_return
Returns the number of KeySyms per KeyCode.
The
function returns the symbols for the specified number of KeyCodes
starting with first_keycode.
The value specified in first_keycode must be greater than
or equal to min_keycode as returned by
,
or a
BadValue
error results.
In addition, the following expression must be less than or equal
to max_keycode as returned by
:
first_keycode + keycode_count - 1
If this is not the case, a
BadValue
error results.
The number of elements in the KeySyms list is:
keycode_count * keysyms_per_keycode_return
KeySym number N, counting from zero, for KeyCode K has the following index
in the list, counting from zero:
(K - first_code) * keysyms_per_code_return + N
The X server arbitrarily chooses the keysyms_per_keycode_return value
to be large enough to report all requested symbols.
A special KeySym value of
NoSymbol
is used to fill in unused elements for
individual KeyCodes.
To free the storage returned by
,
use
.
can generate a
BadValue
error.
To change the keyboard mapping, use
.
XChangeKeyboardMapping
XChangeKeyboardMapping
Display *display
int first_keycode
int keysyms_per_keycode
KeySym *keysyms
int num_codes
display
Specifies the connection to the X server.
first_keycode
Specifies the first KeyCode that is to be (Kc.
keysyms_per_keycode
Specifies the number of KeySyms per KeyCode.
keysyms
Specifies an array of KeySyms.
num_codes
Specifies the number of KeyCodes that are to be changed.
The
function defines the symbols for the specified number of KeyCodes
starting with first_keycode.
The symbols for KeyCodes outside this range remain unchanged.
The number of elements in keysyms must be:
num_codes * keysyms_per_keycode
The specified first_keycode must be greater than or equal to min_keycode
returned by
,
or a
BadValue
error results.
In addition, the following expression must be less than or equal to
max_keycode as returned by
,
or a
BadValue
error results:
first_keycode + num_codes - 1
KeySym number N, counting from zero, for KeyCode K has the following index
in keysyms, counting from zero:
(K - first_keycode) * keysyms_per_keycode + N
The specified keysyms_per_keycode can be chosen arbitrarily by the client
to be large enough to hold all desired symbols.
A special KeySym value of
NoSymbol
should be used to fill in unused elements
for individual KeyCodes.
It is legal for
NoSymbol
to appear in nontrailing positions
of the effective list for a KeyCode.
generates a
MappingNotify
event.
There is no requirement that the X server interpret this mapping.
It is merely stored for reading and writing by clients.
can generate
BadAlloc
and
BadValue
errors.
The next six functions make use of the
XModifierKeymap
data structure, which contains:
XModifierKeymap
typedef struct {
int max_keypermod; /* This server's max number of keys per modifier */
KeyCode *modifiermap; /* An 8 by max_keypermod array of the modifiers */
} XModifierKeymap;
To create an
XModifierKeymap
structure, use
.
XNewModifiermap
XModifierKeymap *XNewModifiermap
int max_keys_per_mod
max_keys_per_mod
Specifies the number of KeyCode entries preallocated to the modifiers
in the map.
The
function returns a pointer to
XModifierKeymap
structure for later use.
To add a new entry to an
XModifierKeymap
structure, use
.
XInsertModifiermapEntry
XModifierKeymap *XInsertModifiermapEntry
XModifierKeymap *modmap
KeyCode keycode_entry
int modifier
modmap
Specifies the
XModifierKeymap
structure.
keycode_entry
Specifies the KeyCode.
modifier
Specifies the modifier.
The
function adds the specified KeyCode to the set that controls the specified
modifier and returns the resulting
XModifierKeymap
structure (expanded as needed).
To delete an entry from an
XModifierKeymap
structure, use
.
XDeleteModifiermapEntry
XModifierKeymap *XDeleteModifiermapEntry
XModifierKeymap *modmap
KeyCode keycode_entry
int modifier
modmap
Specifies the
XModifierKeymap
structure.
keycode_entry
Specifies the KeyCode.
modifier
Specifies the modifier.
The
function deletes the specified KeyCode from the set that controls the
specified modifier and returns a pointer to the resulting
XModifierKeymap
structure.
To destroy an
XModifierKeymap
structure, use
.
XFreeModifiermap
XFreeModifiermap
XModifierKeymap *modmap
modmap
Specifies the
XModifierKeymap
structure.
The
function frees the specified
XModifierKeymap
structure.
To set the KeyCodes to be used as modifiers, use
.
XSetModifierMapping
int XSetModifierMapping
Display *display
XModifierKeymap *modmap
display
Specifies the connection to the X server.
modmap
Specifies the
XModifierKeymap
structure.
The
function specifies the KeyCodes of the keys (if any) that are to be used
as modifiers.
If it succeeds,
the X server generates a
MappingNotify
event, and
returns
MappingSuccess.
X permits at most 8 modifier keys.
If more than 8 are specified in the
XModifierKeymap
structure, a
BadLength
error results.
The modifiermap member of the
XModifierKeymap
structure contains 8 sets of max_keypermod KeyCodes,
one for each modifier in the order
Shift,
Lock,
Control,
Mod1,
Mod2,
Mod3,
Mod4,
and
Mod5.
Only nonzero KeyCodes have meaning in each set,
and zero KeyCodes are ignored.
In addition, all of the nonzero KeyCodes must be in the range specified by
min_keycode and max_keycode in the
Display
structure,
or a
BadValue
error results.
An X server can impose restrictions on how modifiers can be changed,
for example,
if certain keys do not generate up transitions in hardware,
if auto-repeat cannot be disabled on certain keys,
or if multiple modifier keys are not supported.
If some such restriction is violated,
the status reply is
MappingFailed,
and none of the modifiers are changed.
If the new KeyCodes specified for a modifier differ from those
currently defined and any (current or new) keys for that modifier are
in the logically down state,
returns
MappingBusy,
and none of the modifiers is changed.
can generate
BadAlloc
and
BadValue
errors.
To obtain the KeyCodes used as modifiers, use
.
XGetModifierMapping
XModifierKeymap *XGetModifierMapping
Display *display
display
Specifies the connection to the X server.
The
function returns a pointer to a newly created
XModifierKeymap
structure that contains the keys being used as modifiers.
The structure should be freed after use by calling
.
If only zero values appear in the set for any modifier,
that modifier is disabled.