The Input Stack on Linux: an End-To-End Architecture Overview
Postedabout 1 month agoActiveabout 1 month ago
Original: The Input Stack on Linux: An End-to-End Architecture Overview
venam.netTech Discussionstory
informativeneutral
Debate
0/100
LinuxInput DevicesOperating System Architecture
Key topics
Linux
Input Devices
Operating System Architecture
Discussion Activity
Light discussionFirst comment
2h
Peak period
4
2-4h
Avg / period
2.5
Key moments
- 01Story posted
Nov 27, 2025 at 11:55 AM EST
about 1 month ago
Step 01 - 02First comment
Nov 27, 2025 at 2:03 PM EST
2h after posting
Step 02 - 03Peak activity
4 comments in 2-4h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 28, 2025 at 5:48 AM EST
about 1 month ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 46071030Type: storyLast synced: 11/27/2025, 7:50:37 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
It is covered for both X11 and Wayland. I just don't get into the particular decisions and details of how each WM/DE picks what they deem the current focused window, since it varies widely and it's more part of window management than of input management (I've written a WM and it's a bit messy). An article on WM/Compositor development would be more appropriate for that, I have a few already on my blog.
>Obviously, each have their own internal representation and ways of managing the information they get from libinput, XKB, and others, but this is outside the scope of this article
From what I can tell this is the explaination. It says that they manage input. If this is good enough why not simplify what the kernel does by saying Linux has its own way of handling inputs from keyboard and that is out of scope. It just seems arbitrary what handling of input is and isn't in scope.