macos: map Print Screen / Scroll Lock / Pause to F13/F14/F15 - #445
Open
tyvsmith wants to merge 4 commits into
Open
macos: map Print Screen / Scroll Lock / Pause to F13/F14/F15#445tyvsmith wants to merge 4 commits into
tyvsmith wants to merge 4 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a macOS-specific fallback mapping so Linux evdev keys that lack entries in the keycode crate’s evdev→CGKeyCode table (Print Screen / Scroll Lock / Pause) still generate usable key events on macOS by mapping them to the conventional F13/F14/F15 CGKeyCodes.
Changes:
- Add a
scancode::Linux-based fallback forKEY_SYSRQ,KEY_SCROLLLOCK, andKEY_PAUSE. - Map those keys to macOS F13/F14/F15 keycodes (0x69/0x6B/0x71) to enable binding in tools like
skhd.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+459
to
+463
| let code: CGKeyCode = match scancode::Linux::try_from(key) { | ||
| Ok(scancode::Linux::KeySysrq) => 0x69, // F13 | ||
| Ok(scancode::Linux::KeyScrollLock) => 0x6B, // F14 | ||
| Ok(scancode::Linux::KeyPause) => 0x71, // F15 | ||
| _ => match KeyMap::from_key_mapping(KeyMapping::Evdev(key as u16)) { |
3 tasks
tyvsmith
force-pushed
the
fix/macos-missing-keycodes
branch
from
June 27, 2026 19:18
d5b527c to
5bf3269
Compare
Contributor
Author
|
This is now reparented on #449, so once that merges on main, this will merge cleanly without the seemingly duplicated file to the github workflow. |
The keycode crate's Chromium-derived table has no macOS CGKeyCode for these three PC-only keys, so they were silently dropped. Map them to F13/F14/F15 respectively, which is the conventional macOS stand-in for keys that do not exist on Apple keyboards. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Apply rustfmt to fix the failing Formatting CI check. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tyvsmith
force-pushed
the
fix/macos-missing-keycodes
branch
from
July 24, 2026 18:38
5bf3269 to
18d61ff
Compare
Rust 1.97 clippy denies clippy::useless_borrows_in_formatting on the `&self.config_path` arguments in src/config.rs (code inherited from main, not part of this PR). Fixed here so CI passes; this commit can be dropped once main carries the same fix. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The gtk-windows-build cache was evicted, and rebuilding gtk now fails because windows-latest runners only ship Visual Studio 2026 (v18) while gvsbuild defaults to vs2022 (v17): Skipping Visual Studio at "C:\Program Files\Microsoft Visual Studio\18\Enterprise": Doesn't match target Visual Studio version of 17 Error: Unable to find applicable Visual Studio Pass --vs-ver vs2026 so gvsbuild uses the installed toolchain. This is inherited CI breakage, not part of this PR; the commit can be dropped once main carries the same fix. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
keycodecrate's Chromium-derived evdev→CGKeyCode table has no entry for three keys that appear on virtually every standard PC keyboard:KEY_SYSRQ(99) — Print ScreenKEY_SCROLLLOCK(70) — Scroll LockKEY_PAUSE(119) — Pause / BreakWhen a Linux client sends any of these keys, the macOS emulation backend hits the
Err(_)arm and silently drops the event with"unable to map key event".This is reproducible with any software KVM (e.g. lan-mouse itself) where the sending machine is Linux and the receiving machine is macOS: pressing Print Screen on the Linux keyboard produces
keycode: 0xffffon the macOS side with no key event emitted.Fix
Add a fallback match on
scancode::Linuxbefore delegating toKeyMap::from_key_mapping. Maps the three keys to F13/F14/F15 (0x69/0x6B/0x71) respectively — the decades-old macOS convention for PC keys that have no Apple keyboard equivalent.This allows tools on the macOS side (e.g.
skhd) to bind these keys normally, since F13/F14/F15 are well-known CGKeyCodes.Testing
skhd -oreportskeycode: 0x69/0x6B/0x71for each key respectively (previously0xffff)KeyMap::from_key_mappingpath)