On Tue, Dec 2, 2025, at 20:24, John Ramsden wrote: > This is why I’m concerned that a virtual keyboard implemented the way > Plasma Keyboard is currently designed may not allow "full keyboard" > functionality. It seems it would work well for text fields, but may not > allow me to send arbitrary key events in the same way a physical > keyboard can.
Wayland defines separate protocols for different responsibilities: input-method is responsible for the on-screen keyboard (OSK) communicating with the compositor, and text-input is responsible for the application communicating with the compositor. This is in addition to the base Wayland protocol, which allows the compositor to send raw key events to the application, and any compositor-specific protocols that may extend the possible feature set for an OSK. The important point here is that these two don't have to be an exact match for each other, because the compositor sits in between and can also insert its logic for these text or key events. In particular, KWin can (and in some circumstances, will) accept a text string from the OSK and translate it into key events. KWin also still exposes the org_kde_kwin_fake_input protocol, which allows a client (such as Plasma Keyboard) to send key events independently of the input-method protocol. Plasma Keyboard has a draft MR to use this and allow physical key emulation in addition to the text-based approach of Wayland's input-method protocol: https://invent.kde.org/plasma/plasma-keyboard/-/merge_requests/27 There is lots of discussion to be had about how best to tweak KWin or Plasma Keyboard for optimal behavior and long-term maintainability. But an application is shielded from this, all the necessary work can go into the compositor and OSK which then simply forward the appropriate events (via core Wayland or text-input) to the application. - Jakob
