River xkb bindings

此请求表明客户端将不再使用 river_xkb_bindings_v1 对象。

针对给定的 seat，根据 xkbcommon keysym 以及其他可配置属性定义一个键绑定。

新的键绑定不会启用，直到初始配置完成，并在 manage sequence 期间发出 enable 请求为止。

创建一个用于管理特定于 seat 的 xkb bindings 状态的对象。

对给定的 river_seat_v1 对象多次发出此请求属于协议错误。

此请求表明客户端将不再使用 xkb 键绑定对象，该对象可以被安全地销毁。

指定一个应用于转换按键事件的 xkb layout，用于触发此键绑定，而不管当前激活的 xkb layout 是什么。

layout 参数是生成按键事件的键盘的一个从 0 开始索引的 xkbcommon layout 编号。

如果从未发出过此请求，将使用生成按键事件的键盘当前激活的 xkb layout。

此请求会修改窗口管理状态，并且只能作为 manage sequence 的一部分发出，参见 river_window_manager_v1 说明。

该请求应当在所有初始配置完成后，且窗口管理器希望键绑定能够被触发时发出。

此请求会修改窗口管理状态，并且只能作为 manage sequence 的一部分发出，参见 river_window_manager_v1 说明。

此请求可用于暂时禁用键绑定。稍后可以通过 enable 请求重新启用。

此请求会修改窗口管理状态，并且只能作为 manage sequence 的一部分发出，参见 river_window_manager_v1 说明。

此事件表明触发该绑定的物理按键已被按下。

在服务器发送所有其他新状态之后，此事件随后会发出 manage_start 事件。

compositor 应该在处理进一步输入事件之前等待 manage sequence 完成。这允许窗口管理器客户端（例如）修改键绑定和键盘焦点，而不会与未来的输入事件发生竞争。当然，窗口管理器应该尽快响应，因为 compositor 缓冲传入输入事件的容量是有限的。

此事件表明触发该绑定的物理按键已被释放。

释放绑定的 modifiers（修饰键）而不释放产生绑定 keysym 的“主”物理按键，并不会触发 release 事件。即使自 pressed 事件发出以来 modifiers 发生了变化，此事件也会在“主”按键被释放时发出。

在服务器发送所有其他新状态之后，此事件随后会发出 manage_start 事件。

compositor 应该在处理进一步输入事件之前等待 manage sequence 完成。这允许窗口管理器客户端（例如）修改键绑定和键盘焦点，而不会与未来的输入事件发生竞争。当然，窗口管理器应该尽快响应，因为 compositor 缓冲传入输入事件的容量是有限的。

此事件表明，如果在 pressed 事件发生后，窗口管理器一直在 repeat（重复执行）某些操作，则应该针对该绑定停止 repeat。

此事件通常在发出此绑定的 pressed 事件之后，且尚未发出 released 事件之前，有其他（可能是未绑定的）按键被按下时发送。

在服务器发送所有其他新状态之后，此事件随后会发出 manage_start 事件。

此请求表明客户端将不再使用该对象，并且它可以被安全地销毁。

确保此 seat 的下一个非 modifier（非修饰键）按键事件及相应的 release 事件不被发送到当前聚焦的 surface。

如果下一个非 modifier 按键触发了某个绑定，pressed/released 事件将如常发送给 river_xkb_binding_v1 对象。

如果下一个非 modifier 按键并未触发绑定，则会转而发送 ate_unbound_key 事件。

原理：窗口管理器可能希望实现“和弦（chorded）”键绑定，即触发一个绑定时，会激活一个带有不同键绑定集的“submap（子映射）”。如果没有机制去吞噬（eat）下一个按键事件，那么当在 submap 中按下了未绑定的按键时，窗口管理器就没有好的办法知晓它应当报错并退出 submap。

此请求会修改窗口管理状态，并且只能作为 manage sequence 的一部分发出，参见 river_window_manager_v1 说明。

如果由于该请求尚未有按键被吞噬 (eaten)，此请求将取消最近的 ensure_next_key_eaten 请求的作用。如果已有按键被吞噬或者根本没有发起过 ensure_next_key_eaten 请求，则此请求无效。

原理：窗口管理器可能希望在几秒钟超时后取消未完成的“和弦”键绑定。请注意，因为这种超时的用例要求窗口管理器使用 river_window_manager_v1.manage_dirty 请求触发 manage sequence，所以在窗口管理器有机会发出 cancel_ensure_next_key_eaten 请求之前，可能已经发送了 ate_unbound_key 事件。

此请求会修改窗口管理状态，并且只能作为 manage sequence 的一部分发出，参见 river_window_manager_v1 说明。

由于 ensure_next_key_eaten 请求，一个未绑定的按键事件被吞噬了。

在服务器发送所有其他新状态之后，此事件随后会发出 manage_start 事件。