Linux keyboard backend has no mapping for VK_ABNT_C1 (ABNT2 dedicated `/ ?` key) — key is silently dropped

Open Beginner friendly
  • Is something wrong?
#6,051 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp, linux
Domain
backend

Research direction

Read libvirtualhid's src/platform/linux/uhid_backend.cpp and locate the key_code_to_linux() special_keys table; compare the Linux mapping with src/platform/windows/keylayout.hpp and the suggested KEY_RO mapping. Check whether VK_ABNT_C2 needs handling while editing. Done when VK_ABNT_C1 maps to KEY_RO and the Linux backend accepts it; the related Moonlight client change is described in moonlight-qt#1944.

Written by the indexing model from the issue text.

Description

Is this a new bug?
  • I have searched existing issues and this has not been reported before (no ABNT/ABNT_C1 results in LizardByte/Sunshine or LizardByte/libvirtualhid).
Describe the bug

The dedicated / ? key of a Brazilian ABNT2 keyboard is dropped on Linux hosts. Windows maps this key to the Brazil-specific VK_ABNT_C1 (0xC1, scan code 0x73), but Sunshine's Linux keyboard path has no mapping for it, so pressing the key types nothing regardless of the host's keyboard layout.

All other ABNT2 keys round-trip correctly once the host session layout is br (ABNT2) — only this key is lost.

Expected behavior

VK_ABNT_C1 should reach the host and produce / (? with Shift) when the host layout is ABNT2, the same way Windows hosts already handle it.

System File Check output
Current Directory: /home/machadex/.config/sunshine
Version: 2026.1103.235308 (commit: 019b1ba)
OS: CachyOS (Arch-based), Linux, KDE Plasma 6.8.2 on Wayland
GPU: NVIDIA (nvenc), capture: kwin
Details / evidence

Client: Moonlight for Windows (current stable), ABNT2 keyboard; host: Sunshine 2026.1103.235308.

  1. Official Windows layout — KBDBR.DLL (Portuguese Brazil ABNT2, via kbdlayout.info KBDTABLES dump) assigns:

    • ;/: → scan 0x35, VK_OEM_2 (0xBF)
    • \/| → scan 0x56, VK_OEM_102 (0xE2)
    • //? → scan 0x73, VK_ABNT_C1 (0xC1) ← the affected key

  2. Linux conversion table — key_code_to_linux() in libvirtualhid src/platform/linux/uhid_backend.cpp holds a fixed 48-pair table of US positions and has no 0xC1 entry (sequence: 0xBF→53 KEY_SLASH, 0xC0→41 KEY_GRAVE, then directly 0xDB→26). Verified both in master source and in the shipped binary (the pair<u32,u32> array at file offset 0x2c3a1a0 of /usr/bin/sunshine 2026.1103). Unmapped codes return -1 → "keyboard key code is not supported by the Linux backend".

  3. Windows backend already handles the key — libvirtualhid src/platform/windows/keylayout.hpp contains 115, /* 0xc1 */ (scan 0x73), so Windows hosts accept it. The gap is Linux-only.

Suggested fix

Add to the Linux special_keys table:

{0xC1, KEY_RO},   // VK_ABNT_C1 — ABNT2 dedicated slash key

KEY_RO (evdev 89) is the kernel code of the ABNT2 extra slash key — XKB <AB11> (keycode 97), which symbols/br maps to [slash, question, degree, questiondown]. On non-ABNT2 host layouts it lands on an unmapped position, exactly like other layout-specific extra keys. Consider VK_ABNT_C2 (0xC2) as well while touching this.

Related upstream

For the key to work end-to-end, the client also needs to start sending it: Moonlight for Windows currently discards the key before it hits the wire — confirmed with min_log_level = debug on Sunshine (no keyboard packet at all when pressing it). moonlight-stream/moonlight-qt#1789 reports that and PR moonlight-stream/moonlight-qt#1944 fixes it. Once that lands, Linux hosts will deliver 0xC1 into the unmapped table above — this fix is the second half.

Workaround

With the host layout set to br, AltGr+Q produces / and AltGr+W produces ? (level-3 mappings in symbols/br).

Dominant language
C++
Stars
43k
Forks
2.4k
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LizardByte/Sunshine

All issues in LizardByte/Sunshine

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.