Things you should know about Windows Input, but would rather not

Original Article ↗ Hacker News Discussion ↗

Overall reaction to the article

  • Several commenters appreciate the explicit invitation for experts to critique the solution, seeing it as very “hacker spirit” and akin to using public writeups to attract better ideas.
  • Many confirm that Windows input is indeed a mess of legacy and modern APIs with surprising edge cases.

Raw input, NOLEGACY, and message queues

  • Commenters reiterate that once NOLEGACY is enabled, you can’t switch back to legacy messages at runtime; RIDEV_REMOVE kills all input.
  • Some propose synthesizing legacy messages yourself, but others note Windows tracks “real” vs synthetic events, which can break default handling and embedded components (e.g., WebView2).
  • There’s debate on how to structure message loops: some argue you should drain the entire queue and ignore unwanted messages in the handler, rather than selectively peeking.

Fullscreen vs borderless and input lag

  • Experiences differ: some find AAA titles only stable in true fullscreen; others say “borderless windowed” usually gives the best tradeoff of performance and Alt‑Tab behavior.
  • Newer flip-model presentation (DXGI / DX12-era) is mentioned as the key to low-latency borderless modes; support only became practical once older OS/DX versions could be dropped.

High-polling mice and performance

  • 8 kHz mice can flood queues and hurt performance; some have had to lower polling rates to avoid stutter.
  • Others downplay the problem, arguing that processing thousands of events per second shouldn’t be expensive, but game developers counter that real games do regress.
  • There’s debate over whether dropping events is acceptable; some note HID already reports deltas, so not every event must be processed for accurate motion.

Keyboard layouts, WASD, and input expectations

  • Many complain games inconsistently treat WASD as characters vs scancodes, breaking non‑US layouts and layout switching.
  • Multiple commenters insist games should:
    • Use scancodes for bindings (positional behavior).
    • Use OS APIs to map those to display labels.
  • Raw vs accelerated mouse input is debated: competitive players favor raw input; others argue defaulting to OS behavior is better for casuals.

Controllers, APIs, and alternatives

  • Old joysticks/wheels often need calibration; newer engines and APIs sometimes ignore system-level calibration, breaking older hardware.
  • GameInput is suggested as a unified API but is criticized for missing legacy devices (e.g., Xbox 360 pads) and not solving the message-flood issue.
  • Some suggest offloading raw input to a separate process or ring-buffer style handling, arguing multi-process designs are underused.

Other platform quirks

  • Wayland compositors can drop clients when event buffers overflow.
  • IME behavior (especially Japanese) and Shift timing for capitals are cited as broader, long-standing UX issues across platforms.
  • Rust game-dev tooling (e.g., winit) still struggles with repeat keys and timing, especially on X11.