macos: map Print Screen / Scroll Lock / Pause to F13/F14/F15#445
Open
tyvsmith wants to merge 1 commit into
Open
macos: map Print Screen / Scroll Lock / Pause to F13/F14/F15#445tyvsmith wants to merge 1 commit into
tyvsmith wants to merge 1 commit into
Conversation
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>
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)) { |
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)