fix(wayland): handle the wl_keyboard v10 repeated key state instead of aborting - #1774
Open
nikicat wants to merge 1 commit into
Open
fix(wayland): handle the wl_keyboard v10 repeated key state instead of aborting#1774nikicat wants to merge 1 commit into
repeated key state instead of aborting#1774nikicat wants to merge 1 commit into
Conversation
`wl_keyboard` v10 lets the compositor take over key repeat: it sends
`repeat_info { rate: 0 }` to disable client side repeat, then delivers
held keys as `key { state: repeated }`. The dispatch only matched
`Pressed` and `Released`, so every other value fell into
`_ => unreachable!()` and aborted the process.
That arm is reachable from compositor supplied data in two ways — the
new `Repeated` state, and any `WEnum::Unknown` state — so it is a panic
on untrusted input rather than an invariant. Handle `Repeated` as a
repeat key press (the compositor only sends it once client side repeat
is off, so there is no repeat timer to keep in sync) and downgrade the
remaining catch-all, plus its twin on the keymap format, to a warning.
Reproduced on mutter 50.3, which advertises `wl_seat` v10: holding any
key aborted the terminal with "internal error: entered unreachable
code". Needs sctk >= 0.20 to trigger, since 0.19 caps the `wl_seat` bind
at v7.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
wl_keyboardv10 lets the compositor take over key repeat. It signals this by sendingrepeat_info { rate: 0 }(disabling client-side repeat), then delivers held keys askey { state: repeated }— a thirdkey_statevalue added in that version.The Wayland keyboard dispatch matches only
PressedandReleased:so anything else aborts the process. That arm is reachable from compositor-supplied data in two ways — the new
Repeatedstate, and anyWEnum::Unknownstate — which makes it a panic on untrusted input rather than an invariant.Impact
mainis not affected today: sctk 0.19 caps thewl_seatbind at v7, so no compositor will sendrepeated. It becomes a hard crash the momentrio-windowmoves to sctk 0.20, which bindswl_seatup to v10.I hit it on a fork carrying that bump, on mutter 50.3 (advertises
wl_seatv10). Holding any key killed the terminal:Fix
WlKeyState::Repeatedas a repeat key press. No repeat-timer bookkeeping is needed: per the protocol the compositor only sends it afterrepeat_info { rate: 0 }, so client-side repeat is already disabled and the two paths are mutually exclusive.unreachable!()towarn!, so unknown protocol values degrade instead of aborting.Verification
Rebuilt with the sctk 0.20 bump on mutter 50.3 and held a key via
ydotoolwithWAYLAND_DEBUG=1:104
state: repeatedevents delivered, key repeat works, process survives. Before the change the first one aborted. Alsocargo check -p rio-windowon this branch's base (sctk 0.19) — clean.🤖 Generated with Claude Code