Current status of the Wayland text input protocols
The Wayland display protocols are mostly concerned with letting people show pixels on the screen. They also include two protocols related to text input however. Those two protocols are the text-input and the input-method protocols, both of which are part of the unstable Wayland protocols.
The goal of this blog post is to give the reader an overview of the current status of these protocols and their recent development. For me this blog post is also an opportunity to put into writing some of my notes and the collection of links that I have gathered about this topic over the last months. As such the information presented here may be incomplete and wrong in some cases so some caution is advised.
The first versions of these two protocols have been written and implemented quite a few years back in around 2012 or 2013. To understand what their purpose is let’s briefly recall what the Wayland protocols are used for. Wayland is a protocol that lets a compositor and its clients communicate so that all the clients can be shown on the screen by the compositor. The details of how this works can be read up on on the official Wayland protocol site linked above. How do the two text-input-related protocols fit in there then? The compositor is responsible for drawing the clients to the screen and somehow (at least some of) those clients will want to get textual input.
Currently there exist two ways for Wayland clients to get textual input. One is directly from the Wayland compositor through the wl_keyboard protocol. The other one is through the text-input and the input-method protocols which mainly describe how clients can get their textual input in case that there is an input method (IM) in-between that helps the user when composing text for CJK languages. How this is supposed to work can be gleamed from this presentation from 2013.
I have tried to render an illustration of how all the Wayland protocols responsible for text handling interact below.
The text-input and input-method protocols are represented by the two transparent rectangles with rounded corners. On the left side of these rectangles are the events that can be sent from the server to the client. On the right side are the requests that the clients can send to the Wayland server.
It’s easy to see that a Wayland client and an input method (which itself is a Wayland client) do not communicate directly. Instead, the Wayland compositor serves as an intermediate that decides how text in the client is manipulated by the input method client through the two Wayland protocols in question.
The first versions of these text-input and input-method Wayland protocols have been implemented in Weston and the weston editor client. Sadly, neither of the Wayland implementations in the two most popular Desktop Environments, KDE and GNOME, makes use of those protocols. GNOME seems to have switched to its own version of a text input protocol several months ago while KDE has implemented a different version of the protocol that was never upstreamed either (see here).
GNOME’s text-input protocol still seems to have issues which is also true for version one of the Wayland text-input protocol. Even with all the new revisions having been proposed on the wayland-protocol development mailing list, version one is still the only one that can be found in the Wayland protocols upstream repo.
Recent developments
About two months ago some new development around these protocols emerged. It seems to have been initiated by Purism’s efforts to start producing and selling their own Open Source phone. This new development manifested itself at first as a pull request to wlroots which is a Wayland compositor library that will be used by a bunch of upcoming tiling Windows managers which are still under development. The pull request implements the first version of the input-method and text-input protocols in wlroots. A few weeks later a new version of the text-input protocol has been sent to the wayland-protocols mailing list for consideration by an employee of Purism.
In addition to that, a patch for a virtual-keyboard protocol has been sent to the mailing list as well. The reasoning behind this new protocol seems to be that it would simplify the input-method protocol which currently includes keysym handling as well. By breaking this part out into its own protocol it presumably will be easier to implement a virtual keyboard when no full-blown IM with preediting is needed. The author of the protocol and its implementation has described his work on Purism’s blog.
Having followed the development of these text-relevant protocols in Wayland for a while, it is a joy to see that their development has picked up pace in the last two months. I am looking forward to seeing them take on shape further and hopefully contribute some more (than just spelling fixes) to their development.