Compositor Role in Input Methods

Point of Contention

Input method support in Wayland has always required CJK input method providers (fcitx, IBus) to interact with the compositor (via input-method-unstable-v1 and v2).

It was recently suggested on IRC #wayland and afterwards also discussed in #40 that previous protocols might have overplayed the role of the compositor for input method support and more should be done by clients without any compositor involvement via Wayland protocols.

Areas of Compositor Involvement

Fundamentally we can identify the following areas of compositor involvement in current input-method protocols:

Selection and Activation

Which input method client is selected to serve input methods is defined by the protocol. Current protocols all follow a first come first served policy.

In regards to activation of the selected input method client: the compositor informs the client when another client is asking for text input (via the text-input protocol).

Context Management

Input method providers might want to set different options depending on the context, that can be for example per window or application. The compositor needs to create such context information on its own or relay them from the receiving client.

Conveyed Data

This is data the compositor actually does not do anything with but only conveys between the clients. Examples are:

• Preedit and Commit String.
• Surrounding Text and other metadata like the cause for a change of the surrounding text.

Keyboard Grab

The input method requests a grab on the wl_keyboard. All keyboard events are then sent to the input method exclusively instead of to the client of the surface currently having keyboard focus.

Keys the input method does not use to form strings from the input method should transfer back to the compositor to be sent to the client with keyboard focus instead.

Graphical Presentation

Input methods often need to display some graphical information:

• CJK input shows word selection lists.
• Word completion services can show options for completion.
• Virtual keyboards show their input panel (input-method-unstable-v1 only).

In the first two cases a popup must be shown relative to the text-input. which the input method client can not do but must be delegated to the compositor. In the last case the panel must be placed globally, which again only the compositor can do.

Discussion

Solution Space

A solution of the initial question lies on a continuum between two poles. At these opposed extremes we have:

1. The compositor provides input methods itself.
2. Input methods integrate with clients that request it without the compositor and by that Wayland protocols being involved at all.

Solutions in between rely on some kind of compositor involvement. Discriminating criteria could be the previously listed areas of compositor involvement. For example a solution which features compositor involvement for all but the conveyed data between the clients (as in this not being sent via the Wayland protocol) is closer to pole 1 than a solution doing this and also not requiring a keyboard grab.

High-Level Arguments

Independent of technical solution some arguments can be formulated in favor of each direction:

Direction 1: More Compositor Involvement

• Wayland is a unifying specification pushing downstream projects to adapt common protocols. This process is already established. It might not be possible to establish something similar again between input method providers and receiving clients.
• Keeping the compositor involved provides possibilities for future innovations, for example different input method provider per virtual workspace.
• Current protocols go rather heavily on the compositor involvement. Implementations for these exist already. When we would move into the other direction now, we might lose a lot of prior art.

Direction 2: Less Compositor Involvement

• It is not directly intelligible why compositors should be involved in input methods at all. The mission of a Wayland compositor and what input methods do seem to be in completely different domains at first.
• Wayland compositors are complex pieces of software which on the other side must be extremely robust. Their footprint should be kept as small as possible. Whatever can be done in other pieces of the stack, should be done there.
• Compositor developers are less experienced with input methods than input method developers. It is therefore better when input method developers can come up with solutions not involving the compositor.
• Wayland compositor and protocol developers are generally overstretched with what they are working on. Less work for them is better.

Technical Solution

Explicit technical solutions must provide answers to the following questions:

• What areas of involvement are required or do we opt to keep for non-technical reasons?
• Do we need the narrowly scoped input-method and text-input protocols at all or could we do this through more generic interfaces?
• What about virtual keyboards? Should they provide key events through a separate protocol or do it through the input-method protocol?
• For each area of involvement being retained, how is the solution designed in detail?
• Can the requirements declared in #40 be fulfilled?