Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Meta
Q&A
Posts Tags Edits
Ask Question

Welcome to the Power Users community on Codidact!

Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.

Post History

60%
+1 −0
Q&A What's the protocol for keyboards to communicate which keys were pressed?

There are quite a few layers and protocols involved in keyboard input. At the lowest layer, you have the USB HID protocol (https://www.usb.org/document-library/device-class-definition-hid-111 and ...

posted 5d ago by ninjalj‭  ·  edited 5d ago by ninjalj‭

Answer
#3: Post edited by user avatar ninjalj‭ · 2025-05-23T14:40:54Z (5 days ago)
#2: Post edited by user avatar ninjalj‭ · 2025-05-23T14:40:53Z (5 days ago)
  • There are quite a few layers and protocols involved in keyboard input.
  • At the lowest layer, you have the USB HID protocol (https://www.usb.org/document-library/device-class-definition-hid-111 and https://usb.org/document-library/hid-usage-tables-16). In times of yore, when the Earth was young and primordial beasts roamed the forests, there were the PS/2 and other protocols. Ben Eater has some nice videos on PS/2 and USB keyboards at Youtube (https://youtu.be/7aXbh9VUB3U?si=-WdEcrantNi7LbzX, https://youtu.be/wdgULBpRoXk?si=Xh8JluZ-JATTG3Pk and
  • https://youtu.be/2lPzTU-3ONI?si=LwNg-XjOll5Ph62_).
  • Then the operating system may have another protocol, such as evdev on Linux (https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h).
  • The display server/window system will have its own protocol, e.g. wl_keyboard (https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_keyboard) in Wayland, or the KeyPress, KeyRelease and KeymapNotify events in X11 (https://tronche.com/gui/x/xlib/).
  • Then there are input methods, which not only provide things such as proper support for CJK languages, which need many more symbols than keys are on a keyboard, but also support things such as predictive input (https://mike-fabian.github.io/ibus-typing-booster/). The situation at the moment in Linux is quite complex. Wayland (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39) has protocols to communicate between the input method framework and the compositor (`input-method-*`), and to communicate between client applications and the compositor (`text-input-*`), and there are currently different versions of each in use. X11 has XIM (https://www.x.org/releases/X11R7.6/doc/libX11/specs/XIM/xim.html), but toolkits such as GTK and Qt provide their own input method support. Short version: prefer Wayland protocols over toolkit support, prefer toolkit support over XIM.
  • And finally we arrive at terminals and terminal emulators. These tend to support some variation over the DEC VT100 (and above) protocol (https://vt100.net/docs/vt100-ug/chapter3.html#S3.1). As can be seen on xterm docs (https://invisible-island.net/xterm/ctlseqs/ctlseqs.html), the situation got quite complex over time, with keyboards having/not having different keys, and different terminal emulators supporting them in different ways. In more recent times there have been extensions to all this, such as xterm's ModifyOtherKeys, Leonerd's fixterms (https://www.leonerd.org.uk/hacks/fixterms/), and the Kitty keyboard protocol (https://sw.kovidgoyal.net/kitty/keyboard-protocol/).
  • More links:
  • https://en.m.wikipedia.org/wiki/Scancode
  • https://wiki.archlinux.org/title/Keyboard_input
  • https://tomscii.sig7.se/zutty/doc/KEYS.html
  • There are quite a few layers and protocols involved in keyboard input.
  • At the lowest layer, you have the USB HID protocol (https://www.usb.org/document-library/device-class-definition-hid-111 and https://usb.org/document-library/hid-usage-tables-16). In times of yore, when the Earth was young and primordial beasts roamed the forests, there were the PS/2 and other protocols. Ben Eater has some nice videos on PS/2 and USB keyboards at Youtube (https://youtu.be/7aXbh9VUB3U?si=-WdEcrantNi7LbzX, https://youtu.be/wdgULBpRoXk?si=Xh8JluZ-JATTG3Pk and
  • https://youtu.be/2lPzTU-3ONI?si=LwNg-XjOll5Ph62_).
  • Then the operating system may have another protocol, such as evdev on Linux (https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h).
  • The display server/window system will have its own protocol, e.g. wl_keyboard (https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_keyboard) in Wayland, or the KeyPress, KeyRelease and KeymapNotify events in X11 (https://tronche.com/gui/x/xlib/).
  • Then there are input methods, which not only provide things such as proper support for CJK languages, which need many more symbols than keys are on a keyboard, but also support things such as predictive input (https://mike-fabian.github.io/ibus-typing-booster/). The situation at the moment in Linux is quite complex. Wayland (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39) has protocols to communicate between the input method framework and the compositor (`input-method-*`), and to communicate between client applications and the compositor (`text-input-*`), and there are currently different versions of each in use. X11 has XIM (https://www.x.org/releases/X11R7.6/doc/libX11/specs/XIM/xim.html), but toolkits such as GTK and Qt provide their own input method support. Short version: prefer Wayland protocols over toolkit support, prefer toolkit support over XIM.
  • And finally we arrive at terminals and terminal emulators. These tend to support some variation over the DEC VT100 (and above) protocol (https://vt100.net/docs/vt100-ug/chapter3.html#S3.1). As can be seen on xterm docs (https://invisible-island.net/xterm/ctlseqs/ctlseqs.html), the situation got quite complex over time, with keyboards having/not having different keys, and different terminal emulators supporting them in different ways. In more recent times there have been extensions to all this, such as xterm's ModifyOtherKeys, Leonerd's fixterms (https://www.leonerd.org.uk/hacks/fixterms/), and the Kitty keyboard protocol (https://sw.kovidgoyal.net/kitty/keyboard-protocol/).
  • More links:
  • https://en.m.wikipedia.org/wiki/Scancode
  • https://wiki.archlinux.org/title/Keyboard_input
  • https://www.csslayer.info/wordpress/linux/how-to-make-your-application-support-input-method-under-linux/
  • https://tomscii.sig7.se/zutty/doc/KEYS.html
#1: Initial revision by user avatar ninjalj‭ · 2025-05-23T14:30:32Z (5 days ago) 
There are quite a few layers and protocols involved in keyboard input. 

At the lowest layer, you have the USB HID protocol (https://www.usb.org/document-library/device-class-definition-hid-111 and https://usb.org/document-library/hid-usage-tables-16). In times of yore, when the Earth was young and primordial beasts roamed the forests, there were the PS/2 and other protocols. Ben Eater has some nice videos on PS/2 and USB keyboards at Youtube (https://youtu.be/7aXbh9VUB3U?si=-WdEcrantNi7LbzX, https://youtu.be/wdgULBpRoXk?si=Xh8JluZ-JATTG3Pk and
https://youtu.be/2lPzTU-3ONI?si=LwNg-XjOll5Ph62_). 

Then the operating system may have another protocol, such as evdev on Linux (https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h). 

The display server/window system will have its own protocol, e.g. wl_keyboard (https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_keyboard) in Wayland, or the KeyPress, KeyRelease and KeymapNotify events in X11 (https://tronche.com/gui/x/xlib/). 


Then there are input methods, which not only provide things such as proper support for CJK languages, which need many more symbols than keys are on a keyboard, but also support things such as predictive input (https://mike-fabian.github.io/ibus-typing-booster/). The situation at the moment in Linux is quite complex. Wayland (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39) has protocols to communicate between the input method framework and the compositor (`input-method-*`), and to communicate between client applications and the compositor (`text-input-*`), and there are currently different versions of each in use. X11 has XIM (https://www.x.org/releases/X11R7.6/doc/libX11/specs/XIM/xim.html), but toolkits such as GTK and Qt provide their own input method support. Short version: prefer Wayland protocols over toolkit support, prefer toolkit support over XIM. 

And finally we arrive at terminals and terminal emulators. These tend to support some variation over the DEC VT100 (and above) protocol (https://vt100.net/docs/vt100-ug/chapter3.html#S3.1). As can be seen on xterm docs (https://invisible-island.net/xterm/ctlseqs/ctlseqs.html), the situation got quite complex over time, with keyboards having/not having different keys, and different terminal emulators supporting them in different ways. In more recent times there have been extensions to all this, such as xterm's ModifyOtherKeys, Leonerd's fixterms (https://www.leonerd.org.uk/hacks/fixterms/), and the Kitty keyboard protocol (https://sw.kovidgoyal.net/kitty/keyboard-protocol/). 

More links:

https://en.m.wikipedia.org/wiki/Scancode

https://wiki.archlinux.org/title/Keyboard_input

https://tomscii.sig7.se/zutty/doc/KEYS.html