Input emulation via libei

[mahkoh]

libei should provide most of the functionality needed. The primary difference is that libei does not allow the client to set a keymap.

One problem is that there is currently no way to map libei regions to wl_outputs for absolute pointer movements. I have opened https://gitlab.freedesktop.org/libinput/libei/-/issues/65 for this.

Is this something you are interested in?

[any1]

I never really understood why we need a library for this, but if someone wants to implement a libei backend and help to maintain it, I'll probably accept it.

It would be best to load libei using dlopen to keep it fully optional.

[any1]

Out of curiosity, do you think that libei would be a better solution than to have wayland protocols for virtual input? What makes it better? Does there exist a requirement for this that cannot be satisfied with a plain wayland protocols?

[mahkoh]

The problem with the existing protocols is that their interactions are not properly specified. If a client uses a virtual keyboard to inject events, does it also receive those events via wl_keyboard if it has the focus? If a client uses virtual keyboard to inject events, does it also receive those events via input-method if it has created an input method?

libei sits in the same layer as libinput which makes it clear that events take the same route as libinput events.

[any1]

If these interactions were to be properly specified, is there anything else that disqualifies the protocol approach?

I think that a virtual keyboard should inject events at the same level as libinput within the compositor. It's probably easier to implement that way.

[mahkoh]

If these interactions were to be properly specified, is there anything else that disqualifies the protocol approach?

Sure, if you specified it from the start, it should work.

I think that a virtual keyboard should inject events at the same level as libinput within the compositor.

fcitx requires that the virtual keyboard bypasses input-method clients.

[any1]

To be totally honest, I've never touched anything related to input method and for the longest time I didn't even know what it was for or why it existed.

If you type something on a regular keyboard, does that normally produce input method events for input method clients?

[mahkoh]

Input flows as follows when an input method is active:

1. Physical keyboard
2. Input method client
3. Virtual keyboard or input method protocol
4. Text input client

[any1]

Can you make a recommendation on how to specify IM interaction for ext-virtual-keyboard-v1?

[mahkoh]

If you want a protocol that acts at the libinput level, you first have to solve the usecase that fcitx currently uses the virtual keyboard protocol for. For example by adding methods to the input method protocol to send raw keyboard input directly to the client, bypassing the normal input pipeline.

If you want such a protocol to support client-defined keymaps, you also have to address https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/406 since otherwise there is no way to switch between keymaps without temporarily removing keyboard focus.

[any1]

If you want a protocol that acts at the libinput level, you first have to solve the usecase that fcitx currently uses the virtual keyboard protocol for. For example by adding methods to the input method protocol to send raw keyboard input directly to the client, bypassing the normal input pipeline.

Come to think of it, it simplifies a lot of things to specify that the virtual keyboard must have exclusive state. This would place it at a different level, right?

I'm also fine with virtual keyboards being at a different level than physical keyboards. I'll comment on this over on the MR.

If you want such a protocol to support client-defined keymaps, you also have to address https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/406 since otherwise there is no way to switch between keymaps without temporarily removing keyboard focus.

Does this affect the design of the virtual keyboard protocol?

[mahkoh]

Come to think of it, it simplifies a lot of things to specify that the virtual keyboard must have exclusive state.

I don't know what you mean by exclusive state.

Does this affect the design of the virtual keyboard protocol?

If you want the protocol to support custom keymaps. libei doesn't allow clients to set custom keymaps so this issue doesn't exist there.

[any1]

I don't know what you mean by exclusive state.

I mean that the state of the virtual keyboard does not affect other keyboards, be they physical or virtual, and vice versa.

If you want the protocol to support custom keymaps. libei doesn't allow clients to set custom keymaps so this issue doesn't exist there.

Sorry, I actually wanted to know how it affects the design. ;)