2 个不稳定版本
0.2.0 | 2022 年 3 月 6 日 |
---|---|
0.1.0 | 2022 年 3 月 5 日 |
#1275 in 硬件支持
74KB
2K SLoC
qsk (又名量子软键盘)
你从未意识到的键盘重映射软件。
受开源键盘固件项目 QMK 启发,qsk 的目标是为主机系统上连接的任意键盘启用类似的功能。例如,笔记本电脑上的内置键盘或 1990 年代部门商店桌面计算机中附带的那个糟糕的通用键盘。
功能
- 标准键盘重映射,例如将
F
映射为U
- 由具有特殊功能的键激活的可组合层键映射
- "轻触切换",在给定时间内轻触键将发送其常规按键,并在保持时激活指定的层
与 QMK 的丰富功能集相比,此功能集仍然相当小。按需实现功能 -- 欢迎贡献!
使用(目前仅限 Linux)
尝试示例重映射器
安装
cargo install qsk
获取可用设备列表
qsk list-devices
在确定要使用的设备后,运行重映射器
sudo qsk remap /path/to/device-file
注意:上面需要 sudo
,因为默认情况下您的 Linux 登录用户没有必要的权限来抓取您选择的键盘输入设备,也不能创建新的虚拟键盘设备,通过该设备发出重映射的按键。
自定义和构建您自己的重映射器
上一节描述了如何使用通过 crates.io 提供的二进制文件,目前无法自定义其键映射。将来,将能够传递一个包含键映射 DSL/脚本的文件路径。目前,键盘重映射定义必须编译在内。为了使这更容易,qsk 提供了一个 cargo-generate
模板,它可以帮助您快速开始创建自己的 qsk 项目
cargo generate --git https://github.com/waynr/qsk.git qsk-template
cargo-generate
将提示您输入值以填充 qsk
模板项目,其中之一将是 "项目名称"。传递给此处的值将是您新 qsk
项目的目录名称。要构建它
cd $PROJECT_NAME
cargo build
获取可用设备列表
./target/debug/$PROJECT_NAME list-devices
在确定要使用的设备后,运行重映射器
sudo ./target/debug/$PROJECT_NAME remap /path/to/device-file
QSK 程序宏重映射 DSL
上述模板生成一个类似以下的 main.rs
use std::error;
use qsk_macros;
use qsk::entrypoint;
fn main() -> Result<(), Box<dyn error::Error>> {
let layer_composer = qsk_macros::remap!(
ModLayer[Active]: {
Y -> HOME,
F -> TapToggle(Navigation, F),
},
Navigation: {
END -> Exit(),
Y -> HOME,
U -> PAGEDOWN,
I -> PAGEUP,
O -> END,
H -> LEFT,
J -> DOWN,
K -> UP,
SEMICOLON -> RIGHT,
},
)?;
entrypoint(layer_composer)?;
Ok(())
}
这演示了 qsk_macros::remap!
宏,它接受一个简化层键盘重映射定义的微型 DSL 作为输入。目前,这的唯一替代方案是在 Rust 中直接定义 qsk_types::LayerComposer
。在您的生成项目中,您只需要更新键映射,保存并构建。
在定义键盘重映射层时,需要注意几个标识符类别
层名称
是如上所示的Navigation
和ModLayer
这样的标识符。这些名称前面有一个冒号和一个可选的方括号组,由键函数使用。例如,在TapToggle
中,Navigation
表示当按下->
左侧的键时,应该激活Navigation
层。层 选项
是如上所示的方括号中的Active
这样的标识符。这些用于配置单个层。键码
是如上所示的K
、END
和UP
这样的标识符。在->
的左侧,键码表示要重映射的 "输入" 键。在->
的右侧,这表示根据左侧的键码将输出哪个键码。键函数
是如上所示的Exit
和TapToggle
这样的标识符。这些只能出现在->
的右侧,并用于赋予左侧对应的键特殊属性。
键函数
TapToggle(<layer_ref>, <tap_key>)
当按下并保持左侧的键时,将激活名为<layer_ref>
的层。当它在默认的轻触切换超时(180 毫秒)内轻触时。Exit()
当按下左侧的键时,程序将优雅地退出。
层选项
Active
表示在程序初始化时应将层设置为 "激活" 状态。
与 QMK 的不同之处
假设您熟悉QMK,您可能想知道这个项目与QMK有何不同。
如果您不熟悉QMK,那么简单来说,它是一款软件,您可以使用它来定制支持键盘的行为,动态改变按键的行为。如果您想了解更多信息,请查看QMK文档网站,但请注意,这可能是一个有点复杂的知识领域。
目标运行时
QMK编译成必须在它支持的特定键盘上加载的固件。因此,它不对主机系统产生资源消耗负担,并最小化了由于(假设)微控制器专有性导致的延迟。
qsk
则相反,它编译成一个必须在接收原始硬件输入事件的宿主系统上运行的二进制文件。
它需要在主机系统上获得必要的权限来
- 抓取现有输入设备的输入,以接收其输入事件。
- 创建一个新的虚拟输入设备,将按键发送到该设备,这些按键可以是它生成的或从源输入设备传递的。
此外,您必须在执行二进制文件时告诉qsk
要抓取哪个源输入设备。
额外的延迟
正如您可以想象的,工具如qsk
在接收到键盘事件和发送相应的可能更改后的键盘事件之间注入非平凡延迟是有可能的。
选择Rust为这个工具,除了满足个人偏好外,其目的是在提供扩展其功能的可能性的同时,安全地最小化延迟。尽管如此,尚未有关于这里涉及延迟的量化研究,但(waynr)我可以证实,它对于日常使用来说似乎并不明显。
重新映射输入事件,而不是实际按键
在qsk
中,我们不是将所需的键盘事件/行为映射到特定的硬件按键,而是映射到其他键盘或输入事件。因此,您必须注意您的物理设备和目标主机OS映射到哪些输入事件,以便有效地重新映射。
未来,我们可能会做一些复杂的事情,比如检查给定输入设备的详细信息,并允许用户通过GUI和输入事件接口提供的默认布局来配置它。我们鼓励在此领域做出贡献!
支持的操作系统
由于qsk
的性质,它很可能需要针对内核/OS进行特定支持,因为这是最自然的API边界,可能在此边界处提供此类接口。
Linux
对于Linux,我们通过evdev
实现设备支持,这是内核提供的一个通用输入事件接口。以下是一个粗略的关系链示例
brain -> fingers -> keyboard -> CPU interrupts -> interrupt handlers (kernel) ->
evdev subsystem (kernel/userspace) -> qsk -> X11 input drivers OR libinput for
Wayland -> your program
请注意,当qsk
连接到某个输入源时,它将“抓取”该输入,从而获得独占读取其事件的权利。
[待办] Mac
我没有苹果电脑,所以实现对这些系统的支持对我来说并不实用。我没有苹果电脑,所以实现对这些系统的支持对我来说并不实用。但我很高兴有人能证明我错了。请鼓励为这些系统实现支持,我会很高兴提供所需的任何指导或帮助!
[待办] Windows
我没有任何Windows电脑,因此对我来说实现对其的支持并不实用。我对它是否像Linux一样容易持怀疑态度,但很高兴有人用Windows证明我是错的。请随时鼓励实现支持,我很乐意提供您需要的或想要的任何指导!
[待办事项] ??
你有一个我不知道的操作系统或计算范式吗?告诉我!
维护者
Wayne Warren是一个普通的日常人物,喜欢用Rust编写软件,他因不满他高度定制的机械键盘固件和他各种笔记本电脑的超级不可定制的内置键盘之间缺乏肌肉记忆兼容性,而驱使他编写了qsk
。
依赖项
~15–27MB
~404K SLoC