xorgproto 2026.1 ships quietly, and most of it is about your keyboard
xorgproto 2026.1 is a release about keyboard symbols. It exists to make sure the keys on your desktop still have proper names after the Linux kernel adds new ones you didn't know needed them.
The package was tagged by maintainer Alan Coopersmith and it carries the usual GPG signature. It follows the project's year-based versioning scheme, and it is the first release of 2026. There is nothing flashy here, and honestly that's the point.
Of the twelve commits in this release, the vast majority are keyboard keysym updates. The rest is a single documentation fix, some license housekeeping, and CI cleanup. No new extensions. No architecture changes. No performance bumps.
What xorgproto actually is
xorgproto bundles the headers and specification documents for the X Window System. It is the single source of truth that every other X library and driver compiles against. If you ever built xorg-server, libX11, or a graphics driver from source, you almost certainly linked against it without ever noticing or caring.
Per the project's own README, it consolidates 37 individual protocol packages into one versioned tarball. You've got the core foundation, then the extensions built on top: RandR for display reconfiguration, XKB for keyboards, Render, display power management, window-manager behavior, and a bag of legacy pieces that nobody talks about anymore.
One nuance worth remembering: the protocol specs are authoritative, but the headers are chained to backward compatibility. You can't just "fix" a wire format even when you spot a bug, because doing so could break an old client talking to a new server, or the reverse. That constraint explains why so many fixes land in the documentation rather than the protocol itself. For anything needing machine-readable definitions, the project points users to its sister repo, xcbproto. xorgproto stays the canonical wire-format reference.
The keyboard symbol table, modernized
By far the most substantive work here is syncing the keysym definitions with the Linux kernel's key-code tables. A keysym is the abstract name a client reports when you press a key, like Return or Escape, kept deliberately separate from the physical key. Keeping them in step with new kernels means freshly introduced hardware keys keep working across every X application.
If you're keeping score, the driving force is Pierre Le Marre of wismill.eu. He authored eight of the twelve commits and has quietly become the project's largest contributor overall, now sitting at 26 of the last 50 commits in the repo.
His changes mostly regenerate the XF86keysym.h header from newer kernel code. Kernel 6.18 brought new KEY_* codes, and kernel 7.0 brought even more. Media keys, launchers and other modern input devices then get proper symbolic names instead of falling back to something generic or undefined.
He also updated the keysym-generator script to handle evdev keys carrying Unicode annotations, which lets rotary and phone-style keypads map onto X more sensibly.
One of the more technically interesting commits promoted ISO_Group_Shift to its canonical name. The key had previously been called Mode_switch, a legacy name from the core X protocol that refers to a group-switching mechanism now made obsolete by XKB. Mode_switch also lacks latch and lock action variants, whereas ISO_Group_Shift supports them. The rename aligns X with how keyboards actually work.
Then there's the detail, if a keysym can have one. Le Marre added SSHARP, the symbolic name for the German capital sharp-S (ẞ). That's the official uppercase of ß when you hold shift or use all-caps. Giving it a proper keysym means editors and browsers can finally tell the two apart instead of mangling it into a lowercase ß.
He also added dead_apostrophe and a pair of single angle quotation marks (‹ and ›), the latter recognized as acceptable secondary quotation marks in several languages.
While the keysym work grabbed the attention, a separate commit by dec05eba touched a real protocol nuance in RandR's RRGetOutputPrimary reply. The reply was documented as 28 bytes when it should be at least 32, so an extra padding item was added. The interesting bit is that the generated header already had the correct layout, so the bug existed only in the documentation, not in any shipped code. It's exactly the kind of spec-only fix that xorgproto's backward-compatibility rules make appropriate.
Three small commits round out the release, and each one shows how the project actually runs. Coopersmith dropped the ci-fairy check-mr job, which only verified a checkbox letting maintainers edit merge requests, a setting that has been default for years and is now enforced elsewhere in the CI template. He also normalized every tracked text file to end with a trailing newline, avoiding subtle diffs and POSIX-compliance nits. Jasmine Tang removed a stale NCD notice from COPYING-xextproto, one that referenced LBX headers deleted back in 2009 and described code no longer shipped.
Who keeps the lights on
The repository is modest by modern open-source metrics. This is dependency software. Hundreds of packages rely on it, almost nobody names it, and if it stopped being maintained the whole X11 build ecosystem would quietly stall.
The contributor base is small but deep. Beyond Coopersmith and Le Marre, recurring names in the recent history include Enrico Weigelt, Erik Kurzinger, Olivier Fourdan and Jasmine Tang. A handful of engineers keeping foundational Linux graphics infrastructure alive.
The release cadence reads like a steady drumbeat. xorgproto switched to year-based versioning around 2018, and releases tend to land about once a year with occasional mid-year updates. The last one, xorgproto-2025.1, came down the pipeline on December 19, 2025, maintained by Olivier Fourdan of Red Hat. Coopersmith and Fourdan, both of whom work on the X server and display stacks at the distro level, are the primary maintainers today.
xorgproto 2026.1 is a fine case study in infrastructure that only becomes visible when it breaks. Every time someone on a Linux X11 desktop presses a recently added key, it's this symbol table translating physical scancodes into meaningful text. Get it wrong and you get garbled input, unmapped keys, or characters that look almost right but aren't.
It also makes two points about the X Window System in 2026. X11 is still a living standard, actively patched and extended even as the industry drifts toward Wayland. And the most valuable work is often unglamorous. Adding a keysym for a capital sharp-S, padding out a documentation struct, and dropping a notice for headers removed 17 years ago aren't headline features. They're the precise, low-risk maintenance that keeps billions of keystrokes correct.
If you've never heard of xorgproto, that's by design. It's doing its job.
Head here to the X.Org GitLab repo for commit history and download.
