xkb 第2章 鍵盤 state

鍵盤 state 的核心協議描述由八個 modifier 組成 （Shift , Lock , Control 和 Mod1 - Mod5 ）。 每當修飾鍵被物理或邏輯地按下時，修飾鍵控制的 modifier 設置到鍵盤的 state 中。

xkb 擴展保留了核心協議定義的 8 個真實 modifiers，但擴展了核心協議鍵盤state 的概念最多包含 4 個 keysym groups。

鎖定和暫鎖 modifiers 和 groups

• 鎖定 （Locked） modifiers 或 groups 應用於全部將來按鍵事件，直到它們被顯式地改變。
• 暫鎖 （Latched）modifiers 和 groups 只應用於下一個不改變鍵盤 state 的按鍵事件。

xkb 鍵盤 state 的基本組件

• modifiers 和 group 的鎖定 state

• modifiers 和 group 的暫鎖 state

• modifiers 和 group 的基本 state （邏輯或物理按下的鍵）

• modifiers 和 group 的有效 state （基本、鎖定、暫鎖 modifier 和 group state 的累積）

• 核心指針按鈕的 state

modifiers 和 groups 的鎖定和暫鎖 state 能夠被鍵盤活動和應用程序使用 LatchLockState 請求修改。 基本 modifier、基本 group 和 指針按鈕的 state 老是反映鍵盤和指針的邏輯狀態，而且僅在響應鍵盤或指針活動時更改。

計算 modifer 和 group 的有效 state

modifiers 的有效 state 是基本、暫鎖、鎖定的按位或（|）。

group 的有效 state 是基本、暫鎖、鎖定的算術和。鎖定和有效 group 必須在 Group1 - Group4 範圍內，所以它們根據全局 GroupsWrap control 被調整到範圍內。

基本和暫鎖 groups 不限制在 8-bit 整數值，且不被 GroupsWrap control 影響。

根據 XKB State 獲得 State

許多事件在單個 state 字段中報告鍵盤 state 。 使用 XKB 時，一個 state 字段組合了 modifiers、groups和指針按鈕 state 到單個 16-bit 值中：

• 0-7 （低8位） 表明 modifiers

• 8-12 表明 指針按鈕 state

• 13-14 兩位無符號數 表明鍵盤 group

• 15 （最高位） 保留，且必須爲0

XKB 鍵盤 state 的派生組件

除了基本 state 組件以外，XKB 還會跟蹤並報告從基本組件派生但分別存儲和報告的多個 state 組件，以便更輕鬆地跟蹤鍵盤 state 的變化。只要任何基本組件發生更改，這些派生組件就會自動更新，但沒法直接修改。

第一對派生的 state 組件控制被動 grabs 被激活的方式和在覈心協議事件中 modifier 被報告的方式。Server 使用 ServerInternalModifiers、 IgnoreLocksModifiers 和 IgnoreGroupLock 控制。派生出以下兩種 state：

• lookup state 是用於肯定按鍵事件相關的符號的 state，由有效 state 減去任何 Server 內部 modifiers 組成。

• grab state 是用於肯定特定事件是否要觸發被動 grab 的 state，由 lookup state 減去 ignore locks modifiers 的任何成員（這些 modifiers 不是暫鎖或邏輯地被按下）組成。若是設置了 ignore group locks control， 則 grab state 不包含任何鎖定group 的效果。

Server 內部 modifiers 和 ignore locks 行爲

核心協議不提供任何從 client 事件中排除某些 modifiers 的方式，所以沒法設置 隻影響 server 的 modifier。

在 InternalMods control 的 mask 中指定的 modifiers 不會在任何核心協議事件中被報告， 不用於肯定 grabs 且不用於爲 XKB-unaware clients 計算兼容 state。 Server 內部 modifiers 隻影響當鍵被按下時被應用的 action。

核心協議沒有提供任何方法從 grab 計算中排除某些modifiers，所以鎖定中的 modifiers 一般會產生意外和不幸的反作用。XKB 提供另外一個 mask 能夠幫助避免這些問題。

在 IgnoreLockMods control 的 mask 中指定的 modifiers 的鎖定 state 不會在大多數核心協議事件中報告，也不會用在激活 grabs。 只有核心協議的 key press 和 release 事件（且不激活被動grab時）包含在 IgnoreLockMods control 的 maks 中指定的 modifiers 的鎖定 state，若是激活 grabs 就不會包含。若是設置了 IgnoreGroupLock control，則當激活被動 grabs 時 group 的鎖定 state 不被考慮。

若是沒有XKB，由快捷鍵（Alt+space）設置的被動 grab 在任何快捷鍵中未指定的 modifier 被設置時不能被激活。致使當 NumLock 或第二鍵盤 group 激活時許多 UI 組件沒有反應。IgnoreLockMods 和 IgnoreGroupLock control 使得能夠避免窮盡抓取每一個可能的 modifier 組合的行爲。

鍵盤 state 的兼容組件

核心協議中鍵盤 modifiers 的解析不包括對多個 groups 的直接支持， 所以 XKB 報告有效 group 給 XKB-aware client 時使用了一些核心協議事件的 state 字段的保留位。

被修改的state字段不能被 XKB-unaware clients 正確解析，所以 XKB 提供了一個 group 兼容性映射，當可能時，它將鍵盤 group 重現映射爲有類似效果的核心 modifier mask。XKB 維護 3個 兼容性 state 組件用於使得非 XKB client 儘量地工做：

• 兼容 state 對應於有效 modifier 和有效 group state。
• 兼容 lookup state 是 lookup state 的核心協議等效的 state。
• 兼容 group state 是最接近 grab state 的核心協議等效的 state 。

兼容性 state 本質上是相應的 XKB state，但鍵盤 group 可能被編碼爲一個或多個 modifiers；

對任何給出的核心協議事件報告給 XKB-unaware clients 的兼容性 state 是從 XKB-capable client 看到的相同事件 modifier state 計算獲得的。 好比，若是設置了 IgnoreGroupLocks control 且 group 2 被鎖定，綁定到 Mode_switch 的 modifier 不會在除了不激活被動 grab 的 (Device)KeyPress 和 (Device)KeyRelase 事件的任何事件被報告。

注意

將客戶稱爲 XKB-Capable 在這種狀況下有些誤導。XKB 的示例實現無形地擴展了 X 庫以使用鍵盤擴展（若是存在）。這意味着大多數client 能夠利用全部 XKB 而無需修改， 但它也意味着能夠向未明確請求鍵盤擴展的客戶端報告 XKB 狀態。直接解釋核心協議事件的 state 字段或直接解釋 keymap 的客戶端可能會受到某些 XKB 差別的影響；client 使用庫或工具包例程來解釋鍵盤事件會自動使用全部 XKB 功能。

XKB-aware client 能夠隨時查詢鍵盤 state 或請求當即知曉鍵盤 state 的任何基本或派生組件的改變。