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
haveissues 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.