1xcb_allow_events(3) XCB Requests xcb_allow_events(3)
2
6 xcb_allow_events - release queued events
7
9 #include <xcb/xproto.h>
10 Request function
12 xcb_void_cookie_t xcb_allow_events(xcb_connection_t *conn,
13 uint8_t mode, xcb_timestamp_t time);
14
16 conn The XCB connection to X11.
17 mode One of the following values:
19 XCB_ALLOW_ASYNC_POINTER
21 For AsyncPointer, if the pointer is frozen by the
22 client, pointer event processing continues normal‐
23 ly. If the pointer is frozen twice by the client on
24 behalf of two separate grabs, AsyncPointer thaws
25 for both. AsyncPointer has no effect if the pointer
26 is not frozen by the client, but the pointer need
27 not be grabbed by the client.
28 TODO: rewrite this in more understandable terms.
30 XCB_ALLOW_SYNC_POINTER
32 For SyncPointer, if the pointer is frozen and ac‐
33 tively grabbed by the client, pointer event pro‐
34 cessing continues normally until the next Button‐
35 Press or ButtonRelease event is reported to the
36 client, at which time the pointer again appears to
37 freeze. However, if the reported event causes the
38 pointer grab to be released, then the pointer does
39 not freeze. SyncPointer has no effect if the point‐
40 er is not frozen by the client or if the pointer is
41 not grabbed by the client.
42 XCB_ALLOW_REPLAY_POINTER
44 For ReplayPointer, if the pointer is actively
45 grabbed by the client and is frozen as the result
46 of an event having been sent to the client (either
47 from the activation of a GrabButton or from a pre‐
48 vious AllowEvents with mode SyncPointer but not
49 from a GrabPointer), then the pointer grab is re‐
50 leased and that event is completely reprocessed,
51 this time ignoring any passive grabs at or above
52 (towards the root) the grab-window of the grab just
53 released. The request has no effect if the pointer
54 is not grabbed by the client or if the pointer is
55 not frozen as the result of an event.
56 XCB_ALLOW_ASYNC_KEYBOARD
58 For AsyncKeyboard, if the keyboard is frozen by the
59 client, keyboard event processing continues normal‐
60 ly. If the keyboard is frozen twice by the client
61 on behalf of two separate grabs, AsyncKeyboard
62 thaws for both. AsyncKeyboard has no effect if the
63 keyboard is not frozen by the client, but the key‐
64 board need not be grabbed by the client.
65 XCB_ALLOW_SYNC_KEYBOARD
67 For SyncKeyboard, if the keyboard is frozen and ac‐
68 tively grabbed by the client, keyboard event pro‐
69 cessing continues normally until the next KeyPress
70 or KeyRelease event is reported to the client, at
71 which time the keyboard again appears to freeze.
72 However, if the reported event causes the keyboard
73 grab to be released, then the keyboard does not
74 freeze. SyncKeyboard has no effect if the keyboard
75 is not frozen by the client or if the keyboard is
76 not grabbed by the client.
77 XCB_ALLOW_REPLAY_KEYBOARD
79 For ReplayKeyboard, if the keyboard is actively
80 grabbed by the client and is frozen as the result
81 of an event having been sent to the client (either
82 from the activation of a GrabKey or from a previous
83 AllowEvents with mode SyncKeyboard but not from a
84 GrabKeyboard), then the keyboard grab is released
85 and that event is completely reprocessed, this time
86 ignoring any passive grabs at or above (towards the
87 root) the grab-window of the grab just released.
88 The request has no effect if the keyboard is not
89 grabbed by the client or if the keyboard is not
90 frozen as the result of an event.
91 XCB_ALLOW_ASYNC_BOTH
93 For AsyncBoth, if the pointer and the keyboard are
94 frozen by the client, event processing for both de‐
95 vices continues normally. If a device is frozen
96 twice by the client on behalf of two separate
97 grabs, AsyncBoth thaws for both. AsyncBoth has no
98 effect unless both pointer and keyboard are frozen
99 by the client.
100 XCB_ALLOW_SYNC_BOTH
102 For SyncBoth, if both pointer and keyboard are
103 frozen by the client, event processing (for both
104 devices) continues normally until the next Button‐
105 Press, ButtonRelease, KeyPress, or KeyRelease event
106 is reported to the client for a grabbed device
107 (button event for the pointer, key event for the
108 keyboard), at which time the devices again appear
109 to freeze. However, if the reported event causes
110 the grab to be released, then the devices do not
111 freeze (but if the other device is still grabbed,
112 then a subsequent event for it will still cause
113 both devices to freeze). SyncBoth has no effect un‐
114 less both pointer and keyboard are frozen by the
115 client. If the pointer or keyboard is frozen twice
116 by the client on behalf of two separate grabs,
117 SyncBoth thaws for both (but a subsequent freeze
118 for SyncBoth will only freeze each device once).
119 time Timestamp to avoid race conditions when running X over the
123 network.
124 The special value XCB_CURRENT_TIME will be replaced with the
126 current server time.
127
129 Releases queued events if the client has caused a device (pointer/key‐
130 board) to freeze due to grabbing it actively. This request has no ef‐
131 fect if time is earlier than the last-grab time of the most recent ac‐
132 tive grab for this client or if time is later than the current X server
133 time.
134
136 Returns an xcb_void_cookie_t. Errors (if any) have to be handled in the
137 event loop.
138 If you want to handle errors directly with xcb_request_check instead,
140 use xcb_allow_events_checked. See xcb-requests(3) for details.
141
143 xcb_value_error_t
144 You specified an invalid mode.
145
147 xcb-requests(3)
148
150 Generated from xproto.xml. Contact xcb@lists.freedesktop.org for cor‐
151 rections and improvements.
152X Version 11 libxcb 1.13 xcb_allow_events(3)