blob: 2da16dba4e292340866ec5c52ffdd97712353d7d (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
<chapter id='replacing_the_keyboard_on_the_fly'>
<title>Replacing the Keyboard "On-the-Fly"</title>
<para>
XKB supports the <emphasis>
XkbNewKeyboardNotify</emphasis>
event, which reports a change in keyboard geometry or the range of supported
keycodes. The server can generate an <emphasis>
XkbNewKeyboardNotify</emphasis>
event when it detects a new keyboard, or in response to an <emphasis>
XkbGetKeyboardByName</emphasis>
request (see <link linkend='using_the_servers_database_of_keyboard_components'>Using the Server’s
Database of Keyboard Components</link>) which loads a new keyboard description.
</para>
<para>
When a client opens a connection to the X server, the server reports the
minimum and maximum keycodes. If the range of supported keycodes is changed,
XKB keeps track of the minimum and maximum keycodes that were reported to each
client and filters out any events that fall outside of that range. Note that
these events are simply ignored; they are not delivered to some other client.
</para>
<para>
When the server sends an <emphasis>
XkbNewKeyboardNotify</emphasis>
event to a client to inform it of the new keycode range, XKB resets the stored
range of legal keycodes to the keycode range reported in the event. Non-XKB
clients and XKB-aware clients that do not request <emphasis>
XkbNewKeyboardNotify</emphasis>
events never receive events from keys that fall outside of the legal range
that XKB maintains for that client.
</para>
<para>
When a client requests <emphasis>
XkbNewKeyboardNotify</emphasis>
events, the server compares the range of keycodes for the current keyboard to
the range of keycodes that are valid for the client. If they are not the same,
the server immediately sends that client an <emphasis>
XkbNewKeyboardNotify</emphasis>
event. Even if the "new" keyboard is not new to the server, it is new to this
particular client.
</para>
<para>
In addition to filtering out-of-range key events, XKB:
</para>
<itemizedlist>
<listitem>
<para>Adjusts core protocol <emphasis>
MappingNotify</emphasis>
events to refer only to keys that match the stored legal range.
</para>
</listitem>
<listitem>
<para>Reports keyboard mappings for keys that match the stored legal range to
clients that issue a core protocol <emphasis>
GetKeyboardMapping</emphasis>
request.
</para>
</listitem>
<listitem>
<para>Reports modifier mappings only for keys that match the stored legal
range to clients that issue a core protocol <emphasis>
GetModifierMapping</emphasis>
request.
</para>
</listitem>
<listitem>
<para>Restricts the core protocol <emphasis>
ChangeKeyboardMapping</emphasis>
and <emphasis>
SetModifierMapping</emphasis>
requests to keys that fall inside the stored legal range.
</para>
</listitem>
</itemizedlist>
<para>
In short, XKB does everything possible to hide the fact that the range of legal
keycodes has changed from clients non-XKB clients, which cannot be expected to
deal with it. The corresponding XKB events and requests do <emphasis>
not</emphasis>
pay attention to the legal keycode range in the same way because XKB makes it
possible for clients to track changes to the keycode range for a device and
respond to them.
</para>
</chapter>
|
